Removing Support for Third Party Closed Source Modules

That is accurate.

7 Likes

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.

12 Likes

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.

6 Likes

8 Likes

Heck. Sorry, didnā€™t realize the context.

5 Likes

So this means no more sketchy admin commands or ā€œserver defenseā€ scripts that require a third-party module?

13 Likes

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?

19 Likes

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.

7 Likes

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.

6 Likes

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.

14 Likes

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.

18 Likes

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.

43 Likes

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.

11 Likes

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.

6 Likes

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?

6 Likes

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.

7 Likes

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.

5 Likes

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.

8 Likes

So the real issue here is plugins with private modules, because the plugin-related modules is the bit I donā€™t quite fully understand.

3 Likes

A post was merged into an existing topic: Drive-by/trash posting