Okay, let me expand my “band-aid” fix: if the script a developer inserts has a private third party module, then WARN them Everytime about the module and it’s risks and REQUIRE them to accept the risks on top of the similar requirements to how LoadstringEnabled works on the Server. I just don’t understand why we can do this with LoadstringEnabled, something I’d say is simiarly as bad, but not with Third Party ModuleScripts.
Well, at that point, people could just have the backdoor in the script itself. My idea (and forcefully open sourcing private modules) just allows developers to check what they use. If they choose not to…
Maybe introducing that the same time they remove the current system would be more effective.
Some of us are heavily dependant on closed sourced modules for our communities for features such as global data stores.
LinkedSource should be able to replace that I think.
I’m in support of allowing people to know all code running within their game and providing better controls on anything spooky. Aside from getting the game owner to look through scripts and change stuff, another issue with sandboxing is the module could say it specifically needs stuff like HTTP access or whatever else and would then be given it by the place owner anyway while the place owner just blindly trusts that it’s doing what it says it’s doing.
A trust system on top of this is necessary. If Roblox were to introduce a case-by-case permission system without any trust built-in, then we would see half of the people trying to inject malicious modules in the game showing guis like this:
I don’t think there has been a problem with third party closed modules in games these days. People make the choice to use other people’s modules or not being fully aware with the possibility of it being malicious.
Thought about that. Plenty of malicious models have already done things like that and people were perfectly happy to comply with whatever it was telling them to do (remember those “login” guis?)
It’s a bad idea, anyway I’ll get my mate to remove his stuff from the public and say. The code is too personal…
$ npm install some-random-package@latest
Now imagine that you used that in your production code-base PLUS you couldn’t audit the package. That’s why private modules are bad. You should never run arbitrary code in your game. You should always be able to pull in specific versions and audit the code.
It’s unstable, unsustainable, insecure, and just bad practice overall.
As for writing private modules…why? What harm is there in making the code visible to others? Who cares if someone takes it and changes it around a bit? If you’re allowing others to use your code, you might as well allow them to view the source.
Also, consider that a private module could then require other private modules. How do you know that the first module creator is as cautious as you are? It leads to a string of unknown dependencies with unknown security issues.
Is there any other way to provide closed source code to a game with a similar function as this?? I use private modules to sell a service and I can’t make this service open-source due to user keys and tokens that must stay private.
I remember back when Roblox proposed letting people sell models for Robux, but cancelled it due to a lack of protection from copiers. Now you’re removing our protection entirely… I get why you’re doing this; rule-breakers could remotely destroy games. But this is another example of punishing the rule-followers to stop the rule-breakers. There has to be a middle ground…
This is exactly what I think. I, as a developer, now have no protection for my paid service to be stolen and resold or just given away. There is no middle ground and I don’t think that’s exactly fair for the people who are using this functionality as a business.
People have offered many solutions that would work perfect for my use, and I think that some sort of ThirdPartyModulesAllowed property would be great. Someone, please consider this. If the removal of this functionality occurs with no middle ground, I won’t be able to sell my product anymore.
The tragic thing is, many kids would fall for that simply because of those last six words. I know players who cannot speak a single sentence without including “Fortnite” in it somewhere. Unfortunately, these kinds of updates exist solely to protect those people at everyone else’s expense…
Given the general vein of this thread, I’m hoping Roblox mentions what they’re doing to replace private modules before February. Until then, we’ve been given adequate warning, even if it’s not a particularly good fix for everyone involved.
Also, please guys. Snide remarks and passive aggression aren’t becoming of anyone; we’re all on the same boat.
I would like to add some additional context on this decision.
Currently modules can do anything that a regular game script can do:
- Access data stores
- Teleport players to other games
- Send HTTP requests to any domain (if the game allows HTTP requests)
- Log player chat messages
Long term, we are going to implement a solution where plugins/scripts can be given granular access in order to sandbox games from malicious code they may import. However, this solution requires significant effort and it would be impossible for us to deliver it until late next year at the earliest.
We are not saying we will never support closed source modules, but that the current risk is simply too high to allow.
Without coming off as accusatory, in the meantime what would you suggest people who sell products or use modules to hide sensitive information do? It’s obviously a bad idea to include sensitive information like API keys in a place that other people can access, but at the moment there’s no real alternative.
If you are exposing a service through web APIs, I recommend doing what most products do: have developers create API keys and use those to authenticate against your service. Make sure to have throttling and other protections in place to prevent abuse.
If you are providing some sort of anti-cheat service or something that requires the code run on the game server but not be accessible to anyone, unfortunately that use case is no longer supported.
Alrighty. That’s disappointing to hear, though it’s understandable. Will that use case be supported once closed source modules are re-allowed in the future, or is it too early to tell?
Can you tell me if I would still be able to do this (given the module is located in my inventory, rather than on the group)? If not, I’d like to adjust things as soon as possible.