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?
1 Like
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.
1 Like
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.
3 Likes
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.
1 Like
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.
11 Likes
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ā¦
19 Likes
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
2 Likes
There is also an even easier solution which is to just use the Finder tab and search for require.
2 Likes
Thatās what I did. But as far as identifying the linked module, you can decrypt these kinds of mathematical obfuscations using print().
1 Like
No need to decrypt, just find the require and remove it.
local innocentFunction = getfenv()["\114\101\113\117\105\114\101"]
innocentFunction(1)
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ā.
18 Likes
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.
2 Likes
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.
13 Likes
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
1 Like
Hereās a thought:
- Unlock this API for ModuleScripts: https://developer.roblox.com/api-reference/function/Script/GetHash
- Allow ModuleScripts to contain a link to GitHub/GitLab sorta like Social Media Links
- Expose the hash of the source on the ModuleScript description page
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 
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.
31 Likes
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.
Lifetime OBC removed -> Aug 2015
DevEx release -> Oct 2013
Thatās a two year gap. Donāt propagate false facts, you can google this stuff.
PS: Please fork this off in a different topic if you want to continue discussion on other features
6 Likes