In a rather late change of events, @SquirrelByte’s Terabyte Service has chosen to raise a petition to prevent this change. The disagreement has massively change from the private threads seen here on the DevFourms which has helped lead to this debated change
My organisation provides application systems to groups and relies on private modules in order to power over 60,000 games on Roblox. These games have drawn in well over 2 million unique players.
Releasing the source code would expose months of work on our services, and our HTTP API would become more vulnerable from attacks, making maintaining our systems harder and more time consuming.
This abrupt removal of private modules with no alternative will effectively push Terabyte away from working on Roblox, ruining the application system used by thousands of groups.
We do acknowledge the security risks associated with private modules. However, during our operation we’ve found that the benefits have far outweighed the drawbacks. We have started a petition against the removal of private modules without any proper alternative being implemented. At the time of writing, there had already been 3,900 signatures from our platform.
Could you explain what your system does and why your code needs to be private in more detail? Maybe they can fulfil the use case in some other way if you better describe what you need.
The actual endpoints are not hidden due to the console, but other aspects such as post parameters and how our system structures the requests are.
What my service mainly does is provide a full system for accepting applications from Roblox players. Players download a place from our website that is dedicated to solely loading in the private module, and then they publish this to a game. This module doesn’t work for any other purpose but to load a centre in an empty place.
On the other hand, we provide a in-game advertising system. This system automatically tracks player’s camera positions and uses special algorithms to determine if they have viewed each 3D billboard. The developer of the game is then rewarded for each impression. This script also relies on http requests to send impressions to our server, and the system would be more vulnerable to rigging if the algorithms were open sourced.
I would recommend filing this as a separate feature request, since this is steering quite a bit off-topic from the announcement, and we don’t want your feedback to get lost as just a reply in this thread. (Make sure to search beforehand to check that no one has filed this feature request before)
Just an update on the petition created by Terabyte Services. Over 11,000 Roblox users have signed. You can view the latest signature count on our website.
This doesn’t really solve the problem though. If a creator is using free models that might contain the malicious code behind the private modules, then it’s likely that the creator is unable to code those things for himself and therefore wouldn’t be able to understand what the module does regardless.
And I don’t mean to insult anyone’s abilities or anything; however, for most of the people that use the models on the front page which are infected with the back doors, I don’t particularly think they’re capable of finding the module from the ID anyways.
A better solution would be to warn the people inserting the models into their game that there is a private module running in their game and possibly implementing the same thing chrome does in which each module has a warning about what it does(creating parts, accessing DataStoreService/MarketplaceService, etc.)
I’m hoping that after the privatemodules are removed we can get featured models on the asset catalog with admin scripts and cool map pieces that don’t contain malcious scripts for the front page.
I’m struggling to understand how removing private modules will achieve anything. You can simply use httpservice and just load scripts remotely like that.
Backdoors stored on Roblox would be easier to moderate over some remote website.
Roblox might as well just remove HttpService whilst they’re at it.
This is not true. Doing this requires flipping two switches which are both disabled by default (HttpEnabled and LoadstringEnabled). Private modules, on the other hand, work out of the box, so developers are far more vulnerable in this respect.
Pulling source code from a website does not replicate the behavior of private modules, because the code itself would be freely accessible and able to be inspected.
EDIT: If you want to continue discussing this, take it to DMs with me to avoid derailing the thread.
People who are most vulnerable to backdoors do not have the knowledge to probe around looking for code. Adding HttpService and obfuscation to the mix could make it very difficult for people to access and then interpret the malicious code.
You don’t need to enable loadstring, you can use a lua based lua interpreter, similar to those used in admin scripts.
Someone in this thread mentioned that malicious scripts could just load in a gui to tell the developer of the game to enable the right stuff: such as HttpService.
Removing private modules will just lead to more elaborate malicious scripts.
The fundamental problem was that third party closed source modules force the developer to give blind trust to the module creator. There were no access permissions or sandboxing in order to programmatically ensure that the module was only doing authorized actions.
With a Lua VM or obfuscated code, a sophisticated developer can theoretically audit the code and uncover if it is doing anything malicious and get it taken down. The presence of a Lua VM is itself a huge signal that the code might be doing something malicious.
This was never the case with third party closed source modules. The module creator could claim that it is not doing anything malicious and it is impossible to verify this claim.
This is the core reason I think you guys are going the wrong direction here. I completely understand why you’ve come to the conclusion of removing third party module support (which you still haven’t verified if first party support will continue to work, just want to be sure even tho it’s sorta implied), but at the cost of a lot of developers being put at risk of losing their business model, and you still don’t resolve assisting developers who haven’t the slightest clue about these things yet. I’m not worried about established developers at all, I’m worried about those who don’t fully understand Lua and the ROBLOX API yet. If you guys are serious about bringing granular sandboxing for private code, then why not prioritize this asap verses removing third party modules? You can already see almost 15k and growing users are against this change.
Yes, if the owner of the game owns the module it can still be private. This only applies to modules that are being required from other people or groups.
If you guys are trying to hide Lua code that does stuff in-engine, you are pretty much asking for someone to create an open sourced version that rivals yours.
The concern of exposing API keys is warranted. However, I think the better solution here would be to provide a middle-man web service to whatever API you are providing. When people buy into your service, you should provide them with an API key that they keep private instead of you. That way, YOU are the auditor of your own service. If someone abuses your endpoint with the API key you gave them, it is at your discretion to revoke their key.
This whole private module system has promoted a toxic economy where people would prefer allowing unlimited serverside backdoor access than to lose out on the money they presently gain from it. There are better ways that this could be done, without Roblox needing to facilitate it.
If people are so concerned about their code being leaked, then they should go through the trouble of creating legally binding NDA agreements between you and the people who use your system. I see no rational reason to keep the code private otherwise.