Removing Support for Third Party Closed Source Modules

#1

Hi developers,

Games can import code modules dynamically using the require function. Currently we allow closed source modules to be used within a game even if the game creator does not have access to the code. This poses a serious risk because models can contain malicious code and developers have no way to audit the code. Additionally, our platform does not contain any sandboxing support so modules can do anything game scripts can do, such as writing to data stores or teleporting players to another game. We have no protections in place for this.

On February 1st, we will be removing the ability to use closed source modules from other creators on the platform. If you want other developers to use your modules, you must open them to the public or publish them under the same account as the game.

Soon we will start showing warnings in Output for games which will be affected. You will be able to use the in-game Developer Console to view these warnings.

Here are the steps to change a module from private to public:

  1. Go to the Create page
  2. Click “Models”
  3. Find the module you want to change
  4. Click the cog icon and select “Configure”
  5. Check the “Allow Copying” checkbox
  6. Click “Save”

image
image.png991x163 20.7 KB

Longer term, we are investigating the following:

  • Providing sandboxing for scripts so that developers have full control over what code they import can do in their game. This may eventually allow us to reintroduce closed source modules once we have put certain safeguards in place.
  • Allowing creators to share code and other assets with specific users instead of the entire platform.
[Private modules] New way of securing code?
Module script open source licencing
November 2018 Recap: Keeping Up With the Developer Community
December Recap: What's Happening in the Developer Community
Diciembre resumido: ¿Qué está pasando en la comunidad de desarrolladores?
#2

I am going to have to hope nobody steals my admin system, re-upload it as their own, and call mine a copy…

#3

Despite the drawbacks, I think this is the right move.
The manpower required to audit private modules is infeasible, and the ability for developers to hide anything inside of a private module is dangerous.

#4

I’d have preferred it as opt-in setting in the game rather than removing the possibility entirely though. That way people would be making a conscious choice to risk it.

#5

This is great news!

#6

@Seranok I’ve been looking everywhere and I can’t find a solid answer, but are LinkedSource scripts guaranteed the same protection as private modules?

#7

This is correct. I was thinking about the requirements before seeing this (i.e. a developer having thousands of lines of code to go through), but there is also the lack of context of where the code would be used. If you see a Lua VM as an admin console, you wouldn’t know if it is for a single game that the owner approves, or if it is planned to be used in something like the current backdoor problem with plugins.

#8

This was the right call. I understand why people are upset with this, but the consequence of allowing private modules is far more significant than just leaving all of them in an open-source state.

#9

I have to agree with Clone here, honestly. Still though, I think allowing developers to tick a flag in their games to allow this feature to continue running would also be a good idea. This doesn’t seem to affect auto-updating scripts for the creators of said scripts in their games which is good in my opinion.

Also, @wravager, I’m pretty sure LinkedSource won’t be affected by this since you’re not publishing the scripts to the website - they’re only in your game.

#10

I asked about their source protection, not if they are being removed.

#11

I have to agree with @TheRings0fSaturn.

I think that many developers would like to see the ability to release creations without their users being able to access the coding. I understand why this move is being made but I feel there needs to be a replacement feature, or an amendment like I will suggest, before it is rolled out.

I believe that the usage of closed source modules should be an opt-in feature. An “allow closed source modules” setting, which defaults to be off, should be available to developers which will allows them to require closed source modules if enabled. A notice about the possible malicious nature of allowing closed source modules can be included here.

#12

Finally!

#13

Oh.

If the scripts are Module or Local, I’m pretty sure exploiters can still gain access to the source, just due to the fact those scripts don’t have any kind of auto-obfuscation or having the characters show up as null and copying that script to a game would render it useless.

#14

You know it’s funny because just yesterday I was looking at a thread discussing closed source modules and a debate based on them. Personally, I have to say that this judgement call was most effective.

Closed source modules were too much of a risk, whether they were being used as backdoors in maliciously botted plugins or just modules at all. We haven’t a clue what code people are running on our servers and that is VERY dangerous. Any code you include in your game should objectively always be accessible to it’s developers. What’s the point otherwise? You can’t see it, you can’t update it, you have no control except inserting or removing it.

Good. I am very pleased with this.

#15

This is gonna cause an issue for anyone who makes or has made proprietary scripts on roblox. It is at the developers discretion to use private modules in their game, if they can’t trust the module then quite simply, don’t use it. Roblox shouldn’t remove this feature entirely.

#16

This is a really smart solution. Thank you so much!

#17

Not necessarily. Have you seen the malicious plugins using private modules to load in scripts that you definitely do not want in your game?

Don’t worry, in the long term, private modules will come back

#18

Didn’t know about the plugins loading in private modules, that is dodgy. The models however are a different matter.

#19

Models do the same thing.

#20

But it’s your choice if you use a model that requires a private module.