This is not the right direction at all. There are 4 major issues with these being blocked.
Fenv:
There are rare cases, mostly in plugins, where this is needed. If this change also applies to the plugin marketplace it diminishes an already small plugin creator community.
Require:
This function is vital to many scripts on roblox. First the post acts like auto update is not vital. In things like anti exploits and admin systems, auto updates are vital for the functionality because of the fact that they are exploit targets. Secondly the blocking of require makes it so no script on the marketplace can use modules. I hope I am mistaken in assuming that because blocking module scripts is detrimental to anything even slightly complex. Finally, many systems such as admin and vehicle systems use requires and they are essentially being forced to be diminished into one script.
Obfuscation:
Developer’s work is routinely stolen on the platform. Obfuscation allows the developer to keep their credit in what they make and at the same time allows them to control their use case. I will make a concession here in saying that those who say this is affecting strictly commercial products, such as blizzard, are wrong. This is because pay-to-use obfuscated systems are not meant to be on the public toolbox.
Monopolization:
Roblox, a platform that is built on the idea that anyone can build anything, is unintentionally supporting monopolies here. The idea of whitelisting models that use these methods just shows how important the methods are. By making a whitelist system, Roblox is essentially giving the top free models permanent prominence with no one else being able to make the same type of script without being on the special whitelist.
Conclusion
Model backdoors, malicious code, viruses, and the infamous “RoSync” have plagued games for years now; however, taking away user freedom is not the solution. Think back to when Roblox disabled HTTP requests by default. Scripts making malicious requests were blocked but the developer had the option to re-enable HTTP requests if they knew what they were doing and knew the risk. The option to allow or disable these methods is one that will be much better than blocking them all together. At the end of day, most malicious code infections are in small games by new developers (those who use the toolbox most). These relatively new developers would be protected by a system that disabled these methods by default because when they see a large warning they will hesitate to move forward. The harm done to legitimate actors is far greater than the benefit of community as a whole.
Many models in Roblox use require, getfenv, and setfenv for legitimate use-cases. These developers should not be punished due to the actions of bad actors unrelated to them.
Not only that, but Roblox has given absolutely no notice before this change. Have we not been over the debacle with the audio update and how little notice we’ve gotten with that? I can buy the fact that Roblox was under a serious time-constraint during all that, but I don’t see why Roblox could at least give us even just a week’s notice before this happened.
Absolutely unacceptable the way Roblox just dropped this on us.
Why exactly was this pushed out with zero prior warning? Development on this platform is starting to get severely hindered lately and I, among other devs, are not happy. This immediately breaks things without giving a chance to remedy it making a lot of hard work rendered useless.
Fenvs can (mostly) be superseded by just coding things differently, like for example having modules import vargs on requiring.
If you need a code running enviroment like a loadstring module you can use my virtual env thing, Creator Marketplace: Improving Model Safety - #65 by ALE111_boiPNG
You can still have obfuscation by sharing a .rbxmx file which then loads the obfuscated code via HTTP service and runs it.
I totally agree with the require thing however, instead of Roblox allowing us to choose of disallowing 3rd party modules, they instead hide all public 3rd party requires. But the worst thing about this is that malicious models can actually bypass this restriction, meaning legitimate usecases are punished while leaving the malicious actors fine.
Also 3rd party modules are sadly the only way to make publicly updating things, unless you make some complicated system, this will definetly hurt legitimate Admin Command systems and other systems like Adonis.
Roblox barely anybody wants this update so please listen to your community and not push this update.
There are better ways to go around this and either way back doors will always find a way, but blocking many useful scripts is not helpful to stopping back doors and viruses at all.
Also wanted to add. What about module scripts that must be public. I have a private modulescript that I had to make public because requires cannot call private scripts anymore. I’m not mass distributing this script through the tool box I’m just using it in groups that I work for. Will this script suddenly get banned?
And what about backwards compatibility? I’m the creator of a free tool called Encrypt API with hundreds of users. Will I suddenly get banned cause that tool I made 2 years ago has disallowed methods. What about the people that use the script? A core functionality of their game will just be broken now because I have to take my api off the marketplace.
Not sure why this is here but being a regular on here gives you nothing but the ability to make bug reports (which members can already do). Wouldn’t push this stereotype here…
This isn’t an excuse for them not telling us how they detect/determine what is considered “obfuscated code”, security through obscurity has never worked and never will work. Developers should not be forced to remain in the dark about a system that could potentially block their models due to a false positive from this system.
That’s not really the point. The point is that people that had a game working fine will have to find a new method to encrypt and have to spend time changing their game code. They might even not know its my encrypt api being offline causing the issue meaning they will need to spend hours debugging. They could have also been saving encrypted data now all that data will be useless.
This really doesn’t seem like the best idea, there should just be a setting to disable require() globally in our projects instead of a marketplace wide ban as this will definitely break a lot of things
From the wording of the post, it seems that the only thing this announcement will impact is toolbox visibility for models that use getfenv, setfenv, or require on third party modules. The “will no longer be allowed in assets shared in the Creator Marketplace” wording implies that this won’t actually cause your code to break, it just won’t appear in the library if it is public.
Edit: I guess this could also mean that any models set to public cannot use those APIs at all, in which case I would just make your model private since you aren’t widely distributing it… but I find it hard to believe they would completely ban all models like this instead of just hiding them from the toolbox.
I’m not developing anything on roblox anymore (like a big break) but I feel I have to share my perspective on this update. I’m glad to see you are trying to solve these problems of viruses, backdoor and more. I had actually developed a plugin for analising assets to deal with this problem before. When I was developing the plugin, I didn’t want to do what others do, automatically delete everything that was looking suspicious. Instead, I decided to display a list to the user to let him determine by himself what he wanted to do. In the same context, I think that preventing the publication of scripts containing getfenv/setfenv, require or “Obfuscated code” is counter-conductive for some. Now I’m not saying that this is a useless idea, it will clearly improve the situation, as everyone knows how infected the marketplace is with these scripts. But I personally think that this is not the right way. You could for example display a warning to the user that the script he wants to add from the toolbox is suspicious. This would allow all developers to continue to use and share scripts containing these useful functions while warning them to check the script to be sure. As for the “Obfuscated code” I agree that an obfuscated script does not inspire trust and cannot be verified manually with ease. However, I wonder how effective you are at automatically detecting an obfuscated script, what to do if it was a false detection? Will the user be able to fix the problem? Will there be any indication of the reason for the detection?
As others have said, there other solutions that i think you should implement too, i could take @metatablecatmaid for exemple, allowing the users to block require in the engine is a good solution. I would even say that it would be better to let the users decide what he want to allow and block himself. If he want to block requires, he block it, if he want to block modelescripts, well he block it too. That would be, i think, another good option to help fixing this issue with viruses and backdoor.
Local modulescripts pose little threat, besides they are used very very widely for legitimate purposes, nearly every game and model uses them. So it really doesnt make sense to even have a feature to block them.
This is true, and i am myself using them everywhere. This was mostlikely a exemple to make the point of “allowing the user to block functionality he want to” since i wasn’t having a lot of idea for the enumeration
I find it strange how you can be so sure of what the future holds or why I should trust automatic updates on a promise of some developers’ account security. I also find it strange how an admin system opens the opportunity for a game to be backdoored to begin with, but I digress. The point is that automatic updates are dangerous and leave no time for review.
@FxllenCode raises the great example of node-ipc. Now take the scenario of node-ipc and add automatic updates to the mix. You can trust a developer as much as you want, but at the end of the day, it’s not difficult to hide malicious intent online. Given the sketchy history of admin systems in the past, they’re literally the absolute last thing I want automatically updating in my game, lol.
