The Creator Marketplace team is dedicated to helping developers easily find safe assets to accelerate building their creations. As part of this, we’ve helped lay a solid foundation of safety measures and procedures designed to make the Marketplace more useful.
In our ongoing efforts to tackle both new vulnerabilities and existing malicious content, we are announcing changes to make Marketplace even safer. Starting today, the following three APIs and techniques will no longer be allowed in assets shared in the Creator Marketplace.
getfenv/setfenv
These functions are often used to obscure the engine features being used in a script. In addition, these functions are already in the process of being deprecated in Luau.
While this API can be useful for auto-updating assets within your experiences, the majority of use cases in public models are malicious. A model that may look useful on the surface, for example, could load another “virus” asset at runtime. This change will make it easier for developers to understand what functionality each model contains.
Obfuscated code
For publicly-shared assets, it is important for developers to understand what they are putting into their experiences. If code is obfuscated, a developer cannot trust that the script is only doing what it should be.
Please note: These code readability requirements do not apply to private models or scripts inside experiences. To minimize disruption, we will also maintain Marketplace listings for a small number of pre-approved assets (eg HDadmin, Kohl’s Admin & Adonis) that include these features.
These changes will be going live today, and we’re excited for the future these will bring. We appreciate your continued support as we make the Creator Marketplace a safer place.
Sorry, had to do this because I feel like the easiest and best solution is being ignored. Adding a marketplace ban to the function is NOT the solution to this.
Will we be able to apply our own models for preapproval just like HD Admin and the other admin systems that were preapproved to be whitelisted for these changes?
It’s great that requiring by id will be prohibited from the marketplace, but I need a more future-proof and surefire solution to the issue of bad faith actors uploading infected assets. I don’t ever want an id require in my experience, period. As it is, this can’t be applied retroactively so experiences already suffering from trying to rid of this problem… still have that problem.
Wait, has anyone considered how badly this will affect private systems such as the Polar helicopter system, since those types of systems are both obfuscated and use require()?
These scripts are built this way for revenue gain to support their own development, as the example mentioned is a pretty large and comprehensively complex system and it requires users to pay robux for them to use it.
What I’m concerned about here is complex systems that hide their workings behind obfuscation and require() to avoid malicious parties from reuploading their life’s work.
While the update is a fairly good one, how does one get into the cool developers club where we can get our code with require() whitelisted? Asking as this seems to be very limiting to those models that aren’t popular enough to have their models whitelisted but also are useful and safe enough to not cause worry. We’d be much better off just being able to block requests to the toolbox through require per game…
I use setfenv to opt in specific libraries to a loadstring function for a plugin I’ve written to preview color3 in realtime in scripts.
Will this change prevent me from sharing my plugin (now, or in the future?), or does this affect exclusively only models?
If so, I need an alternative for this because otherwise my plugin will have a huge security vulnerability. I have alternatively tried parsing color3/brickcolor directly out of the script text, but this was extremely imperfect and terribly messy.
So I have a question. Does this apply to assets that are in my own game that were not created by me, and were added before this took effect? I’d like a bit of an elaboration on this.
how does this change affect plugins that use require(id)?
I know of a few plugins that use this method to check for and notify of updates (where the required module is simply a dictionary of version IDs), among other use cases.
this is a terrible update. There are times where you need to use getfenv & require(assetid).
For example, Adonis admin uses require(assetid) in order to ensure that the model is uptodate. Millions use it, and it’s not malicious. Many other models do this too. Plugins too use this @/boatbomber’s InCommand plugin uses this functionality in order to get the latest version of the plugin. It is also used in order to require a module and ensure that it’s up to date. For example, in DS2 you can require it via assetid in order to make sure it’s always up to date. Roblox shouldn’t all of a sudden break this functionality in models inside the marketplace and not give developers time to fix their models/plugins. getfenv is also good to see which script required a module.
Roblox shouldn’t be doing this, it is up to the developer to ensure the models they insert is not malicious. All this is doing is punishing legitimate use cases of these functions.
It is unfair to punish legitimate use cases because of a few bad apples.
While these changes are a great step towards giving developers the ability to understand what’s being added to their games, excluding certain assets from these new measures leaves me concerned. I’ve seen multiple well renowned admin scripts use auto-updates to do things from banning users to prompting free model purchases. How will a new developer know that the assets they’re inserting still come with these risks? Will Roblox be working with the developers of the pre-approved assets to transition towards meeting the requirements that other assets are put under?
