I have come up with a fully effective, yet potentially cumbersome for the end user proposal that might fulfil this feature request and would also be highly useful to me, so I will describe it as a reply to this feature request.
Objective
Providing a method to implement closed-source modules effectively and limit bad actors’ capabilities. Previously, closed-source modules would allow for code to run effectively and quietly, allowing for malicious individuals to add code to a free model that would allow for the owner to use functions unintended by a game developer, such as a lua interp, an admin script, or something that wipes DataStores/kicks all players.
Motivation
Their removal incites other issues, however. The only alternative to keep code away from prying eyes and copiers and pirates is obfuscation. The code will also, unless a way to shutdown/punish places who have copied/inserted the code is implemented, be able to be copied even if it is obfuscated. Any malicious actor could obfuscate their code heavily, and since it would be doing something that has no time/value, they would not have to fear it being copied except by other malicious actors. The flipside of this: Anyone offering a service or script who obfuscates it will have great value within their code, and then there IS great motivation to obtain it, no matter the cost to themselves. Especially if they’re able to compromise a webservice or read an anti-exploit system to work around it. No one explained this upon the private modules’ removal, and I just now had the revelation when detractors were saying “just obfuscate it.”
This does not solve the issues in either option. Despite closed-source modules being an unintended feature in the first place, now services will be targetable. Despite closed-source modules being victims of particular bugs that would allow source code to be stolen, this post will be about something different.
ClosedScript
Allow me to introduce to Roblox the ClosedScript. This class, while it can be created with Instance.new, will have a LinkedSource property (could use something similar to the current model of gameasset but it would use the script’s unique ID for the URL) that contains its code. ClosedScripts and their LinkedSource property especially are not replicated across client-server boundaries. ClosedScripts must be bought from the Library page for Robux on a per-game basis which will also allow monetization directly. The escrow period will be seven days, and the user can request a refund on the item’s page during this period, and a few restrictions will be put in place upon these scripts to prevent timebombs, etc. They will also not be re-publishable as to prevent more timebombs. These ClosedScripts will only be serverside, as private modules always were, along with public ones.
Important restrictions on the feature
- These scripts will not be able to use any function giving absolute time. This prevents code from being activated a la timebomb. This might cripple scripts that need to date things, such as scripts that use datastores/headers to send to servers, and could be worked around. Unless restriction #3 is in place.
- Player’s UserIds would not be accessible on a ClosedScript. This would kill off most backdoor exploits that would require (no pun intended) the owner of a private module or whatever to have them be able to use an admin panel or whatever. This further emphasizes the compartmentalization required by the producers of these scripts, as per Restriction #3.
- These scripts will only be able to use void or boolean functions from ModuleScripts. Any other return values would cause the module to error “Cannot get return value” Also, whenever a ModuleScript is required by a ClosedScript a warn message would happen informing the developer of the ModuleScript’s ID. This way compartmentalization could be performed: a modulescript solely intended for interacting with HttpService that has the ability to date the request could be a publically published ModuleScript. This way there are no workarounds for the above restrictions. Please note that ClosedScripts will still be able to access HttpService but this block of ModuleScripts, changes, and time functions is solely intended to make these scripts timeless.
Functionality
ClosedScripts would work precisely like modulescripts in every other functionality, and can be published by mouse button 2 on a modulescript->Publish as Closed. You can set the price from here (or make it free if you choose, your code still gets protected)
These little bitty classes, when they’re inserted into a game, would alert a player with an error message that would specifically tell them if they bought the script, whether it exists, or no error message unless it propagates out of the script.
Pros
- Stops all of the current backdoors (timebombs, lua interpreters, and admin panels) in their tracks, and many more potentially
- Sounds very straightforward to create, and a wiki article could be written all about them
- Monetizable very directly, charging up front on a per-place basis for the scripts could make sense.
Cons
- If a ClosedScript has a bug or becomes obsolete, the user would have to refund it
- If a ClosedScript’s bug appears after the 7 day refund period to an end user, it would not work out well for them because they could no longer refund it
- Requires just as advanced scripting knowledge to understand, and potentially some brute forcing to get the functions out of the return module (which being forced to use specific functions with long names could be a plus to lock services behind an additional barrier but is unnecessary for end-users at this point)
- No modifications can be made to the scripts after publishing to add new features
- Like obfuscation, would leave users vulnerable to chance-type exploits which will do something like show inappropriate content to specific random users in a server
Potential compromises
- 2/3 of these could be fixed by using something similar to the current LinkedSource browser where one can revert to the last published version of a script, as well as update them manually off of the published version, with no notification, this could be repeated
- This leaves the user open to a timebomb exploit however, so they should be warned first that the script “could function better or cease to function as you intend altogether”
- As these scripts would be specifically server-side, disabling GUIs from replicating from client to server in some way would fix one of the issues, although it might make it much harder for newer users to start using GUIs as many have
Sidenote
This is a followup from my “ModuleScript Marketplace” idea fleshed out drastically, with added details on the current alternative method (obfuscation)'s flaws. (and no, this time, it won’t involve negative robux at all) As far as Roblox is concerned, any alternative method of IP protection would fail, any form of IP enforcement would be too expensive and time-ineffective, so this suggestion is meant to bridge the gap of safety completely for third party closed source modules as far as I’ve seen the complaints (summed up to timebombs, lua interps, and admin panels for any malicious use), and reap the benefits to the fullest extent (even if it means restricting their ModuleScript use and ability to tell time).
Conclusion
If care is taken as to prevent people from accessing the code from these then many will love to get into using them in the near future, as making a game appears to be always a dead-end route for some most others, midway through, and short scripts or services made for others have always been the way to go for many. If you could advertise these too… The conversion potential would be very high, and Roblox, both the corporation and its userbase, could profit.
Thank anyone who’s read the whole thing for reading it.