Provide a reasonable alternative to closed source modules

Feature Requests Engine Features
#1

:star: Important Edit

As of 2023, my opinion on this topic has changed drastically and I currently disagree with many of my own points that I made on this thread, and even see some of them as ridiculous, but am unable to delete this topic.

I still think it’d be neat for some way to have closed-source server sided code at the very least in order to create some sort of viable alternative market for some scripters, provided that something similar to the studio plugin permission system is included, but I just don’t see closed-source modules ever working for any sort of client sided code at all.

Please be aware that everything written below was my opinion from 2019, which I no longer completely stand by.

The Problem [2019 Expired Opinion]

As a Roblox developer, it is frustrating to see such a useful feature come to an end due to a few people writing malicious code.

The feature that I’m talking about is closed source modules, which allows users to expand their creativity beyond creating games on this platform. People use(d) this feature in order to create their own applications that would then be sold and used in multiple games.

But closed source modules aren’t perfect, we know that. They definitely need to be removed as they currently exist, but I urge you to provide us with an alternative, new and improved feature before removing support for something that creates its own sub-genre of content variety within this community.

Arguments [2019 Expired Opinions]

These are some arguments that I’ve seen popping up all over the announcement thread. Here’s my take on them.

There are many, many arguments on the original thread, so my apologies if I’ve left any out.

Open Source Argument
I’ve seen a large number of people on the announcement thread jump onto the open-source bandwagon and declare that all closed source modules, or a newer version of it, do not have their place on this platform because “all published code on Roblox should be open sourced.”

The problem with this argument is that it completely ruins business, which is what players are attempting to imitate. Open-sourcing everything sounds like a lovely idea that would work in a world in which you can sell products and not have to worry about people easily taking that product and giving it away to everyone else for free. Unfortunately, we exist in the real world, where open-sourced programs completely ruins business.

Can you image if Adobe were to open-source all of their software and then continue to try and sell Photoshop? Would you buy Photoshop if you can just go to the Adobe website and download it for free?

You may be thinking “but this is Roblox, developers aren’t exactly comparable to Adobe.” Yes, that’s true, but players are trying to have an entrepreneurial mindset. They WANT to imitate large companies like Adobe. That hunger to create is what fuels this platform, and I think that it should be applauded rather than snuffed out.

Web Service Argument

If you can just use some external web service to hide your code, then what exactly is the reason behind removing support for third party closed modules again? Players can and will malicious with this alternative. They can revoke your key at any time, which could completely ruin your game depending on how dependent you are on their service.

No offsense, but the run-of-the-mill Roblox developers that rely on this feature aren’t exactly comparable to Google, either. Having to use a remote webserver to host my code is also a lot more difficult than an on-site alternative. People don’t want to have to jump through hoops in order to develop. That’s the entire point of feature requests - to make our development lives easier.

Also… people have to “Allow HTTP Requests” in order for your external website-calling code to even function. So, why exactly can’t there be a toggle in your game such “Allow Closed Source Modules?” That brings me to the next argument…

Getting Tricked Argument

Okay, but what exactly is stopping people from doing this same thing with enabling loadstring, or http requests for that matter? “I can simply view the source code of open-sourced scripts to verify whether or not the loadstring code is malicious or not.” Fair point. But are you forgetting the entire web server argument mentioned previously? This same trick can already be used to trick people into allowing external web servers to load private code into your game by using loadstring to load heavily obfuscated code from an external website. By using loadstring to execute code read from an http request, the provider is able to change the source at any point and run that code dynamically in your game, which can be malicious.*

Why exactly is it only a problem when we’re talking about closed source modules, then?

Another issue with not being able to view source code is that users can dynamically change their code on the fly in order to harm your game. This is a good argument, but people are already able to do the same thing with the example mentioned above, yet we have a toggle for loadstring. For this, I’d suggest some form of version control.

*There was a huge discussion about obfuscation on the announcement thread. Yes, people can eventually deobfuscate your code and figure out the source (or quickly, depending on how good you are). But this takes time (depends), effort, and an existing understand of scripting. I can’t imagine that players that are using malicious privatized code are entirely capable of deobfuscating that well, if at all. People will pay for convenience. Plus, if it’s a somewhat popular user that was selling the obfuscated code, many people will probably still be tricked into buying it even if someone has managed to deobfuscate the source and is providing it for free. The point is, there are many other ways to be malicious with existing features, yet they haven’t been removed yet. Is it simply because there is a stigma around not being able to view the code? As I mentioned before, you can’t view the code for Photoshop either (at least not fully or easily), yet people still pay for it. You may argue that Adobe is a reputable company and that you can trust their code, and that would be accurate. Which is why, yet again, this is a request for an alternative. I am not asking to keep closed source modules as they are. Allow players themselves to determine whether or not they want to trust third party modules in their game.

Free Models Should be Free and Open Sourced Argument
They’re called “Free” models for crying out loud.

Entirely agreed. Which is why I’m asking for an alternative to be provided before we lose support for closed source modules. if someone uses a free model, then they should be able to view and edit all of the code provided. It is in the name.

Conclusion [2019 Expired Conclusion]

Closed source modules are not perfect. I am not arguing for them to be kept around forever. Instead, I’m insisting that they continue to exist and function properly until we’re provided with a reasonable on-site alternative. They’ve existed for a while now. They can continue to exist until they’ve been successfully replaced or locked behind some sort of enable setting.

49 Likes
Protecting Scripts
Removing Support for Third Party Closed Source Modules
#2

I agree completely. Removing closed source third party modules entirely is a bad idea except when faced with the alternative of keeping them in their current state. If Roblox provided a reasonable alternative – and provided it quickly – it would no longer be a bad idea.

If a reasonable alternative to private third party models were implemented it would enable selling code safely and without worrying about backdoors in public places like free models and plugins.

Heck, if a reasonable alternative to third party modules in general was implemented it would be a massive improvement because as numerous people have said uncountable times (seriously guys it’s been like hundreds of times), the presented removal of third party private modules does not solve the problem. It’s a bandaid solution. More often than not, a backdoor only exists because the game owner does not know about it. This makes third party public modules just as much of a threat as private ones.

Ideally, this alternative would be a proper channel for selling and protecting code and sandboxing for it. As I said in the public announcement thread, there’s more to being a developer on Roblox than making games. Contractors and service providers must be provided a platform to sell from or they’ll make their own or simply not sell at all.

16 Likes
#3

If you are trying to market some sort of software service, do what actual companies are moving towards. A software as a service model where your service you are trying to deliver is hosted on your own site, and clients can purchase some sort of “key” to access the API.

#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