Removing ability to require non-owned module scripts

Third party private modules are starting to seem less useful and more sketchy.

I made an argument for them last year based on IP enforcement. That argument doesn’t work because there’s no official channel for making money through models, so IP enforcement isn’t useful for them.

There isn’t a legit reason to hide stuff in code that you’re giving away for people to use imo.

Distribution control.

1 Like

No. The module is an attack vector currently modifying games against the wishes of creators and purposefully hiding itself from them. The model is also an attack vector but is currently not attacking anything; you are falsely conflating the two in my argument. The chair is more than bricks, it is an inventory slot that can be updated at any time and inserted into games.

Models have been malicious in the past and there is no reason this will change. Remember when people were randomly getting teleported from games into these baseplates and generating millions of tix?

In that case, the model was a teleporter created by roblox. It had all the properties of a malicious model:

  • able to be inserted in the game
  • able to be modified to create malicious behavior

and malicious users did both.

The chair model has the same qualities:

  • the chair is able to be inserted in many games (due to many people owning it)
  • the chair can be modified to create malicious behavior (by updating the model)

So does the admin script:

  • the admin script is inserted in many games
  • the admin script can be modified to create malicious behavior (and is currently modified to create malicious behavior [and has been modified to create malicious behavior in the past])

The only thing the model attack vector is missing is one insecure remote or one InsertService exploit and it can be inserted.

Technically, all models owned by other people are attack vectors, but this on the small scale I have not seen nor heard of. The widespread dissemination of the chair model is cornering because it greatly expands the umbrella of potentially-affected games, and given the current situation with the admin script, and the past situations with the admin script, I find I would rather not take the chance that nothing will ever happen with the chair model.

For what it’s worth, I apologize for my earlier unsavory comparison.

1 Like

Didn’t they make it only the server can use LoadAsset? If so, it doesn’t matter which models are in the creator’s inventory, as they can only be inserted from the server, which would only happen if there’s already malicious code present anyway.

1 Like

Not sure why the module is the problem. I could dynamically insert assets through InsertService in a regular script. You could argue that with a script you can tell unlike a closed-source module, but the people affected aren’t the type to check (or even understand) script source.

The problem is that third-party scripts have full access to the game, public source or not.

1 Like

Modules and models are both attack vectors, but this module is being used as an attack vector. The same person or friends of the same person controls the model that is being widely disseminated, something that is also an attack vector. I believe there is a decent chance, based on previous situations with the module, that the model will be used maliciously in the future.

@einsteinK yes, but there are supposedly hacks which allow execution of code as if it was server-side. Maybe these days are gone completely, but I will not bet on it. I did also mention insecure remotes, which are not malicious but are an attack vector.

I’m pretty sure there currently isn’t an exploit to run serverside code in an empty place, FE or not FE. There might be insecurities with RemoteEvents, but you must’ve been doing very weird stuff to have a Remote that allows running code on the server (or requiring/loadasseting any model)

I am not running any code to insert arbitrary models because I know they are an attack vector. I also do not own the chair model. The same cannot be said for everyone on ROBLOX.

1 Like

Unless there’s actually a way to insert it into those users their games, it’s quite harmless.

Perhaps I am being too pessimistic or paranoid, but I do not believe the inability to insert it into people’s games will stay for all time.

On the contrary. It’s been an ongoing trend over years to decrease the power of inserting models. Long ago, a client could insert any model on the server. Now, it’s pretty restricted:

There’s also this planned: https://devforum.roblox.com/t/upcoming-change-insertservice-will-no-longer-auto-replicate-instances-to-all-clients/54187 that’ll even block the “run serverside code on LoadAsset without even parenting to Workspace/ServerScriptService on LoadAsset” thing.

I’ve seen @ConvexHero mention roblox might think about better support and security for third party code. (from his descriptions, seems like an official NPM-ish thing for roblox is what he has in mind, which would be very nice) Could take a long time before those functions and/or security things are implemented, but it doesn’t seem like the trend of “more security, less ways to load (unauthorized) external code” is about to stop, let alone revert.

2 Likes

I was referring to illegitimate methods.

ROBLOX is getting pretty good at not having security holes, but some have appeared in the past and some may appear in the future, which is my concern.

Maybe InsertService will go away forever at some point? I will be sad, because I know several communities that use inserting models as social features, but I won’t worry about models being an attack vector outside of social engineering.

What methods would that be?

Hacking, mostly. There may be no hacks able to insert models currently, but there may in the future despite the good work ROBLOX is doing. Things unimaginable like the bad server from September 7th to 9th.

I don’t want anyone to have any pleasure from modifying ROBLOX games en masse to distribute a model which in the future is used to have fun in or destroy specific vulnerable games, whether the vulnerability is on the game creator’s side or ROBLOX’s.

Or have any pleasure from modifying ROBLOX games en masse for unexplained reasons period, which is currently happening.

1 Like

With FilteringEnabled (also being checked on the server), I doubt there’ll be an exploit to insert stuff on the server.

The bad server thing from a bit ago had nothing to do with InsertService, or even anything in-game. They found a way to start an unprotected Team Create server for (some) places, which they then connected to edit the game. That’s a lot different from executing any kind of exploit in-game.

1 Like

Given how prolific model/place copying is, require() is one of the precious few ways to protect our source code from plagiarizers. Not to mention it makes remote-updating blissfully simple. Find a solution that doesn’t ruin the lives of countless scripters, please. Thieves shouldn’t prosper off of our hard work. I know information wants to be free, but some scripts absolutely need privacy to remain viable.

1 Like

That point is flawed. It does not stop people from doing things like these.
The issue comes less from the open/closed source aspect and more of how confident the developer is in the models. I would also like to add that as opposed to modules, which can in one way or another be seen by at least someone even if ROBLOX Staff, there would be no real way of retrieving this source, unless with a decompiler, of which are somewhat rare now anyways, but the point is that with this approach, not only would someone be completely untraceable because the style is lost in the code, but it could case even more damage if just used in a script, as it seems “fine” or as if it were just any other open source script.

Yes, the code provided in the first sentence does perform the same function as the one in the screenshot. And it does so via a little thing I revamped/remade not so long ago.
If we’re going to try to keep our source safe then we’re going to move in to other things. Removing modules will if anything worsen the situation and cause people to use more cryptic things to make their code just that, theirs.

Closed source is fine. Closed source + extremely vast dissemination + updating on a whim is a recipe for trouble, one that is currently being brewed. There’s always the risk that someone will abuse this combination, and guess what, someone is.

I don’t want models nor modules to go away, but there needs to be some action taken on the current situation lest people realize it’s A-OK to do whatever they want to other people’s games against their will, especially with steps taken specifically so game creators do not notice the modifications.

You absolutely missed my point. What I’m saying is at least if something goes wrong in modules, the admin can take care of it, read the source or whatever and dish out punishment.
But what will you do in the case of my example? There’s no point in trying to rid of MainModule, that method can very well do more harm and honestly takes even less time than uploading a model.
If theoretically I were to add

if not game:GetService('RunService'):IsStudio() then
    SecretlyStealGame();
end;

you would have 0 way of knowing, and what’s worse, it’d be too late if you ever do notice.
Once again, modules are not the problem, the fact that people can and will use anything they can to do malicious things is the problem.

2 Likes

It’s server only, but to my knowledge the security surrounding that change was so horrendous it was originally set locally by a fast flag, haha.

1 Like