That is accurate.
Just realized that I have around 10 private modules used in both of my games, three of them being required by another one of them. Looks like Iāll have to copy all of them and edit the named one to require the correct copy of the other modules per game. Maintaining this will be a pain.
Speechless rn.
If you own them, you donāt have to do anything to fix this, and if you donāt, copying them should be infeasible anyways.
Heck. Sorry, didnāt realize the context.
So this means no more sketchy admin commands or āserver defenseā scripts that require a third-party module?
Sooo ā¦ my solution is just being thrown under the water? Itās the same path youāve guys have taken before, and it provides a much better means than removing the feature until the company can do what youāve discussed regarding granular control. If it comes down to it, I guess itāll actually happen, but youāre only encouraging the bots/those who wish to protect their source until such solution to build encrypted VMs. Then weāre back to the same problem: inexperienced developers still at risk of not understanding what the code does and utilizing the bad malicious plugins/scripts. Why canāt this even be considered? Yes, youāll have prompts to ignore/allow the module, but it still WARNS the developer of the risks each and every time? Whatās so bad about this vs not having it at all?
I am excited beyond compare.
Backdoors, hidden stuff in admin scripts, and all sorts of crazy stuff ends here and now. I am completely ready for this. In my eyes, if youāre worried about copy-cats and clones of your private module script, then donāt make it public to begin with. If itās going to be a free model, thereās going to be copiers.
What you state as an alternative will ultimately lead to the same grimey situation we are currently in (backdoors, malicious scripts hidden inside other scripts). I feel this is a good change, despite some drawbacks we have to overcome.
We considered adding a setting to allow third party modules. Ultimately we decided against it because it is simply too dangerous to let developers put third party unsandboxed, unauditable code in games on our platform. We are not willing to take this risk.
We are aware that this change alone is not adequate to address malicious code. We are taking other actions to mitigate abuse, which you will hear more about in the coming months.
This. This. This! If any developer in this thread is still unsure/against this change, this should be reason enough to support this change. Developers must have 100% control and transparency about what code is run in their game, and private modules donāt allow that.
February 1st cannot come soon enough.
Well, Iāve wasted 100s of hours of work on something that can now be copied, be edited within a few minutes to have any premium content be completely free, and then republished as someone elseās magnum opus.
A lot of developers relied on this functionality for income to help support themselves. Abruptly taking it away without giving any other means to accomplish anything similar greatly undermines the value of developing for ROBLOX for these developers, as apparently whatever they spend their time and effort making and building for themselves can be instantly taken away from them.
Not that I disagree, but consider thisā¦
A group uses a private module to run their game, they also hire developers who could leak the games. The use of private modules allow for the scripts to remain safe.
I want to ālicenseā proprietary scripts to a group for a month.
These arenāt the only scenarios, and it seems like the perspective for removing the private modules is against backdoors in free models.
Personally I wrote all my private modules years ago when I had very little experience, so they are filled with api keys and urls i dont want other people using. Itās not worth the hassle of re-scripting them as few people use them, so theyāll just have to be retired.
Awww man!
Now Iām gonna have to find a new way to load in my weapon scripts.
If I am the only one using the private module and itās linked to my group game does it still count as third party?
Solution: Donāt hire people who leak games. Also, if theyāre paying for a license, they shouldnāt want to leak it in the first place. Lua is, in general, not a closed source language. We know this going in.
Also, backdoors in free models arenāt the only place - stolen copies of plugins will also insert malicious code, too. Itās dangerous all around.
I donāt own the group so who gets hired is not up to me.
What other solution are we given if we want to make proprietary scripts. This issue surely exists in the real world; you canāt just read the source code of any application you download from the internet, who knows what is in it.
Again, it is at the developers discretion if they want to use free-models which may contain scripts that require private modules that are for malicious intent such as backdoors for server-side script execution.
[EDIT] - If you canāt trust a free model, quite simply, donāt use it. Why should people who make use of private modules without malicious intent not be able to do that anymore.
I support the fact that new developers may not understand these issues and that private modules have their downsides but the solution should not be to remove that feature entirely.
You can crack open pretty much any EXE with Resource Hacker, or copy the program itself and release it as a tainted program - itās how rogue antiviruses come about. Thereās really no safe way to release code as people are bound to find ways around it, either through decompiling, or just straight up re-releasing the software with a hidden backdoor. Exploiters on Roblox are doing the latter, and thereās no way to stop them as they can bot accounts with the same plugins uploaded endless times.
So the real issue here is plugins with private modules, because the plugin-related modules is the bit I donāt quite fully understand.