Removing Support for Third Party Closed Source Modules

TheRings0fSaturn · December 5, 2018, 8:33pm

These two things still concern me though to be honest. You sure they don’t function any?

Sceleratis · December 5, 2018, 8:33pm

When it runs, it’s running as a normal localscript. It can’t do anything a normal localscript can’t, which includes things like saving places.

TheRings0fSaturn · December 5, 2018, 8:34pm

Okie dokie.
My apologies then.

I just seen that module, was interested in seeing what it was exactly, and then seen that.

Sceleratis · December 5, 2018, 8:35pm

It’s understandable.

Flubberlutsch · December 5, 2018, 8:45pm

Absolutely not happy with this.

I wrote a closed source module with a huge load of functions and features I commonly use when scripting. Those include table modifiers, HTTP APIs, moderation tools, mathematical tools and a whole lot more. There is absolutely no backdoor nor anything running on this module which would hurt the security of a game.

I’ve done work on other people’s games using this module. It’s a lot easier to do simple adjustments to this module if adjustments are necessary, which honestly is the case at times when Roblox removes or modifies other features, than to have a copy of the code in every single of those games and having to edit each of them manually.

Instead of removing this, as suggested before, giving developers the ability to still use closed modules after showing them a warning is a much better step to do there. You could extend this by enabling developers to only allow closed source modules from certain persons, as well as to choose to prevent HTTP requests from being sent from within the module. This way none of the game’s content could be leaked through HTTP nor could the module require modules written by other developers.

Another thing which concerns me is the fact that I’m currently working on a new game which will be a group game and it uses my module in almost each of its scripts. Many of the functions in the module are a necessity for the game. I don’t know if this system would allow me to require it this way.

Removing or blocking features is not always the best solution, gotta open your eyes there. Roblox has been doing countless of movements within the past year which required me to update my code or which just prevented me from doing certain things and I’m becoming more and more unhappy with each of them.

X_Z · December 5, 2018, 8:55pm

I never used require(id) outside of my own projects, but I am very unhappy with this and feel bad for developers who used this responsibly. Hopefully a better solution is offered in the future.

einsteinK · December 5, 2018, 9:05pm

I once suggested having something like requireSandboxed(module, environment), which would basically just require the module (whether it’s a ModuleScript instance or an assetid) and run it with the given environment as main environment (instead of the auto-generated ones). While it’s initially a lot of work for developers, it’d allow us to sandbox the modules, provide a custom require with whitelist (or inherited sandboxing), sandbox instances to block HTTP, …

Just two issues come to mind:

The script global is unknown for assetIds, so auto-set it? (triggering __newindex, still allowing sandboxing)
Since we can sandbox instances, thus methods like PostAsync, we can log HTTP, which isn’t intended
(either you sandbox it to block HTTP or leave it. but logging it? Developers can’t hide keys that way)
One solution I can think of would be a builtin upvalue isInstanceMethod, so devs can check whether methods are overwritten (and if so, disable HTTP if they don’t want keys to be leaked)
Either that, or some complex way to hide keys for HTTP, but that’s quite specific and difficult

This feature wouldn’t just help with this problem. Could also use it to auto-“sandbox” your modules in a test environment, to run statistics and such

I’ve mentioned this before in a Studio Features request thread about private modules:
https://devforum.roblox.com/t/removing-ability-to-require-non-owned-module-scripts/24522/95?u=einsteink

br_ay · December 5, 2018, 9:10pm

I provide a module which includes a global database where all participating groups can earn money/earn levels, buy wands (with a fake currency) which they can use in all of the participating group’s games.

I don’t do it for money, but still a community of 5,000-10,000 is about to be really messed up over this

I could make it open source, but then everyone could change their own and other peoples data with the database source code.

Love putting years of work (and I mean literal, I’ve been apart of this community for 6 years and I’ve been providing this module for FREE for about two) into a community I care about just to lose it because plugins aren’t being regulated properly/developers aren’t being careful about what free models they put into their games.

Trust me, I understand the security risk around closed source. But it is going to have a large impact on large groups of people, many of who only play ROBLOX for this community I run. There has been a few replies about a new method of private modules. They should be incorporating that Feb 1st, instead I have to leave everyone in the dark which will most likely kill my community.

Sceleratis · December 5, 2018, 9:11pm

This would be a nice feature, but I think part of the problem is most of the malicious modules being required weren’t intentionally required by the place owner, so they wouldn’t be sandboxed using the new function.

Reinitialized · December 5, 2018, 9:11pm

This is a terrible solution, and solves nothing! Not only are you going to limit our ability to protect our source, but I bet this is where the bots are going to go now: VM-based hidden bytecode. VMs such as the LuLu VM make this easy to do, and while you could reverse engineer them to an extent, developers who don’t understand how the VM works will still be impacted! ROBLOX, stop for a second and DON’T DO THIS. Instead, please give us a similar functionality to that of HttpEnabled/LoadStringEnabled with Third Party private modules and warns the developer about the risks. This better solves the problem than removing yet another feature that is extremely useful to those who are legitimately using it. End this by for once not playing a chase of cat and mouse, cause I’m honestly tired of losing features cause someone decided to abuse them

EDIT: And if you are working on some alternative for source sharing, great! Please don’t disable what we have now due to abuse. The above method is a much better “band-aid” fix than yet removing another feature until some time down the road the company is finally able to gather the resources to actually fix the problem. As I see it now, the site is becoming crippled all in the name of some users abusing the features we have, and although it may not severely impact you guys now, one feature you decide to axe cause of similar situations I can almost guarantee will.

einsteinK · December 5, 2018, 9:14pm

Fair point.

But to break it down, these modules get required in one of these ways:

You (the developer) choose to require it (which you could alter to sandbox)
A module you required, required it (sandbox require to sandbox it too)
A Script instance calls it (check source, change require calls for assetIds to sandbox)

Like I said, initially quite a bit of work, but it does allow quite a bit of control too.

Sceleratis · December 5, 2018, 9:16pm

Though most of the people affected by the issue might not have enough knowledge/experience to look in the models they insert for scripts and then decide what should or shouldn’t be there. Which, it can then be argued that’s a bigger problem and it could just be a script instead of a private module, but requires are easier to hide and more confusing to someone who doesn’t entirely know what they’re looking at or what it’s supposed to do.

Maximum_ADHD · December 5, 2018, 9:16pm

Ugh, this thread is derailing about as much as I expected.
I want to make a few things clear here.

NO ONE is saying that closed-source modules are a bad thing.

The problem is that there is no vetting or oversight to these modules. Someone can just load a private module into a game secretly, and the developer never has to approve them, and there’s no way to know whether a module is trustworthy or not because there is no trust system in place.

The system that is currently in place right now is inadequate. Roblox has no obligation to keep a feature around if it is clear that its being abused due to flaws in its design. We’ve seen this before with the removal of loadstring, and the AdService, and now Online-only private MainModules are next on the cutting block.

I agree that Roblox should have some sort of private module system, but there needs to be some sort of vetting and oversight to these modules so that people know what to trust.

H_mzah · December 5, 2018, 9:18pm

I wanted to ask one question about this change - if I upload a module to my group, can I make use of it in my group games without other player’s being able to view or take the source?

Sceleratis · December 5, 2018, 9:19pm

As others have suggested there should be some sort of setting that blocks the use of third party closed source modules by default (like how we have the third party sales setting) or some way to approve specific modules or modules from specific people.

*And/Or some way to limit what those modules can do

Reinitialized · December 5, 2018, 9:20pm

Okay, let me expand my “band-aid” fix: if the script a developer inserts has a private third party module, then WARN them Everytime about the module and it’s risks and REQUIRE them to accept the risks on top of the similar requirements to how LoadstringEnabled works on the Server. I just don’t understand why we can do this with LoadstringEnabled, something I’d say is simiarly as bad, but not with Third Party ModuleScripts.

einsteinK · December 5, 2018, 9:20pm

Well, at that point, people could just have the backdoor in the script itself. My idea (and forcefully open sourcing private modules) just allows developers to check what they use. If they choose not to…

br_ay · December 5, 2018, 9:22pm

Maybe introducing that the same time they remove the current system would be more effective.

Some of us are heavily dependant on closed sourced modules for our communities for features such as global data stores.

TheRings0fSaturn · December 5, 2018, 9:23pm

LinkedSource should be able to replace that I think.

Sceleratis · December 5, 2018, 9:27pm

I’m in support of allowing people to know all code running within their game and providing better controls on anything spooky. Aside from getting the game owner to look through scripts and change stuff, another issue with sandboxing is the module could say it specifically needs stuff like HTTP access or whatever else and would then be given it by the place owner anyway while the place owner just blindly trusts that it’s doing what it says it’s doing.