Provide a reasonable alternative to closed source modules

Feature Requests Engine Features
#4

I’ve already addressed this in the original post.

1 Like
#5

I don’t see how your original post adequately address the SaaS approach. It simply comments on how a web service could be a threat vector, which in of itself doesn’t make sense, as the problem is due to a malicious agent being able to run malicious code on the actual game.

The problem is that to run the code, loadstring or a module script must be used. By removing ‘private’ module scripts, that threat vector is removed. The loadstring approach is addressed by loadstring being toggled by the end user, so I fail to see how the introduction of a website allows for malicious code execution.

#6

You obviously didn’t read the entirety of my post, because I also addressed the loadstring situation as well. I was hoping that putting everything in the original post would prevent me from having to repeat myself on this thread, but here we go.

Edit: I obviously didn’t read the entirety of my own post, because I wrote in some mixed illogical arguments due to trying to rush this and look for quotes from the announcement thread. I fixed the mistake in my original post. My bad.

That addresses being able to toggle loadstring. If you argue that you can just toggle loadstring on and off, why can’t we have this as an option for closed source modules?

This addresses having to use external web-services and provide API codes. The entire point of feature requests is to make our lives easier. An alternative provided by Roblox would certainly make the entire process much easier.

The way you phrased your last statement makes it appear as if you think I’m arguing to keep closed-source modules as they are, which is not what this thread is about.

1 Like
#7

The difference between the loadstring-approach and a module script is that the module script allows you to hide the content of the code by nature of design. If a user has a script that has a loadstring in it, the user can inspect the actual content that is being loaded by the loadstring. With a module script, they can not do so.

While my primary alternative is through a external web based service, I suppose ROBLOX could introduce an alternative ‘service hosting’ feature for an internal ‘remote API’ for developers.

To address the web-service point again, a module script hides code that will run in-game. A SaaS model hides code that will never run in the game and therefore can not be traditionally malicious.

1 Like
#8

That was completely my fault. I had three tabs up to the main post and was trying to go back and forth looking for quotes to use, and completely messed up the statement. It took me a while to figure out what you were referring to in my post. My bad, I’ll fix that.

The web-service approach is just as unreliable in terms of trusting the host with whatever service you may be providing. They can simply revoke your API key at any time that they desire, which seems fairly malicious to me.

I mentioned this before, but I personally don’t use even closed-source modules are an external web based service. I just upload my code. I’m only arguing for an alternative provided by Roblox because I disagree with the basic idea that is removing a feature simply because some people are being malicious with it, while others are actually using it for logical unmalicious reasons.

Edit: Ah, I see what I was trying to get at now. I’m not exactly the best writer.

2 Likes
#9

Your frustration is warranted. Here’s what I’ll say.

The fundamental problem is that Roblox doesn’t have a sufficiently developed sandboxing system to allow private modules to be individually audited for what permissions they would have.

Implementing such a feature might be a little more difficult than it seems at the surface level, because you have to consider the kind of things they would need to make it viable enough to address the security concerns of the existing feature:

  1. Some proper infrastructure in place for private modules to be represented on the website (not just as Models)
  2. A way for developers to specify the sandbox constraints that the module should have to Roblox’s server, without requiring the execution of Lua code (such as what services it can use)
  3. Some indication that the module cannot be executed offline in Roblox Studio. Perhaps the developer would need to have a public dummy interface to the module for simulating it offline?
  4. A way to notify the developer of what permissions a module would like to have granted before it’s allowed to be added as a library dependency in a game.
  5. An update system that requires a developer to approve the update, and grants them the permissions to rollback if they notice a change they did not want to allow.
  6. Constraints to Roblox’s Lua->C++ bridge that tie all of this together.

Unfortunately, developing such a system isn’t something that can be done overnight. It requires a lot of coordination between multiple engineering teams at Roblox, with careful planning and consideration into all possible use cases.

Rest assured, I think Roblox hears you guys loud and clear. We’ll see what happens next.

14 Likes
Removing Support for Third Party Closed Source Modules
#10

You still have to account for Lua interpreters which may or may not be easy to figure out what’s going on inside of them. You won’t always be getting inspectable source even with these new changes.

#11

Roblox seemed genuinely surprised by the unintended repercussions of this update:

I think what happened was they rushed to a brute-force solution to the backdoor crisis, and exclusively viewed the problem from a game owner angle, overlooking any positive business examples at the time.

3 Likes
#12

I’m surprised #3 on your list wasn’t already addressed from the beginning. Even inexperienced developers would be able to determine cause and effect if they could preview what the module is doing during Studio tests. But as you said, it would require months or even years of work to replicate an external script’s influence offline, especially factoring in updates to it happening in real time.

EDIT: This would, however, defeat the purpose of keeping modules private, since many businesses relied on them to insert models without risk of copying (i.e. Car dealerships). Perhaps it could just print output from that module, i.e. “MODELNAMEHERE has been inserted to Workspace.”

1 Like
#13

It wasn’t my intention to make it seem as if this is something that can be done overnight, so my bad if something I said came across that way.

I really like the idea of an update system where the developer has to manually approve of changes made to the modules. This is how plugins work, and it’d be much appreciated if it were applied to some future version of privatized code, especially if it included a rollback feature.

2 Likes
#14

On the main thread there are already tons of reasons why this won’t happen listed. The biggest reason is that the idea of private modules itself is deeply flawed.

I think you should voice your concerns on there instead of starting a whole new thread…

#15

This thread isn’t about keeping private modules themselves as they currently exist. This thread is asking for an alternative solution to be provided before losing support for private modules.

The problem with voicing my concerns on the main thread is that people keep on replying without reading through older conversations, due to there being over 500 posts. Many of us have to keep on repeating that we just want a Roblox-endorsed alternative. People on the main thread refuse to understand this, and seem to think that we’re begging for closed-source modules to continue to exist as they are.

I was also directed to post a feature request outside of the main thread. The desire for such a separate post was mentioned by several people.

4 Likes
#16

The advantage to this new thread is DevRel Staff is more likely to read an organized discussion in Platform Feedback than 700+ arguments in Public Announcements. Besides, nothing new can be said there that hasn’t already been buried from a month or two earlier.

7 Likes
#17

There do exist threat vectors such as running arbitrary code through custom Lua interpreters. However, I feel like this would simply fall under simple script obfuscation, which is a completely separate problem to module-scripts, as module-scripts are capable of being hidden by design.

#18

That’s fine and dandy, but you can’t just spam the dev forums about this issue either. Especially since you seem to just be parroting stuff originally posted on the main thread in here. It’s redundant.

Yeah it’s annoying to have your comments buried, but they’re being buried by people who are essentially saying the same things anyway.

This doesn’t seem like a feature request as much as it does an argument to keep private modules around, even if temporarily. As such, I think it belongs on the main thread.

Also, I can promise you that Roblox is looking for feedback on that particular issue on the main thread. The posts that have lots of likes are definitely going to be seen. Don’t sweat it.

1 Like
#19

As of today, the ability to use third-party closed sourced modules was disabled. This change has forced developers who operate on a business level such as Terrabyte Services and Service providers(admins, game features) to either open source their work or continue the service for themselves only. This allows no protection of the creator’s Intellectual Property. The benefits of having this feature to be re-enabled, or brought back with modified suggestions, opens the market of service providers on roblox and will allow users to work with the knowledge that their work is protected without worry of being stolen, re-sold, and re-purposed for malicious intent.

Positives of this feature

  • Allows users to have a wall of protection for their work
  • Opens a market for service providers

Negatives of this feature (without changes made)

  • Gives game creator no knowledge of code being ran
  • Allows the module to operate with malicious intent without restraint

Remedy for this feature

  • ServerScriptService to have an option to allow Third-Party code, similar to LoadStringEnabled.
  • Allow prompt to game creators to know that they are using a closed source module, and are responsible for the handling of the module.
  • Allow options to limit the interaction of the module with the server.
    – Being able to use HttpService, able to use Instance.new(), able to interact with the players service, etc
  • Sandboxing
    – Run button in studio, output will log what the module is attempting to do (“Module 1413415 attempted to send a GET request to https://roblox.com”)
2 Likes
#20

This is problematic since it would have to download the module source to the user’s computer, effectively giving up any privacy.

4 Likes
#21

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

  1. 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.
  2. 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.
  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.

1 Like
#22

This would be hard to sandbox, and time could be acquired from external means such as other scripts in the game, their functions, HttpService, etc.

Also problematic to sandbox because of above issues plus the fact that there are multiple api to acquire information about ingame and offline players.

I’m not exactly sure what this means. Can only return nil or bool? Seems very restrictive, and passed in tables can still be used to mimic returns.

This also seems a bit hard to sandbox, mostly because it sounds like it would require constant checks.

1 Like
#23

Unfortunately all of this assumes that roblox has the necessary sandboxing support. Since it doesn’t this is quite a large feature even if the sandboxing necessary to do so would prevent all problems associated with the closed-source code.

At the end of the day the problem is the lack of ability to audit the code to ensure it does what it claims to do and what the developer wants it to do without doing anything the developer doesn’t want it to do. Without access to the source code there’s no way to audit the code and verify it does what the developer wants.

1 Like