Creator Marketplace: Improving Model Safety

This update has to be even dumber than the audio update, both updates could have been taken care off differently and better lol, litteraly, just put a warning when they insert a model notifying them it has a require() or a getfenv(), if they still insert it and there happens to be a virus in it, thats THEIR fault, you can’t just destroy the platform for developers because of a few foolish people on studio inserting virusses bruh

You can’t seriously expect a popup warning to prevent something from happening. Who’s fault it is isn’t going to matter, its spreading malicious code.

You can’t expect a 9 year old kid or even their non-coding parent to have any idea what getfenv(), require(), etc. even mean. Oh, so some library items are fine to click through that warning and some are not, which ones are fine?

A warning is not a solution.

Thank you so much for the feedback on today’s update. After reading your comments we realize that our initial announcement wasn’t as thorough as it could be. We want to take a moment to address some of the concerns we’re seeing.

These changes are focused completely on the Creator Marketplace. Assets that include the use of these features will not be included in Marketplace Search. We are not disabling any functionality nor are any assets currently using these features being removed or moderated.

These changes are part of an effort leading us to a future where Marketplace Search contains assets that we feel confident are safe for use and you can feel confident in as well.

We appreciate your feedback and will continue to monitor this thread.

28 Likes

Speaking for many others who share similar interests as I do, this update is terrible. Many of us upload modules to be required which depend on other modules that are required and many of us have custom sandboxed elements to allow for a much more customised lua experience. I can provide a simple example:
I wanted to rewrite the math.sqrt function to work for all numbers and not just real numbers (as well as add an nthroot function to the math library), keeping all the functions within the math library for ease of use. To accomplish this, I must utilise setfenv in my script to set a metatable on the current script’s environment, allowing me to replace math.sqrt with my own custom square root function. This works, but with this new update I cannot publish this to the creator marketplace without getting banned (if I wished to do so).

This update simply is much more punishing for all developers as setfenv/getfenv and require are the two most lenient functions, allowing for the coolest stuff to be made in roblox lua.
The best way for this to be handled it to warn users about a potentially harmful module using a trained algorithm. Removing after detecting with the algorithm would be a mistake as false positives may be a thing. This fosters creativity through encouraging the use of setfenv/getfenv and require, whilst also protecting those who are genuinely about to insert a virus into their game.

2 Likes

If Roblox really wants to make their creator marketplace better, they need to work more on providing logs for what the scripts in a users game is doing, instead of outright blocking developers ability to use these features.

A simple page of ‘audit log’ style script events, such as
‘Workspace.FreeModel Car.Script’ has used ‘Kick’ on ‘BlarBlix’-------------- [ disable ]
‘Workspace.FreeModel Car.Script’ has used ‘require’ -------------------------- [ disable ]
‘Workspace.FreeModel Car.Script’ has used datastore scope ‘k1234Ga’ - [ disable ]
‘Workspace.FreeModel Car.Script’ has used httpservice for domain ‘hehebloxbuilder()com’ - [ disable ]

and clicking disable simply removes/disables that script in your game for you.

I mean, Roblox did say they would work on sandbox style for scripts ever since they removed closed source modules… probably for exactly the same reason they’re now restricting new developers from making tools that can self auto-update and letting other tools like Adonis slide by anyway.

December 2018.
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.

Good-bye to auto updating modules incase Roblox does an update. It’ll be up to the game developer to re-insert a module, maybe twice, four times even, anytime Roblox breaks anything.

And if Roblox really doesn’t sidetrack for at least ONE BIT. I really don’t see Roblox listening to the community at all. They’re just doing quick fixes to fix the issues of backdoors at hand, instead of focusing on the people who got affected and helping them with better and easier tools.

Instead of blocking users from being able to do something. Maybe make it easier to know what that something it’s trying to do.

6 Likes

I personally use require(id) for version control in my matchmaking service. I feel retroactively doing this to pre-existing models is very harmful. Why not just allow creators to block an id-based require at a lower level in their game… We have the option to disable marketplace for things we don’t own why not just add another option “Allow require(id) syntax”

1 Like

Your response is appreciated, but it doesn’t really give us anything really positive enough to change our opinions all that much.

I haven’t heard of any lawsuits lately, so I can’t imagine this update is being forced upon us for that. I think it’s a bit absurd to only give us a day, if that, to do anything about it. From looking through this thread, I’ve noticed that a lot of people rely on require() and even getfenv for tools and such.

From what I can tell, this has been your only response on a thread that already has 120+ reactions to it. We should be getting more transparency than just this one message from a staff member, but I suppose it’s better than nothing probably.

Your statement still doesn’t say that “we’ll consider looking into more options”, because I’m sure that’s not even being considered at the moment. We can’t really get comfortable with an update like this when it blocks people from uploading models that use require() or getfenv entirely. Just because some idiots decided it would be “funny” to abuse those two things to make and put malicious scripts in models doesn’t mean we should all suffer.

The title doesn’t help either as it makes it sound like this update is helping us, when in reality it’s restricting us more than anything. The mostly negative response should be a red flag, too.

In the end, the only ones who are winning are the people who are doing what you’re trying to prevent. We’re certainly not winning, even if we’re supposed to be.

7 Likes

Warning or not, just removing another feature because malicious people are using it is not the answer.

They already did that to private modules, said they would bring it back. But uh, that been since 2018 and no solution brought yet.

3 Likes

Roblox is furthermore making developers that want to make amazing tools without the fear that other users may copy their code and reupload without their permission; to do more substantial and riskier things to get their tools to continue working, even working against Roblox Staff’s ability to ensure your code itself isn’t malicious.

I’m already having to consider loading my code that I want to share with others… through HttpService and api keys. Now Roblox would have a really hard time to be sure I’m not using my work maliciously even when I don’t intend to do it this way, but was forced by the upper hand at Roblox to do it this way.

Roblox doesn’t have an easy method at all to report people that are re-uploading their scripts, tools, and even entire games, for copyright infringement. They only care if a lawyer gets involved etc.

Roblox simply needs to bring back private modules for users that have ID verified their account. That would make the community back to being a happy place, Roblox Staff can view code on their end for moderation purposes again, and code obfuscation on the marketplace can be frowned upon and eradicated from Roblox at once! Make another perk for making people verify their age on Roblox!

bring it back, bring it back [closed modules]

My two cents: In around 2013 or 2014, before filtering was a required thing (probably even before it was an optional thing, but I forget at this point) people were inserting malicious images as billboardGUIs attached to the baseplate in a few of my games. I happened to find the source of it in a free model, turns out it wasn’t an imagelabel or anything but rather an enormous amount of Frame objects of every individual pixel.

Folks like that will find any way they can to continue causing trouble lol

As for the actual topic and what’s being changed, I learned how to script in 2011 and never bothered to keep up to date, I have no idea what fenv is and have never used require. As for obfuscation, I kept all my games open source for the longest time anyways so that’s irrelevant to me.

As for plugins… is the original method of a text document inserted into your files still a thing? I had a bunch of simple “push button, apply modifier to everything in Selection:Get()” things I had written to quicken my workflow a bit, but without them I simply do those things manually.

I’m not entirely sure how relevant several of these questions are to the topic at hand, as I’m still super rusty (I left for a few years when legacy voxel terrain was removed as I had a whole project built around the one use case smooth terrain doesn’t cover) and have little idea what half these terms in the topic mean, but I figured I might as well ask.

1 Like

Thank you for your input on this. I wanted to say all of that and now I don’t have to. At least this isn’t as bad as completely removing all functionality of these things entirely, but it now forces creators to rely on work-around methods if they want their assets to be public.

Actions such as commenting out requires may be necessary to get our assets back into the Creator Marketplace, and I have found that there are quite a few new developers who have absolutely no idea what they’re doing in Studio. This will mean that I have to answer more DMs, make more tutorials, and help people with simple things that shouldn’t be necessary but are because Roblox has imposed these restrictions on us.

This update is actually worse than the one that removed support for private sounds over six seconds in duration, because in that instance, it was done out of a desire to protect the creator’s intellectual property and prevent audio theft. In this instance, this is a restriction on developers who want to do exactly what Roblox was intended for - sharing their unique ideas and creations with the community in order to help everyone learn and grow. This is a hindrance to Roblox’s own efforts to make the platform a place to share creations.

2 Likes

getfenv and setfenv allow the modification of a function’s environment. You can use this to easily edit a function for a variety of reasons, whether it be for code protection, metatable data, or any other various programming aspect. The fenv functions are critical to many developers, and I have a friend who constructed an entire admin system on the function getfenv. Deprecating these two functions will cause a severe negative impact on users like her. :frowning:

And I believe you’ve already seen everyone else’s reaction to removing support for require(ID) and why that’s not a good idea, either.

1 Like

Yeah I got the gist of what the fenv functions are used for from reading posts between my own and the one I replied to, specifically one about replacing math.sqrt with something better. I can see why that could potentially be a backdoor.

As for require… I still don’t understand it, but that’s probably because my entire workflow is super deprecated. Why use R15 and animation objects and stuff when a bunch of spinning Motor6Ds from 2008 still function? (Visual fidelity is, admittedly, not my strong suit)

1 Like

The fact that Roblox is threatening to terminate accounts that hide code is also extremely worrying to me. One of the main reasons that I obfuscate public code is for exactly the reason Roblox wants to prevent from happening - someone publishing a false asset with malicious code in it. Without the ability to edit my code, people with bad intentions will be unable to re-publish it under their name with potentially harmful code.

Additionally, our intellectual property rights basically just got thrown out the window.

2 Likes

This seems like a pretty lazy solution when you could’ve taken other steps to prevent players from inserting backdoors into their games.

4 Likes

Roblox will not bring this feature back, unfortunately.

This is simply because they want developers to be able to see and read what code is running in their game.

I understand the whole market behind selling your systems with closed-source code, however this is not viable on Roblox, due to an open-source initiative around marketplace code.

2 Likes

Roblox needs to focus more on the issues of Plugins… Not free models…

It’s way more lucrative for malicious users to get users to install their plugin on their studio.

As then, instant ease of access of opening a place and auto inserting a backdoor.

Sure, users may ignore the ‘allowscriptaccess’ warning as I’ve seen some users do with no regards. They want a paid plugin, for free…

Maybe instead of punishing people giving away free tools and scripts, blocking their access to require etc, why not make plugins required to have a verified ID to publish and share with other users. Malicious scripts aren’t only coming from the Creator Marketplace (free models). Unless are you saying Creator Marketplace includes free models and plugins…?

6 Likes

I feel like a better solution to this than not allowing them to be seen would be to only allow modules to use require(id) on modules uploaded by the same creator…

This prevents the long require chains that malicious modules use and still allow devs to require their own modules. It would be fine to hide modules that require modules not by the same creator, but I feel using require(id) on a module owned by the same creator would be a much better solution than a blanket hide.

Of course this means every module required in script to know the owner of the script which is requiring it and the owner of the module its requiring and if it’s not the same for all scripts it’d be denied.

4 Likes

I don’t think that people understood this post very well, staff said assets using one of these features will not show up on marketplace searches, nothing is getting removed and you can always access these assets with their links. I don’t think that anyone does a marketplace search for open source modules, we find their links and get them from there anyways because of fake publishers so I’m not sure why people made this a big deal. This is a change which is mostly for beginners and I think it’s a good change.

6 Likes

Make people who are certified creator, or ID verify can bypass some rule, they produce good content so why stop them by stupid rules…

1 Like