Will people still be able to get scripts from the website? Is it just the studio built in marketplace effected?
1 Like
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.
2 Likes
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.
1 Like
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…
4 Likes
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.
10 Likes
Anyways for people that use this encrypt API, someone has made an open source Encryption API that has simullar functionality Lua AES Implementation
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.
1 Like
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 
1 Like
You’re missing the point here… Look what happened to node-ipc!
Imagine if this was auto updated!
Roblox should follow suit with every other package manager and add semantic versioning, hence why Wally exists.
1 Like
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.
2 Likes
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.
2 Likes
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.
2 Likes
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
Great, thanks for the heads up
2 Likes
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.
9 Likes
Its normal for large code bases that have a lot of dynamic code to have some vulnerabilities. But Adonis has done a lot to prevent things like this, Adonis has fixed multiple vulns (some relating to LoadAsset while other relating to incorrent remote permission checks) and more, also Adonis is very secure on the server side to prevent tampering from malicious scripts.
This is not the solution we need. There are other solutions that are more viable that others have said here. This is very disappointing Roblox.
Exactly, whoever ‘owns’ the asset could get hacked, lets just say their account gets compromised and they don’t know it, then someone has access to update hundreds of thousands of games with one ‘trusted’ model.
This could be achieved through sandboxing and warning users of what services/permissions the application/plugin would like to use before being installed. Something similar to what we see in the App Store for example. I’ve written up a feature request for this in more detail here.
We see this as temporary (less than a year for example) as both Adonis and HD transition towards entirely new systems to overcome this. Applications like HD/Nanoblox and Adonis take literal years and tens-of-thousands of USD to develop though so its not something we can transition to overnight without impacting thousands of users.
9 Likes
Are players going to get moderated over this? I don’t want to wake up tomorrow seeing one of my accounts banned, over some non-malicious model that I released years ago.
I would hope that this merely prevents them from appearing in marketplace, or at the very least doesn’t punish uploaders of pre-existing models.
We got clarification on this; problem creations will simply be removed from search.