That isn’t the point. If my code is open source no one would pay for it because they can easily get it for free.
As I said, it is difficult to view the source of plugins. Most users don’t know…
- How to access the Roblox directory
- The methods of finding the right folder
- Importing the
rbxmfile into studio
Also,
- Security is on the developer’s part
- Most users still don’t know how to look for potentially malicious code.
This is technically correct but again, most users don’t know how to look for malicious code.
1 Like
Additionally, we’re not asking for private modules to be kept; we’re asking for Roblox to delay this change until we can get a viable replacement. This way, people who rely on them for an income won’t have negative effects.
Many people, myself included, have provided methods to improve modules and to make them better for everyone.
3 Likes
Yes, if it wasn’t clear before, I don’t want them kept, I just want a viable alternative before they are removed.
2 Likes
That is actually incorrect. Plugins can implement backdoors, not even having to be a private module. They can easily parent an admin script somewhere and boom. No private module used, but a backdoor was implemented.
4 Likes
A patch for irregular places to run scripts was sent out in this thread however plugins can still place scripts in regular places and developers may not notice them. This is why it is ultimately up to the developer to implement security and regular checking of backdoors and exploits, especially now that we have tools provided by other members of the DevForums (e.g., Chrisbru01’s Backdoor/Infection Detector).
However, that being said, most backdoors often use methods of obfuscation and directly require a private script module so that they can be updated constantly (whether it be allowing for more users to use the exploit if it includes a whitelist). Removing private modules is ultimately the most efficient way of removing all/most of the backdoors that games contain.
Then they should let us properly make paid modules we can sell.
1 Like
I disagree; the security of your places is on you, not roblox. You’re dumb enough to get backdoored? Oh well. Solve the problem and don’t do the same thing again.
1 Like
Even though it is ultimately up to the developers to ensure the security of their game, those that don’t have experience in patching bugs will ultimately, at one point or another, end up sending Roblox a massive support email as to where they went wrong. In turn, Roblox gets tons of emails that could in general be avoided if private modules were removed and maybe even help speed up the speed of customer service replies.
1 Like
This update won’t change that. If you don’t have that experience, chances are, you can’t spot potentially malicious (obscured?) code.
Not only is this not relevant to anything I’ve said, but it’s another massive leap in logic. I’ve not implied anywhere that by open-sourcing modules the issue of misuse will be fixed. Of course, it won’t but it’s a step in the right direction for modules as a whole.
Your concerns with the number of people who utilise private modules are wellfounded, I’m with you on that note. I do see how many people it’ll affect, but everyone has been given a fair warning and now it’s their time to form a solution. This reminds me very much of the ‘removal of loadstring’ posts a while back, it’s also those fringe groups (of which I’m part of) who are always against change.
However, about the updates at any time. I’m not too sure since I haven’t taken a look into how LinkedSource works at the moment (as in the past, the source was evaluated in Studio). But if it’s evaluated at runtime, simply having a ModuleScript with the LinkedSource of the module you want to use. Functionality will not change 
.
Re-think what you just said. 
Okay, I’m not sure how much I should disclose but here’s a cool case study that is still running to this day.
A few years ago, a friend of mine published a public module purporting to do something interesting and it does exactly that. But by the nature of their obfuscation it’s practically impossible to tell what is going on, and what it actually does is send analytical information to their google analytics page.
At any moment in time, they can update this module to do whatever they want. I’m fairly sure Seranok will remember this module as it was discussed on the old forums but no one has yet figured out what it does.
By shutting off the private modules, Roblox removes a large majority of the backdoors that exist out there. Most of the backdoors are based upon private modules so most developers, no matter the experience they have with removing backdoors, won’t have to go through the pain of having to track down a backdoor.
Not full on as in that sense. I meant configurable, and I’m pretty sure I conveyed that.
Whether or not someone absent-mindedly uses a tainted module isn’t only on their head. You’re not apprehensive to call others ‘dumb’ despite the fact people DO make mistakes. If they notice that the module itself is tainted and refuse to remove it then, and only then, they may be held accountable for whatever happens to their game.
Roblox provides a safe environment for everyone, despite how many people believe otherwise - to do a damn good job most of the time. Be that with their anti-tamper module (well done ConvexHero, but try harder 
) or by moderating content. So to not mention that this change is a step in their attempts to solving a greater issue is insulting.
1 Like
Again, to SANDBOX even PARTIALLY changes the functionality of modules. Give a good example of something you would sandbox and how it would help.
1 Like
Totally agree with you,
I did not mean to direct that at you in particular, but at the general belief that the upcoming change will remove malicious scripts from Roblox or that free models will be ‘safe’ now. Malicious code will continue to be everywhere that code is allowed.
In the very best case, the private module change will reduce some of the malicious scripts, with inactive creators. The active malicious users already, obfuscated their code and checked allow copy, obfuscation is standard practice for malicious users and they don’t have IP to protect, so the allow copy means nothing to them. The malicious users are interested in the IP they can steal and/or the destruction they can cause depending on the nature of the malicious script.
In all honesty the malicious users win the day with this change as I see it. They remove useful functionality from legitimate creators with little to no impact to their behavior.
2 Likes
I’ve said this way too many times now, but it’s not an intentional feature. No one has claimed that malicious modules will be a thing of the past, but you would now have to analyse whether a module is malicious or not by checking the source. If it’s obfuscated, it could be for any number of reasons and people will be less likely to trust it. What is there to hide?
To this see as a win/lose situation is to reduce the magnitude of the situation to black and white, which it is not. It’s giving freedom to all developers to curate what code they use.