So your argument is that just because someone stuffed a bomb in a locked box and blew something up in the mail means that now all boxes must be unsecured and transparent? It is the victim’s fault if they get backdoored. The problem is not the closed off script, it’s that we don’t have tools to do proper damage control. Just because one person with a gun killed someone illegally doesn’t mean that all guns should be banned. In a platform of children where you can make as many alts as you please and evade bans almost trivially (in theory) even legal protections won’t matter - they’ll just weasel their way in again. The only way to prevent said thieves is to make the target of said theft harder to steal.
8 Likes
They will leave them private but make them unable to be required except by the person who uploaded them. Read the first post.
2 Likes
Okay, so let’s just analyse what you’ve said and implied. (Just to make this clear, I’m not here to lambaste you.)
Implication 1
Your comparison tells us that you believe anyone who gets bombed was at fault for opening their mailbox.
This extends further, I have in no way implied that to make something transparent will solve the issue as a whole. It creates clarity with developers not only to provide knowledge to all but to also critique misconduct. To compare open-sourcing modules to having a bomb sent to your house is ludicrous and far-fetched, and I’d personally liked to believe it’s just your inability to form a valid argument.
Implication 2
You say there are little to no reliable tools to handle damage done to games, be that in the form of malicious run-time scripts, or studio plugins.
This, in itself, is not entirely incorrect but you are forgetting what the problems are. Assuming there is a script which causes a significant amount of carnage to a game (also potentially hidden), the easiest solution is to revert the place version. Of course, there is room for improvement, maybe including more permissive version control (the same way git allows you to ‘blame’ a source-file and-or person).
Implication 3
This one isn’t even much of an implication it’s just foolish logic and a ruse: to suggest that guns should not be banned is a political topic that IS widely debated. This point falls flat on its face, and there’s no way you can back that up without coming across as just a little bit misinformed.
Implication 4
Banning is the solution to theft
We are not talking about theft here, to use someone’s code without permission is not in question here. It’s wrong, full stop. The point of licensing isn’t to prevent theft, because if your module is open-source it is by nature public domain and you can only decide how it’s used and whether you are credited for it.
You have grabbed the wrong end of the stick and are now trying to justify why you are right.
As a final point, I want to make this abundantly clear just because your module is closed-source does not mean it’s immune to theft. If anything, you’re just delaying the inevitable.
1 Like
First, yes; the jump was intentional and I am fully aware of it. It was intended to be ludicrous. Secondly, I was alluding to that exactly; sandboxing is the better solution. Third, yeah, that was a parallel to the first that went askew. It was intended to effectively say that “just because some people abuse the hell out of private modules doesn’t mean the feature is bad”. Fourth, my code should not be public domain if I don’t want it to be - and I should be able to sell access to whomever I please. Fifth, I realize that private modules are not infallible. However, they are the best we have right now and make it hard for many of the immature kids to spam repost our modules.
Sorry for the edit, apparently I hit a weird Discourse hotkey or something.
2 Likes
I haven’t forgotten about them, they’re monetisable for a reason but why aren’t modules? It’s designed to work that way, as I alluded to earlier - it’s a feature which has been (mis)used and is now coming back to bite people in the ass.
Concerning the assets you develop for ‘Roblox airlines’, that’s entirely fine. People do sell art services and such outside of Roblox, it counts as a form of employment (for example, building maps, …). But those work on a personal basis. As soon as you do that service and they pay you, they own whatever it is you’ve made (or at least the rights to use it), that does not apply to open-sourced modules which begs the question. Are you talking about general assets, or SPECIFICALLY MODULES.
I can’t make any comment against this because I’m still not clear of your context. What counts as a product to you?
1 Like
Sandboxing is impractical. What exactly would you sandbox that isn’t already? You WANT modules to be able to modify the world, to isolate it is silly and does not change anything. You return to the original problem attempting to be rectified.
As for ‘abuse modules’, I’ve never said the feature is bad. For that matter, I used to use the feature to re-implement a rudimentary client-side loadstring in my script builder. What I’m saying is it was an almost unintentional feature.
If you wish to sell your code, do it elsewhere. Don’t do it by making modules. No one is forcing you to put your code into modules if you only need the code for yourself put it in your game and nowhere else 
.
‘Immature kids’, let’s just be clear. If anyone would potentially be using your code behind your back, it wouldn’t be those who don’t know how to script. Rather it’s the people you least expect; those around you.
1 Like
IP Protection
Private modules are a tool that helps allow you to spread the cost of development across a large number of customers, thus providing the desired product at a much more affordable price. By making the ability to copy the source only available to the most devious of users, the non-theft choice is more easily taken.
Abuse
Is there a way that private modules can be abused?
Yes, but replace ‘private modules’ with ‘scripts’ and the statement is still true.
Yes, but replace ‘private modules’ with ‘public modules’ and the statement is still true.
Communities
There are lots of users active in communities in Roblox, important to note, is that this has nothing to do with the games on the front page. The Terabyte petition has been able to show us a subset of this group and will soon cross 200,000 users, perhaps it seems like a trivial number of affected users to Roblox, but to me it seems rather large and should not be ignored.
*Note: The fact that a developer can make updates to a module at any time, as with the petition, is not relevant to this discussion as the proposed change does not alter this behavior. The number of users that will be affected by the proposed changes is relevant.
So we now we have communities including hundreds of thousands of users that end up needing components / products for their places. It’s a lot cheaper for them to buy an existing product, these products are typically available due to private modules. The alternative is to commission a new product be developed just for that community.
There are a variety of products out there with weeks, months, even years of development time invested because this system of selling is available. Allowing communities to get quality products, for relatively cheap. How many communities can afford to pay the full development price? I guess we are going to find out.
9 Likes
Not full on sandboxing, silly! But Pmodules should definitely be able to be restricted as the user pleases and should not be a forced update system.
1 Like
I touched upon this before, but I’ll reiterate it since it’s been a few days:
That petition is effectively worthless because it does not ensure that those that sign it are informed enough to make a educated judgement on the matter. You may as well go out onto the street and ask random passersby if they think that this is a good change. If you provided them with the same sparse details that Terabyte is, they would almost certainly think this was a bad change because of how one sided and demonizing it is. The petition is simply meaningless at this point; even if a ludicrously high 25% of those 200,000 people are informed, that’s still 150,000 people who are not.
And I disagree that arbitrary updating isn’t relevant. The fact that developers can update modules at any time without anyone being made aware or being able to check the source code is extremely relevant to this discussion. To explain why I’ll simply quote Seranok:
The primary reason for this change is that exactly what you are dismissing is the case. Public modules can be audited. Scripts can be audited. Private modules cannot be. This the major reason behind this change. Two hundred thousand people clicking a button on the GUI that appears in front of them isn’t enough to outweigh this serious security issue.
6 Likes
Developers can easily still choose to open source their code if they actually still want to be known for their services. It could simply just become a donation based service, something like Terabyte would be guaranteed to have tons of donations especially at this with the 200,000 users that Terabyte reaches. To continue the service without abuse of the website, they could easily just revert back to the very old version of Terabyte when it was still Trello based.
It is a choice of the developers whether they want to continue the supposed services or not. I am sure that obfuscation can easily cover a developer for quite the amount of time, especially with higher levels of obfuscation. Of course, it could just be passed around for free but you could maybe somewhere in the obfuscation add this line of code that attaches a place ID to an API Key and that would guarantee the service not to be abused easily. There are numerous ways a developer can continue a private module service, it’s just up to the developers whether they want to choose that route or not.
1 Like
The number is only meaningless if you consider it as votes for or against the change.
The relevant part of the number is that this is a minimum number of negatively affected users. These are people will get an error instead of functionality on Feb. 1st. Terabyte has indicated that they will not be going open source so every signature on that list will be negatively impacted. The number gives us a minimum idea of negative impact which is better than nothing. To my awareness there is no measure of the positive impact.
2 Likes
I am for and against this Third Party Close Source Module removal.
For:
Giving unaware developers more safety and security of their Games, Accounts, and surprisingly, Computers.
Against
For those who don’t know or aren’t aware of Terabyte Services, it’s an Application Service that is great for Business Groups. All though they use Private Modules, and they don’t ask permission from every game owner to add petitions and such, it’s a harsh removal. But there ARE some other people who are trying to revive these Application Services, like Universal Services, which is small in the group, but has 300+ discord members, and at least 50 application centers made.
Overall, I think this is going to make ROBLOX more safe, secure, and a healthy environment.
8 Likes
This really says it all. The people who are complaining about how it affects their business module due to the removal of private source modules should think about the alternatives that you can do. For the Application Centre Services, you can simply have people teleport to one single game on join where all the code is which is owned by the developer. Thus, there shouldn’t be complaints about the removal of these potentially toxic modules. I do understand how much frustration and hassle this may cause these users, but this is for the well-being of our community instead.
The other use I see for Private Modules is the hotel systems or whatever. These are a bit harder to deal with as they are meant to be in a game. In this case, they will need to become open-sourced or use some API to deal with these. Once again, there are options for those who are complaining, although it may cause some more programming to be done, I’m sure you can make it work.
Good luck to those who have this issue.
2 Likes
That’s more or less how I feel about it. It’s not a good solution unless you compare it to the current state. I would much rather prefer in-depth sandboxing or a permissions systen for scripts and modules. But unfortunately this is what we have for the moment.
2 Likes
From a developer perspective, sure. However, from a community perspective, these changes will eliminate lots of toxicity from ROBLOX.
2 Likes
What I’m concerned of regarding the removal of private modules is that there hasn’t seemed to be a planned and ready-to-release alternative at all when it was initially announced and that removing this will do more harm than good.
Sure, removing private modules would help stop some of the emerging backdoors but not all of them; keep in mind that there’s hundreds, if not thousands of plugins on the developer library that are created/modified to be malicious, and are used by beginner developers too, not to mention that they have the ability to be updated by the plugin creator by the snap of their finger to bypass it. It has the exact same background concept as a ModuleScript, except that it has an even higher script identity than a ModuleScript, and needs to be manually updated by the plugin’s user (assuming that updating plugins are not automatic). If require() snippets of code can be injected into our game scripts by plugins once they’re programmed to do so, then why can’t they also do the same thing except it not having the injected code require a script, rather having obfuscated or unobfuscated pieces of code, but that’s another security flaw that should be discussed on a later thread.
I think it’s the game creator’s responsibility to find the malicious scripts and remove them themselves, but also with Roblox stepping in to assist as well by going for a less drastic approach and adding some sort of property like LoadstringEnabled for individual scripts that can’t be changed under model upload.
While this benefits the beginner developers and the whole community in general, there’s also a lot of takeaways for the intermediate developers. I feel as if the benefits of private modules don’t have as much light shed on than the negatives based on around half of the replies on this thread. Private modules can be used to secure code against those who intend to use it for malicious purposes; take backdoor-rigged plugins as an example for malicious modifications. Private modules can also vault endpoint URLs, imperative developer API keys and other sensitive information from the public, making it extremely difficult for exploiters if the module is secured properly. Especially if the endpoint is made by you (the developer) and it’s custom with your backend server, it’ll be extremely hard to deal with this change. I do understand that there are Intellectual Property rights stated in the terms and conditions of the Roblox service, but that can simply be ignored, and when it comes to the legal process, it’s too hectic to the point where it’s not even worth spending your time making different reports to different users because there’ll already be tons of rebranded and stolen pieces of your code.
11 Likes
A free model is a free model, there shoudn’t be restricted parts in a ‘free model’
That goes against the purpose of why there are free models in Roblox.
2 Likes
The same thing can be said about games, or audio, or t-shirts. Almost every feature on the platform can be abused, free Robux games (that affect thousands, if not hundreds of thousands, of people), audio that bypasses the automated checks that expose children to inappropriate content, images that do the same as I just mentioned. All of these features can, and have, been abused and exploits of the features have affected thousands of people, but that doesn’t mean you remove the feature in its entirety. Instead, you find a way to fix the problems with it.
Whether the way that people use private modules to sell a service was an intended use or not, it is how people use it. Removing this feature will, no matter what way you look at it, kill thousands of games, groups and business that have been created on this platform. The update will do far more bad than good and, at the end of the day, backdoors will still be in free models and plugins. This update will do hardly anything to stop this, exploiters will just obfuscate their backdoors, or use other means of hiding the code. All you will have accomplished is killing off backdoors and other virus’ for a very short amount of time, while also killing thousands of groups, games and business that rely on this functionality.
Don’t get me wrong, I am, and always will be, all for a more secure system, but killing off this feature with no other alternative is, by far, the wrong thing to do.
6 Likes
Sure, all features have been misused - however, private modules is the only feature that allows for arbitrary code to be run on games without the developers of that game ever knowing.
This opens up a huge opportunity for exploiters - as they can use this to add backdoors to games. This has already been done by many models and plugins and may be happening in many private modules such as admins.
Also, saying that it affects thousands of people is completely untrue. There are no estimations on this and many admins are open source.
Some people may sell products through private modules, however, if cared about their customers they would be willing to disclose the source code. This means that the update also helps customers find the right people to buy from.
I think that this will definitely better Roblox as it means games, and the groups you talk about will be less prone to exploiting and malicious attacks.
2 Likes
Private Modules have been a thing since 2013/2014, why weren’t they removed earlier since there was a period between 2014-2015 when lots of people and large services propped up based on private modules.
3 Likes