So as per my original question, modules published to group assets can be used by the games that are also published to that group, without having the source code viewable by others?
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.
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.
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.