Wouldn’t that variable be available through getfenv() though when you return a function from the module (or a table containing a function)?
2 Likes
I did getfenv().script = nilwhich removes it from the environment.
External code can’t access the local variable.
3 Likes
We haven’t removed scripts or plugins because it’s too easy to trick people into giving you the ability to run whatever code you want on their game. Tons of free models have fire/virus scripts that spread stuff throughout peoples’ places, and you can’t view the source of the plugin unless you know one of the two obscure ways of inserting it into a place (InsertService or inserting the model file on your computer). Both are capable of putting hidden scripts in your place.
Your concerns about security are unwarranted. If you want your place to be absolutely secure, then don’t use code created by other people. Trying to baby-proof ROBLOX is pointless.
4 Likes
Says the closed-source Windows user.
Using private modules allows me to control who uses what I make. Nobody can redistribute the contents of the module without my permission. The module works fine because the place owners allow it to, and if they mess with anything in their place that causes the module to break, that is of no concern to me. Why does it matter if their game breaks? The people who use private modules made by me are well aware of what they’re getting into, and they’d laugh at your notion that it’s crazy. Better to have a game that you can’t view the source of then no game at all.
6 Likes
You can’t compare private modules to plugins and models because these can actually be looked at. Plugins have an update mechanism that warns you when the content has been updated, and you can choose to review the code before updating. The same applies to models; you can review the content of a model before using it. If you retrieve models from a Set, you can even get a similar update mechanism. I’m not saying any of this is practical, but the point is that it’s an option. A malicious user becomes much less likely to attack through these vectors because of it.
With private modules, the developer is neither warned that an update has taken place, nor can they review the changes. On top of that, they yield complete access to their game without any form of sandboxing. On top of that, the module can be distributed to thousands of users. These ingredients make a very delicious attack vector soup.
The feature doesn’t have to be killed immediately. Once again, it has been shown that there’s a demand for it. However, as long as nothing is done about the security issue, that leaves more time for the issue to be exploited. So, while keeping the feature around for those who use it legitimately, a proper solution should be sought and implemented.
5 Likes
How? Who are the victims? People who don’t look at what they’re inserting? Should we remove plugins/free model scripts too because they can have malicious content that users don’t look through? Are the victims people who know what they’re inserting but insert it anyway? How is that bad? They’re willingly putting it in their game in spite of knowing full well what it can do. If you can’t say who the victims of this behavior are but keep insisting that it’s a security risk anyway, that’s nothing more than baseless rambling.
7 Likes
This behavior is concerning to me because if a user wants to keep the functionality (not the code, the functionality) of their module scripts private they don’t use the normal security mechanism (marking the asset as private), they have to use an arcane mechanism (changing the name from MainModule), which also prevents the author from using it via require(assetId).
I am seeing a lot of good points in this thread, and we’ll make sure to consider (and likely implement) ways of supporting the existing workflows before removing functionality.
10 Likes
We basicly need an option on the site “Allow require by third party” or something.
That would be weird as modules are still just models, making it tricky.
Another solution would be having to call your module PrivateModule if you want it private.
(or instead of Private/Main, use Main/Public, which might break games using third party stuff)
(well maybe you could automate all MainModules being converted to PublicModules, idk)
2 Likes
Thank you. I imagine the best behavior would be that any module should be able to be required from the site, regardless of its name. There shouldn’t be a need to disallow requiring it from the site if the uploader has full control over which games can require it.
The easiest way to implement that would probably be to allow all modules to be required from the site, and make them respect the copylock setting unless the module is named MainModule, in which case they’d exhibit their current behavior. You were about to remove the ability to require private modules, so I’m not sure how much you care about the intuitiveness of that process. Optimally locking a module’s source would be intuitive as well, but I’m not sure that has enough priority to be worked on, so what I just mentioned is probably the easiest way to make requiring modules from the site more intuitive while keeping the functionality of private modules at the same time.
1 Like
preferably allow linkedsource to be shared across all the creator’s games, im not sure why it isnt.
1 Like
Right now, I can go make some private module that contains some functionality desired by users. Assuming they trust me, these users require my module in their games. At this point, I can do whatever I want to these games, and no one will know what I’m doing. Over time, as more users require my module, I acquire more victims.
2 Likes
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