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
I mean, I’m certain developers who develop games on this platform wouldn’t care any. Developers like Stylis Studios & Badimo wouldn’t be affected by this at all.
Again, the idea of selling products on Roblox has never been fully supported, and at one point, it was against the TOS to sell free models. Not sure why the removal of an abused feature would be a surprise to people.
5 Likes
It’s not a suprise, it has been done a lot before, that doesn’t mean however that we agree with it, the TBS petition has over 250K+ signatures (and someone is going to say that they’re players and not well informed, don’t tell this, the players are being affected too), and the majority (currently 71% if I’m not mistaken of the developers voted on the poll above, is against the removal (or want some kind of alternative/replacement/change made instead of the removal)
Even though it may be abusable, the abusable part of it is findable in a lot more things than just private modules, and if Roblox were to remove them all, you could basicly give up on free models in general, maybe even plugins. Private modules (however abusable they MIGHT be) had their use cases, and denying that won’t change anything.
Even though we might get a replacement in the future, that replacement will come too late, taking away something and letting people wait a year will simply kill all the people interested in using that feature (or the ones who already used it), we also heard that other replacements would come which we haven’t heard a thing about (leaderboards for example), I’m affraid that the same thing will happen to private modules.
And I don’t see a lot of people speaking about this, but let’s just remember that bots will profit from a change like this too, they can now freely copy all private modules and add virusses to them
And again, the people who are for the removal of private modules can just not use them, the people against if however cannot just magically remake them.
9 Likes