Removing Support for Third Party Closed Source Modules


That may be true for newer developers coming into the platform. But I’m not sure I know of any knowledgeable developers that randomly add third party content without at least looking into the source a bit. I know you guys want to appeal to the entire spectrum of developers on the platform, but that shouldn’t mean you punish others because other people don’t know how to use the system.


We have no definite plans to do this. If you want this to happen, the best thing to do is post a feature request with your specific use case. This will help us better understand what sort of sandboxing we would need to provide to make this a reality.


I’m fine with closed source third party modules going, but now that public ones may go I’m concerned. It’s important for users without development experience who use certain models to be able to insert them with ease, and not have to enable any form of auto updating themselves. This allows a lot more users to easily receive updates on the models they take.

My question is, will the packages auto update without any interaction from the user putting it in their place?


I would personally not want that to be the default/only option, you really don’t want to give people the ability to dynamically update content that affects your game, and if you think you do then this should be an opt-in per-package. Even if there is no option to auto-update, if the API is rich enough, you could probably define a plugin that auto-updates certain packages when you load up Studio.


I wouldn’t want anything auto updating in a game of mine because I’m capable of managing things myself. My worry is users who aren’t capable of that, those who would benefit from things just being auto updated on default. Users who use Roblox primarily to socialize with their friends, making places for fun to hang out with friends in rather than full-fledged games with lots of development experience behind them.

This would be better, but the best case scenario for users like this is auto updates where they don’t even need to open studio. For these users, auto updating wouldn’t pose any more of a risk than already malicious models, and I’m not concerned about anything being open source or closed source since I already planned to make things open source.


This argument definitely goes both ways and I’m not sure which side is the strongest. Yes, it means users don’t need to update the packages themselves, but if something suddenly breaks in their games because of a package update (i.e. one that is actually buggy, or just not taking backwards compatibility into account), they may not be capable of fixing it either because of the lack of experience/skill. I agree that there should be an option to auto-update in general though.


I know this thread has died down, but I wanted to bring up another big flaw that I’ve noticed with this band-aid fix:

I know this change was made to stop the mass amount of backdoors that have been appearing on Roblox. However, this fix still allows modules that are simply made public to work. Most game owners who don’t know a lot about how modules work will not look at these loader scripts as suspicious, and because after the change all backdoor modules will simply be made public, backdoors will continue to be an issue.

As I and many others have suggested, we should have 1) a property that you MUST enable yourself in order to load any modules that are not an already present object in-game (ID-based modules) and 2) put a warn in the Developer Console that tells when ANY module is inserted (Along the lines of “Module [id] has been loaded into the game”). This allows developers to see exactly what modules are being placed in their game, if they want ID-based modules at all, and is probably our best bet at combatting backdoors.

I’ve also seen other people say that we should allow Private Modules but restrict their accessibility to the Server. I think this change is fine, but I along with others use Private Modules extensively to whitelist a sold product to other people. If a lot of the API is restricted, these modules would be practically useless.

As I previously said before, most game owners won’t see this post and won’t know that there will be any change and won’t know that there is potentially a malicious script being loaded into their game. Therefore, when the change rolls around, all the exploiters have to do is make the module public and they can continue their shenanigans.

Thank you.


Someone came to me saying a user remotely updated their game to break. I helped him track down the module responsible, and it turns out it was public. Other developers in this thread have proposed obfuscation to protect their code from copiers, and it seems we weren’t alone in this line of thinking.

Forcing modules to be public may not stop the malicious users from creating backdoors. They will change tactics in response to this. Just thought I should share this with you all so we know what to look for. Because your average user probably won’t…

EDIT: And this was a very simple example of obfuscation. You could solve it by changing “require” to “print”. Imagine if someone truly wanted to encrypt their source…


Or just check for anything that is named “require” in the code. Easy find to be fair.


To look for all scripts that have require in them, you can use this in the debug line in studio: (sometimes picks up false positives but still works)

for i,v in pairs(game:GetDescendants()) do pcall(function() if v:IsA("Script") or v:IsA("LocalScript") then if string.find(v.Source, "require") then print(v:GetFullName()) end end end) end


There is also an even easier solution which is to just use the Finder tab and search for require.


That’s what I did. But as far as identifying the linked module, you can decrypt these kinds of mathematical obfuscations using print().


No need to decrypt, just find the require and remove it.

local innocentFunction = getfenv()["\114\101\113\117\105\114\101"]

21:30:25.577 - Unable to find module for asset id

There are ways to use require in a script without having the word “require” anywhere in it. Even if you try to search for that instead, maybe they have getfenv everywhere in their script to confuse you / how they obfuscate it, or use string.char(50*2 + 1) to prevent you from searching for “require”.


Oh yeah true, forgot about that. The best suggestion then would be an option for the game to enable third part modules like mentioned somewhere above.


I don’t really agree with shutting down third party modules behind a property users have to enable. All it does it removes usability for a large chunk of players who would fall for free models even if the malicious script was inserted right into their place. Having these users go into studio and change a setting will cut down on how many users will use the model. It’s important to remember a very common use for places is for non-devs to make fun hangout places to play with friends, and they will need free models to do so.

Public third party modules are just as safe as any other free model for the primary consumer of them, which is people without a lot of coding experience. Anyone who can read a script and figure out whether or not it’s doing anything malicious can also just make whatever the model is supposed to be themself. Modules are very good for users to receive updates automatically. Without a replacement for auto updates without the user needing to go back in studio, it’s not very fair to remove any proper way of doing so as it benefits no one.

Any code that can run in someone’s game should be publicly available, yes. But past that whether it’s a third party module or a script inserted directly, no difference will be made for the security of the users. I would make any model of mine have the owner take a copy of the module too when they go in-game, but that requires third party sales to be enabled, at which point they’d need to be able to follow instructions on how to enable the script anyway through this proposed property I keep seeing in this thread.


Does the finder search for keywords inside of a Script’s source code? I tried that when the searchbar was added and it didn’t work


Here’s a thought:

This now gives developers a way to validate changes to the source while keeping private modules in tack until the company is able to finish up a Sandbox permissive based modules system. If users decide to not open their source/allow viewing through a form of licensing, at the very least developers can ensure changes can be brought up and questioned since they can detect changes via hash changes.

C’mon, there’s got to be an alternative to this until you guys are able to upgrade the system. This feature, while maybe not seen as such to every developer, has a lot of extensive use cases. If removed, a lot of small to medium communities will be destroyed and possibly never recover even after a permissive system comes in. Don’t ruin our communities all in the sake of some bad apples :confused:

Edit: I do see one flaw in this, and that the script Instance isn’t always passed along. To fix this, return the script Instance as the first argument of require followed by the returned arguments for private modules. Source is blank, yes? So besides having to adapt, it’ll be a functional fix.


It’s less about the fact that they don’t care about bots, but more about the fact that a developer with a good module for a vehicle script could slip a place copier or admin abilities into their code and the developer that required the asset would have no way of knowing; not only this but he would have no way of removing the malware without rewriting the entire module - something that might not be possible depending on their code abilities. Always get your models from the original author, and don’t insert anything you haven’t personally checked over for viruses / malicious intent.


Quote from the post; “We are removing tickets for a number of reasons. Although familiar to many of us, they are confusing to first-time users.”

Lifetime OBC got removed very close to the point where DevEx got released. This caused many people to believe it got removed for that reason. I’m sorry for making that conclusion.