As a Roblox developer, it is currently impossible to publish modules that are both trustworthy and secure. The current Module system allows for the use of published modules that are copylocked by their creator. As these modules are private, their source code is obviously inaccessible to everyone but the developer. As a result, there are lasting worries about using private modules because there is no way to verify what they are doing. There is also a very real worry that a popular free model could inject malicious code into many games because younger or less experienced developers (i.e. the main users of free models) often do not screen models they insert, or are not aware of the security hole a private module creates.
Due to the issues with private modules, people have been understandably hesitant about the entire idea of them. However, these modules do have legitimate uses and reasons for being private such as preserving an IP; selling a product; or even just hiding a url, as was addressed in a recent thread. Because of this, it seems prudent and necessary to update the security on private modules, as they are most likely not going away.
Additional security on module scripts could take a few forms. The most effective and preferred way would be to have a prompt when inserting a something with a published module used within it that would contain a list of permissions that said module needed to function. Think similar to the Android app permission system, where apps are published and have metadata in them that indicates what permission they require (and if they’re not granted that permission, they can’t use it):
The obvious problem with that is that it wouldn’t be supported by modules that are older, and that could break a few things. In a perfect world, permissions would automatically detected from the code of modules, but that is simply not practical. It also would require a lot of restructuring and make the module system far heftier than it as the moment.
A second option would be to have a prompt on insertion that informed the studio user who published a module and provided a description for it. That has the benefit of not hurting legacy modules, though it relies upon users to be honest and to use common sense – something that’s often lacking in people.
A third option is to simply disable private modules from being published to free models. Of all of these, this is the most blunt, but it would work to protect people from malicious modules. It does have the downside of eliminating a few uses of private modules, but there’s a serious argument to be made that private modules do not belong in free models anyways. It could also break a few previously published models.
EDIT: As Reinitialized has brought up in his reply, another fix for this would be to have a checkbox option such as AllowThirdPartyPrivateModules in the vein of HttpEnabled or LoadstringEnabled.
Crazyman32 also brought up the point that version control over module scripts would be good as well because arbitrarily updated and executed code poses a big risk for actual use of module scripts.
Whatever ends up happening, as long as it improves the overall security for end-users against malicious modules, I absolutely support it. Something has to be done about it.
As a developer, my life would not change much regardless of what happens here (if anything is implemented or if nothing is) because I mostly use my own code for things. However, the effect this would have on free model users and on those who publish/sell modules should be reason enough to do something with it. It would also help bring modules into a more modern age.