Creator Marketplace: Improving Model Safety

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.

7 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…

2 Likes

Maybe add a property to ServerScriptService RequireByIdEnabled like it was done with loadstring (LoadstringEnabled) and make it disabled by default instead of removing every asset that uses this from search?

2 Likes

the 2 blocks are okay except for require. Yes, its mostly used maliciously, But why not just a warning like in the toolbox whenever a model inserted scripts ? I really need the require as i dont want to use httpservice to notify updates.

1 Like

Will this update affect plugins?

2 Likes

plugins, models, ofc. first, they make the audio toolbox ruined, second, they forbid getfenv and setfenv, require. yes these functions are big disgrace we cant use them, these are criminals. kill require creator and getsetfenvs.

1 Like

Regulars do seem to get early access to features if I’m correct?

Sorry if I’m wrong, I just thought that they do get early access to features and get warnings about upcoming changes (e.g. upload limits)

They didn’t use a warning because nobody(well not many) will read the warning and it won’t stop any malicious scripts.

Devs who know the risks and who would understand the warning are already scanning any models for scripts and backdoors if they ever insert something from the library.

1 Like

what about an option to toggle through: Ignore plugins with require and get set fenv, Send me a warning if this plugon has require get set fenv, Remove the plugin if it has get set fenv

Default is remove the plugin.

1 Like

No, we do not unless I missed something.

2 Likes

The node-ipc thing was done by the developer, I’m confident in the multi-member head development team of Adonis not infesting games with malware after a decade of time since the original release EISS. That’s bonkers.

Do you really think the person who made “obby for adonis admin [2022]” really cares to update his game to patch major security vulns? I don’t think you understand the extent to which they matter. A game was hijacked this year, using a vulnerable version, to display free robux advertisements. The developer had been inactive for a year in a still popular game. Without intervention the game may have been Content Deleted, as the game could have been permenantly hijacked through the use of settings.OnStartup, which ran loadstring code (perhaps also in the Adonis env but can’t remember) historically able to be written into the datastore, a behavior which has long been removed now for security.

You can also stop adonis from auto-updating yourself by taking the mainmodule and enabling DebugMode inside the loader, or publish your own copy, as thousands have done, though most are malicious.

The beauty of an open source license is that you can do whatever you want, we’re just doing what’s best for the community at hand.