Too late to remove now.
If you don’t want the risk of external code in your game, don’t use require(assetid).
Same can happen if the module is owned, so not really an argument to remove it.
If you don’t want your module to be stolen, just protect it properly.
I agree, however as I said above. As long as it is not called MainModule. It should be safe.
Then require(assetid) doesn’t work…
local Module = require(game.InsertService:LoadAsset(Id):GetChildren()[1])If it is looks stupid… but it works… then it isn’t stupid.
However, you can set the script variable to nil. That works also.
But not for private modules etc
But InsertService has the limitations that we’re trying to not get for modules.
You can protect the module by setting the script variable to nil at the very beginning of the module.
Literally doing this at the top:
local script = script getfenv().script = nil
Will make it unstealable.
(unless you do dumb stuff like parenting the module, passing that script variable, …)
As Volcano mentioned, that’s backwards thinking. We need a substitute before the current behavior is removed.
Wouldn’t that variable be available through getfenv() though when you return a function from the module (or a table containing a function)?
I did getfenv().script = nilwhich removes it from the environment.
External code can’t access the local variable.
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.
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.
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.
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.
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.
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)
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.
preferably allow linkedsource to be shared across all the creator’s games, im not sure why it isnt.
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.