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.
This pretty much already happens. Admin systems are the most common non-malicious use case, and there is probably at least 50 competing ones of the platform. I own one, and it will become open sourced in Q1 of 2019 because of these changes. I can afford this because I make no HttpService calls.
Sure, people could make NDAs. But what if they have 50,000 clients? And I’m pretty sure you can’t enforce a contract with minors, and last time I checked the majority of players are under 18.
We already secure our system with API keys, but there are some aspects of our roblox side system that could be manipulated if the code was open sourced.
Our business model is to provide a free service to thousands of users. We can’t provide a free service if the required maintenance of the system grows exponentially. Thousands of our customers heavily rely on our services to grow their groups on Roblox.
From what your system is describing, is it not possible for someone to manipulate the service by dropping in bots that change their camera CFrame to look at the ads you are loading in?
If you have to depend on trusting the game itself not to manipulate your system to boost advertising, that seems like a bad idea.
Would it be difficult to track who is abusing your service? Assuming the HttpService sends data about what place the request was sent from, you could monitor their place visits and see if the rates from the game reasonably correlate with the averages you would expect if your system is being used normally.
Advertising is one the services we provide. Our algorithm takes into account many different things when determining a valid view. For instance: verifying that the whole advertisement is not obscured by anything and is fully visible to a player.
Each game is different in where they place the ads, so some get more views than others. We’ve made reasonable steps to ensure that the game can’t fake views, but the majority of these steps would be made invalid with open source.