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.
8 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.
How so? Could all of the required modules not be included in each published model?
Require comes with very useful functionality, this update specifically targets public/on sale models & scripts(which is 3rd party scripts). You can no longer provide tools & services not managed by the game creator themselves. It feels like it defeats the entire point of having this feature. If it was by default disabled in-game or/and per script as a property that you change in Studio that would have been so much better in my opinion & have people be much more cautious about scripts, free assets & the feature altogether.
Roblox could also give the same warnings as models with scripts, or plugins that needs specific perms to scripts that needs require perms.
You know, I was hoping for a different approach, like I don’t know, allowing us to whitelist modules for require(id) in a setting like allowing http requests
This would have the same conclusion, but with some developer flexibility
1 Like
Yes, this would have had the effect of breaking auto updates until such time as the dev figures out how to whitelist it.
Allow us to block 3rd party modules from being required. I don’t believe it’s been said long enough, but we need it blocked completely with an option in game settings or by another method.
“But my 3rd party tool relies on requiring assets into the game with require(id)”
This seems like a developer issue. Assets should already be packaged into the main model itself for easier use.
“I use a framework that is auto updated via require(id)”
PackageLink solves this completely. PackageLInk allows for auto updating and permission based setup, meaning that if your game were to get stolen, people can’t use your packagelink without you granting access. Also comes with versioning and status tools built right in. Migrating your framework has never been easier, start doing some framework spring cleaning! (or summer cleaning)
There is no reason not to block 3rd party requires. They are usually not used for anything besides malicious activity.
1 Like
Im sorry? What? Banning REQUIRE() from freemodels? Because “the majority of uses are malicious”? Have you guys completely lost your mind and understanding of YOUR OWN platform? Like, what the hell made you come up with that?
“hmm yes a single malicious require() was reposted a lot of times so lets ban all requiring from freemodels instead of making efficient ways of warning people of the said requires, previewing the contents of the required assets and such”. Yeah, lets COMPLETELY disregard all the auto updates and easy set up because a bunch of people who launched studio 2 days ago weren’t aware of requires (which is also on Roblox). Thanks! What a useful update! Lets continue demolishing everything on Roblox while putting new features over it until it turns into an average complicated game engine for a bunch of developers that joined in 2020! Completely ignoring everyone else on this platform, besides those guys that are gonna be happy about every game killing update because they have zero connection to Roblox outside of their own questionable simulator projects. This is absolutely stupid.
7 Likes
Reusable Packages have the potential to be incredibly useful, they’re just lacking in Access Permissions right now:
Currently you (the package creator) have to grant manual access to others, or the user has to join your group (but even then there’s no view-only option). These aren’t scalable. They could be if there was a third option where anyone can use your package.
We’d quite like to take a hybrid approach with Nanoblox where we use a plugin to install the application, then the bulk of the application itself functions under a package where users can toggle AutoUpdate on.
Maybe we’ll see some future changes to this current set of permissions @nsgriff?
7 Likes
These functions still have people using it in a valid use-case however, you shouldn’t lock down a feature just because it’s ‘mostly used for malicious behaviour’, you should instead look for options that don’t further limit your platform!
This is a major step-back in my opinion, sure we should be given more control over what assets do in our experience, but just blocking requires from toolbox models is not the way to do it, make it an option. Like how loadstring must be enabled manually by the developer, if I wish to allow the use of a require I should be allowed to do so.
Okay, this is actually a good update but I’ve noticed that you guys seem to be using an automated system for this, which could come up with a few false-positives…
Also, just to ask does the ‘require’ security also apply to in-game scripts, since you only seem to mention that the obfuscated code only applies to public toolbox assets?
1 Like
Yet again, ROBLOX seems to dislike the existence of paid subscription service based assets, Sandboxing is a high demand feature that was promised over 2 years ago when removing closed source third party modules. It was stated that these could be reintroduced once a sandbox system was in place however, this has still not come to fruition. I highly agree with @ForeverHD’s proposition of a fully sandboxed permission based system to control what scripts are able to access what APIs. Having game-wide loadstring, http, and teleportservice toggles causes a security risk when only one script needs such functionality.
Outside of Sandboxing, increasing model safety by disallowing obfuscation and require() functions even if they are open source, again kills paid-subscription based assets and stunts the ability to update models easily. Admin systems will be unable to update to fix possible security vulnerabilities or update features on what users want on demand.
Still, I am waiting to this day for a step forward on sandboxing and allowing at least some way for paid-subscription based models to continue their services without needing obfuscation to do it. Now, this change seems like a step backward and in the wrong direction of actual model security and safety.
6 Likes
If you wish to type in the require command yourself in your game, you are allowed to do so.
I thought obfuscation was already against TOS, no? Just because people are doing it doesn’t mean it is allowed. I don’t’ know, I’m asking.
Maybe it isn’t against TOS, but this popup warning implies that it is:
Yeah, but I should also be authorised to allow other modules do it.
I wonder if they will permit commented out require statements. Where you could go into a setup script of some sort and uncomment the line to enable the functionality.
Not ideal, but maybe an option.