You’re entirely missing the point here, along with a lot of others. Let me give you all an example of why they cannot allow an opt-in feature that’s a bit easier to understand. Imagine a front-page game using a closed-source module doing exactly what it’s supposed to do. Then imagine that all of a sudden this module is updated for malicious purposes, such as rendering mature content in the game. Now, potentially thousands of children have been suddenly exposed to mature content. The owner of the game cannot be held liable, obviously, because they had no way of knowing the module would be updated for malicious purposes. This is the security risk they are trying to get everyone to understand. Regardless of whether you’re okay with the risk, malicious code affects more than just you.
Though I would love an alternative in the future, I entirely agree with the removal of the bug. Yes, an unintended feature is a bug.
Also, please stop flagging posts that you simply disagree with @ everyone. That’s not what flagging is for. You’re just creating more work for the forum moderators.
It doesn’t need to be updated for the malicious code to be there though. That’s like saying a time bomb isn’t a bomb unless you manually detonate it. The point is that you cannot audit the code and therefore cannot prove the validity of it.
Your argument was built off of that statement. Remove the automatic update, and that foundation is gone. You can check validity at any moment by experimenting with it by yourself. The issue is when the creator can push updates at any time to your game without your consent.
That was just a single example. Lets give another. Imagine the module has a built-in Lua interpreter to bypass loadstring being disabled, then loads code from an external service, such as Pastebin. It can then run whatever code the owner of the module wants, entirely unrestricted.
You completely ignored the part in my post where it would be explained to the game developer that the code could be updated at any point without their awareness, and that they must agree to these risks. If they do not agree, then they should not be able to opt-in. If it is explained in great detail in a pop-up, then I fail to see how they can not hold themselves somewhat liable. And, again, I don’t want an opt-in feature to be permanent for the reasons that you stated. Only until we’re provided with whatever alternative they may be planning.
The same risk that you mention here exists for loadstring (which is opt-in). I could easily give away a script that uses InsertService to insert a StringValue that I have created and use loadstring on that value. Sure, people could simply insert that StringValue object from my models and read my code. But I am still able to update that code any time I want, without their awareness, and still expose people to mature content. You can not audit the code if it can be randomly updated by me at any point in time, whether it is initially visible to you or not. The fact that I can change the code any time I want nullifies the fact that you can view the initial source when you first enter the object into your game.
Anyways, the point is that an opt-in solution with built in warnings would, again, not be permanent. It should not be permanent. But it seems to be the best we can ask for until we have some sort of script container object with version control and manual updating.
This, I 100% agree with. It is extremely annoying.
Then they use MarketplaceService to get the description of some model they’ve uploaded and then check for changes to the description every few seconds, then run whatever they get back through their interpreter.
The problem herein is that a lot of developers won’t fully understand the risk of using the closed source module, so regardless of whether they agree to the terms of being held liable, it’s a lot easier for end-users to be exposed to inappropriate content since so many users are just gonna blindly opt in. This is what they are trying to prevent. By not making it opt-in, they are greatly reducing the chances of this happening.
All of that said, I partially agree with your loadstring point, but like I hinted in my response above, loadstring isn’t really required to be enabled to run dynamic code, so there’s no real way to prevent it. They originally actually entirely removed it, but because of backlash from the community, they continued to allow it on the server since you generally know what the code you feed into it does.
I agree that some users are going to blindly opt-in, but the warning should at least make a lot of the users aware of the fact that they’re inserting code that could potentially change at any point to become malicious. A lot of users will definitely tick the box regardless without really reading the warning, but considering that there are alternative ways to make malicious dynamic code (which you acknowledged) I personally think that it’s a fair compromise until we are provided with an alternative feature.
And that’s all I’m really asking for here - compromise.
Like I said before though, you can see what’s being fed to loadstring. You cannot see the code in a closed-source module. I would love a compromise for the time being, but simply making it as easy as ticking a box isn’t the best way to go about it. Maybe if automatic updates were disabled and a Roblox staff member were to review the code before it could be required? It would definitely be extra work for them, but I’m sure it would make everyone here happy.
Someone hires a game developer to script a game for them. It turns out to be a successful game, and it hits the front page. Something happens, and the scripter decides to edit a script and put malicious code in there, such as to generate adult content through guis. Oh, and did I mention the guy who hired the scripter, doesn’t know how to script? I mean, that’s why he hired the scripter. Oh and also, this wasn’t done in a private module. The scripter that was hired made a change to an open source script, and the person who hired them cannot understand the code. Just like you can do to a private module, disable each script (or one, maybe) or delete until you find the problem.
Read my loadstring example - in that example, you can only see what is being fed to loadstring if you keep checking the source. I, however, can update the source any time I want, which completely nullifies the fact that you can read the source initially.
They could, but just as with the blind opt-in problem that we discussed, I guarantee you that a lot of people would simply not bother to take the source and put it directly into their game. For sake of convenience, and me convincing them that I created it that way so that I can periodically update my code for their own benefit, a lot of people just wouldn’t bother (which, again, is the problem that we discussed about the temporary opt-in solution).
This is an edge case and is a problem regardless of whether closed source modules are allowed. Regardless of whether you realize there’s a problem, the damage likely will have already been done long before you noticed.
Then why did you make the example in the first place? Mine isn’t so different than yours. Also, edge? I believe a front page game using a private module (which they have no idea what is truly in it, and doesn’t know who made it) is also an edge case.
Mine is implying a ModuleScript which can be updated at any time, or one that doesn’t even need to be updated in another post, can run malicious code whenever it wants and there’s no way to make sure it’s safe to use. Your example implies someone who had access to edit the game directly put code in that exposed people to inappropriate content. These are very different things, regardless of the similar outcome.
Regardless of whether it’s a front page game, even one child exposed to mature content is undesirable. Mine is not an edge case, it’s a possibility. Yours is considered an edge case because it’s extremely unlikely and caused directly by actions of a developer for the game. If anything, the person who hired that malicious developer and gave them full edit access to the production version of the game is at fault. They were perfectly able to ask someone else to verify the source.
I believe your case is an edge case even more so because why would a top game creator be using private modules which have the possibility to be updated to contain malicious code? A developer can be cut off by being removed from team create, and a private module can be cut off by disabling scripts/deleting them.
Edit: I think I’ve been misunderstanding. I believe my case is more possible than yours. My case is an open source script being updated on a top game to be malicious. That’s what I’m saying.