The version control system built into packages would help address this. Once approved you could just review the diffs and throttle the amount of times a developer can publish (for review) a package. Keep as many versions as you want private, but max of one publish for review per day for example.
The biggest problems are packages aren’t production, yet and there has been no indication that it would support keeping source private. (Obviously the reviewers would need to be able to see it)
That is highly incorrect.
I recommend not making assumptions about how Roblox works internally if you do not have the knowledge to comment on that. Stick to the topic of the post.
I really can’t believe people are suggesting moderating modulescripts.
When I used private modules, I quite often had some large modules, and made updates quite a bit. Do you really expect moderators to go through every private module? Please think next time before you post. This shouldn’t be considered, unless you bring some type of bot that can recognize malicious code, but I doubt that would happen.
Even attempting to moderate code in any way is already a nightmare… what approach would you even take? Any sort of human verification would be utterly impossible as it is so easy to hide malicious code already that it would be the joke of the entire Roblox community within the hour.
Any sort of automated analysis (sandboxing? virtual machines?) would be ripe with false positives and would also be completely useless if they decide to add anti-sandboxing measures (which would be really easy to do…)
In short, moderating modules in any way is completely useless and a lost cause the minute its attempted.
I support introducing sandboxing, however it should allow you to toggle everything that a script can access, individually - so that developers have the ultimate control over what the code can do in their game.
This is actually a viable alternative than just removing the feature entirely, or not implementing a system which is like HttpEnabled or LoadstringEnabled.
I don’t support sharing the source in any way - this provides incentives people to plagiarize proprietary code.
The ability to distribute code without providing the source shouldn’t be taken away from everyone - that isn’t right. This is just going to make providing services even harder without some kind of obfuscation.
Please consider adding a system which allows proprietary code to still be protected, while allowing everyone to use the module in their games.
I understand the reason to remove this but, I believe that in the end it should have been the developers choice to either opt in or not. That way it’s in the users hands if they want to stay on the side if they are new to developing and don’t fully understand scripts yet but for more experienced developers to allow them to utilize private modules as they will hopefully have a better understanding and have decided to opt in and use them.
I love the recent updates, ROBLOX, but this?
This ain’t it.
What’s preventing them from just making the module open source? The ones who generally insert these malicious models that include backdoored private modules are the ones who can’t script anyway, therefore, even if they looked through the source, they wouldn’t know how it works and wouldn’t know how to tell if it’s a backdoor, if they even bothered to look through the scripts at all.
This helps nobody, and if anything, hurts those who rely on this as a source of income, or as means to keep their source from being stolen and abused (For example, admin scripts that rely on Trello or other similar services to get bug reports from users, as they can now just spam the service with HTTP requests.)
This doesn’t help anyone, it just means slightly more competent developers can check the source of private modules in models, despite the more competent developers not inserting these models in the first place. The average joes who insert the malicious models won’t check the source due to a lack of scripting knowledge, so the people who make backdoors can just make it open source and have nothing hurting them, except maybe having to take time to obfuscate their discord webhook.
This just hurts people, and frankly, it’s a useless removal. It solves NOTHING, and it’s just another bandaid patch by ROBLOX. As I said, I’ve been loving some of the newer updates, but not this.
It makes it a lot easier to report free models that are installing malicious code into games, if we can actually look at their code, and it makes it so admin scripts now have to be transparent, and can’t just put in code that gives the owner and their friends admin in your games without your knowledge.
Since the code now has to be open source, they can now make a github for their admin script and link in the Open Source Module and let people submit issues and those who like the admin script and find issues in it can make pull requests to improve it further and fix glitches.
It is just terrible that if you put modules on the group and require it in the group that it still gives the warning message that you are using a module from someone else this needs to be fixed asap for groups or have a way to make it work for groups since when they are gonna remove it completely then group games cant use hidden code anymore
I will grant that being able to see the code makes it easier to tell if the code is malicious as opposed to working with a black box. However, you can choose to use an open source project without taking a tool away from the community.
The second part, is not accurate. Regardless of if the module is private or public, if you are requiring someone else’s code via this method they could update that code at any time, without your knowledge. There is no change in this behavior with the proposed change.
There was nothing stopping anyone from making projects open source before and utilizing any of the tools available for open source projects. There are already a bunch out there including one of the popular admins since you were using that as a reference. If you would like an open source project where one does not exist, be the one to start it, but again it is not necessary to take a tool away from the community.
Hello! I had a question about the removal of Private Modules. My friend owns a group, however I dev for it. I have my own closed source modules that I made, and they are being used in the game. You said that private modules can still be used in our own games, but can they be used in other people’s groups that we have dev access for? It would be awful if not because I don’t own the group however I made the place and module script. Thank you.
I had the exact same situation, but unfortunately the answer is no - a group you have edit access for cannot use your closed source module. I was receiving the warnings in F9 logs and I had to publish the module to the group.
Think of the new module restrictions like the changes to InsertService back in 2011. If you publish something under the Group models, it can be inserted at any of that Group’s games, but not necessarily at that Group’s members’ games. You can always send the Group owner a closed-source copy of your module to re-upload under the Group. Only high-ranking members with asset-editing permissions will be able to view your code.
That’s outrageous! ROBLOX really messed up on this one.
So basically I can’t even use private modules in a friend’s group that I dev for. I made the place but I can’t insert a module into it. Absolutely awful.
That’s the issue. I don’t want high ranking members to take my code. But its my game, and I can’t insert a private module. ROBLOX better be re thinking this.
I agree.
I have a model which uses HTTP requests which must be hidden otherwise, well, bad.
I was just thinking, maybe if there was things like that, the model could be read only and the author could decide whether the links were hidden from the client, and whether it works in the editor.
Just a potential thought, but I’m sure there are a lot of things which could be said against it.
I don’t know your story, but I wouldn’t be working with people that I don’t trust with my code.
I understand the intentions behind closing third party closed sourced modules however all it would take if for the abuser of these modules to make the module public and then the game is once again infected. As most users who infect their games with these modules are newer developers who don’t know about what is wrong they won’t check the source code. I understand many developers want to see the source code and I 100% agree but I also believe there is a bar between what should and should not be shared. If someone creates a products that uses things like API keys using HTTP Service they should not be allowed to view those credentials as they are usually used for the serves themselves.
EDIT:
I have an idea, maybe if your game has a closed source module in it when you insert the script with it it will give a popup saying something like “Model includes a closed source module, do you trust?” and from there the developer has control over it without any worries about accidentally inserting a model with an infected script.
Exploiters and the like also have the same mind as the majority of the scripters here, they actually don’t want their source code leaked as well. Albeit, not every exploiter has that mindset but if they didn’t care about their source being spread around, why didn’t they just make it public?
Yes, it might be easy for them to simply make the code open-sourced, but it also makes the rest of us easier to realize that this code is a harmful one and anyone that has the script that requires it in their game is able to do malicious actions within the game.
A warning that pops up when something is inserted that involves a closed source module makes no difference, people will click yes regardless of the code. For example, every time you sign up for an account on a website, you will most likely click the I agree to the Terms and Conditions box without even bothering to look at any of the terms or conditions. The same concept is applied here, many people will simply click yes regardless of the outcome and the warning is thus redundant.