I disagree with this change.
I believe that the people that are most affected by backdoors are users without the programming knowledge to be able to find the backdoors. What happens when they just make it open source?
I believe that this feature hurts the legitimate users (people with services) more then hurts the illegitimate ones.
10 Likes
Considering obfuscation â it would be quite helpful if there were tools to find suspicious-looking code kind of like an Antivirus heuristic. You run the scanner and it checks the scripts for unusual things like:
- tons of whitespace
- creating strings by concatenating string.char()
- copies itself into touched bricks
I canât list too many features because I donât spend much time picking at viruses and malicious code. Obviously false flags are possible, but since it only identifies the malicious scripts, it doesnât matter.
Of course, thereâs potential for abuse if developers rely too heavily on this, and virus makers will have an easy way to test their code against the heuristic until it doesnât get flagged.
One of my friends recently put together a game and it was infested with viruses that used remote modules, so it was an interesting to see all the new kinds of viruses that appear since Daaaang You Got Owned.
1 Like
Why not just add a âThird Party Modulesâ section that you can manually enable. Set it to false on all games.
It could go right underneath HTTP enabled.
9 Likes
I am not against the removal, even we have modules for the public. But as long modules will stay working from the owner it groups i am not against it.
For example, i own 2 groups on 1 group are the modules located because itâs also the test version for the games. And one group is public with the games on them. As long the modules keep working from Group A to group B that is owned by the same user. I donât mind the removal.
1 Like
In my opinion, whatâs being done hereâs a good decision and change in the long run for everyone.
1 Like
it might be a good change for some, but definitly not everyone, if it was, nobody would be complaining
5 Likes
I understand this has been stated multiple times, but it is true this will continue to impact the userbase which were affected by closed sourced modules anyways. The biggest reason I see this change occuring? Profitable/popular devs were impacted.
Through the months before and after this announcement, Iâve seen quite a few top developers complain on how theyâve been impacted by some malicious code, which eventually lead to this antivirus plugin and this announcement regarding Backpacks.
Now very few if many knew they were impacted until the discovery of how Plugins were injecting Scripts into hidden services which couldnât even be accessed by the highest security context we have available (due to the change, I donât know what this is anymore, but used to be 6). However, it doesnât change the fact that top devs were impacted. Please correct me if Iâm appearing bias, Iâm doing my best to be as unbias as possible here, but this change seems to be in regards to higher level devs being impacted more significantly than before. This is unfortunate as us small communities are now also impacted by the small percentage of top devs who caused the greatest amount of damage (as in the value of having their popular games with a backdoor). Even more unfortunately, top devs donât tend to allow these things to enter their games, thus why this change is being raved as âitâs for the better than worseâ in my opinion. This solves a problem for the top percentage who had experience and knows what their doing, but not for the vast majority who are still inexperienced or are not aware that such a exploit exists (those who are not aware of the devforums/havenât had anyone to inform them), they will continue to be slammed with bots and obfuscation until they fall victim. While I do agree obfuscation is more auditable, not everyone knows how to or will even expect they need to audit this code, especially since the purpose of free models is to be a catalog to utilize assets from other devs in areas you have not be as experienced in/use an already established product rather than wasting time creating your own.
Its especially sad as ROBLOX is growing, so is the interest to develop competitive services on the platform, whether open or closed source. Say all you want about open sourced being better, I donât completely disagree. But where I come from, we allow you to protect your IP through closed sourced methods. I bet a lot if not most of you are using Windows/MacOS of some form or fashion to use ROBLOX. Why? Because these closed source products have for profit companies which have resources to support them, unlike the open Sourced Linux alternatives which have been available for just as long as these closed sourced products. So we need to stop the bias of âopen sourced is betterâ cause no, itâs not. You can make a model to profit off of it, but itâs not the only nor most effective way. Even though companies are embracing open sourced, a lot still havenât opened up their core products.
Long rant short: the impact apon top devs caused this, vast majority will still be impacted. Closed source is not the problem, nor is open source the solution. A step in the right direction would be proper sandboxing and tools to validate what code accesses vs seeing the source of the code.
13 Likes
Iâm against the removal of closed source modules and Iâm hurrying you to put them as soon as possible.
2 Likes
I think in one way the removal is good since then people cant update the code to something else if they want to, this is a good thing against it but I know many people dont like this change but it is for the better as long as groups still can use modules from other groups you own I am fine with it.
1 Like
I fully understand the urgency of closing support of private modules, but there should be an alternative immediately instead of just closing them completely. Since there is a category of developers that rely on closed source modules on income (People including SquirrelByte, wind_o, and NoCollider). Closed source modules do have a low amount of people that abuse it like viruses or ruining peoples games, but it should have an alternative/permission system as a solution that counters these (As a few users suggested.). Closing support puts these categories of developers in a tough spot, web servers are too much to handle and they can break anytime. Which is why they shouldnât be closed completely.
What I recommend strongly that adding a bool value for enabling private modules until a solution is created for the near future as quoted above. Keeping code private is another important thing, since these services require payment, simply making it open source can be easily taken and removing the permission system. Paying for these modules, makes these creators work more on these modules making good quality of service they offer. How is this so? Comparing a paid service against a free one the paid service has more quality and customer service.
In the end, closing support for closed source modules would cause a lot of services to be removed due to this change.
4 Likes
Windows and Mac OSX code is auditable though: slap any Microsoft DLL (or hell, even the kernel) into your disassembler of choice and you will be able to audit it - Microsoft even gives you their debugging symbols to help you out.
Unlike Windows or Mac OSX though, Roblox private modules are completely unauditable without some sort of security vulnerability to get their source. (which completely defeats the point of them in the first place)
9 Likes
Thus why:
If instead of viewing the source directly, we had built in tools to see precisely what APIs and Services it is accessing would allow us to see if itâs performing anything malicious or not. This would then allow us to audit precisely what a ModuleScript does without source exposure. Throw a permissive sandbox system on top of this, and we now have the tools to protect ourselves while being able to maintain private source.
4 Likes
Iâm pretty sure the same applies for any program, unless .dll files in some programs are encrypted to some degree.
The idea that you should trust closed-source code in your game, developed by someone who doesnât have a software license, or thoroughly looked through by Roblox, is asinine. Keeping such a vulnerable and broken feature on a platform primarily directed towards children, is even worse and should be killed off or reformed.
A lot of kids donât understand the dangers of code and how it could potentially spawn in a backdoor, nor do they understand that not everything in the toolbox is safe to insert in their game. A lot of them probably donât know how to sandbox code either. Even top developers have been affected by this, which is quite scary given the circumstances.
4 Likes
People can still update the code without intervention from the developer, just as long as the module has Allow Copying ticked.
3 Likes
Yeah I know but a lot of people dont want to share their code that is what I mean xd
6 Likes
Yes, but most young players will not know how to log obfuscated scripts.
AlternativelyâŚ
Roblox could make it so that scripts inserted under any other container besides nil (where theyâd be garbage collected upon dereferencing by a script not in nil, preventing the plugin abuse) or one where theyâre not visible in the explorer (any of the services besides Workspace, ServerScriptService, and a few others which I neednât mention). Remember back when they removed the ability for scripts to be ran except in those services? That caused an outcry, mostly because those scripts couldnât run in nil, which poses a security benefit rather than a risk. Roblox can do this for us.
The backdoors for plugins are easier to fix than banning private modules entirely. Plus, if we do it this way, developers would have full control of what private modules are running in their games.
The private module removal would also prevent developers like me wanting to be paid to license their code (I know itâs kind of a brutal method of control but itâs better by far than being scammed) to groups and individuals through the payout system and editing/republishing the script with a game whitelist.
Because seriously, the only way these private modules are harmful is that users are having these inserted into their games without knowing, and them being able to run. My solution would work for all games where code isnât carelessly imported through free models, which again, will be able to be inspected. Give the developers more control rather than more restrictions!
EDIT: This is the same issue as the free model viruses, at heart. Keep that in mind.
EDIT 2: TL;DR Roblox should only allow scripts to run in visible services through the Explorer or nil, as well as still preventing them from running in ReplicatedStorage and ServerStorage.
10 Likes
As the update shipsâŚ
Re-reading the last nearly 500 replies. It has really shown that this feature two sides are strong
If this update is truly positive or negative, the final click has occurred.
Whatever you want from this change, to quote @BSlickMusic âHave it allâ
5 Likes