As more content gets added to our developer marketplace that you rely on, we want to ensure that all of you can be confident and safe with any asset you choose to use. As such, we are continuing to improve our suite of content security tools to ensure that all developers have complete awareness and control of 3rd party actions to games. Today we are excited to announce two new security settings directly targeted at known player experience attack vectors: third party purchase prompt controls and third party teleport controls.
In the Game Settings Dialog in Studio, you can find these two new security settings under the Security tab.
Allow Third Party Sales: This setting is intended to control unintentional purchase prompts created by models or plugins that may disrupt gameplay. With this setting disabled, any purchase prompt for an asset that has been published by a user or group that is NOT the publisher of the current game will silently fail. However, any asset published under the ROBLOX account will be permitted. With this setting enabled, any purchase prompt will work as intended.
Allow Third Party Teleports: This setting is intended to control unintentional cross game teleportations initiated by models or plugins that may disrupt gameplay. With this setting disabled, any cross game teleportation to a game that is published by a user or group that is NOT the publisher of the current game will silently fail. With this setting enabled, any cross game teleportation will work as intended.
When these settings are disabled, any attempt to purchase 3rd party assets or teleport to 3rd party places will be blocked without intrusive notifications to your players.
Both of these permissions are game-wide settings that will be applied to all places in that game.
Changes to these settings will take effect when new game servers are initialized
3rd party purchase prompts that fail will be reported in the Output window in Studio and in the Developer Console. 3rd party teleportations that fail will be reported in just the Developer Console.
Any game with a universeID less than 1877172798 will have these settings automatically enabled in order to ensure no game play breakage. If your game does not require these settings, please navigate to the Game Settings Dialog and disable them accordingly.
Any game with a universeID greater than 1877172798 will have these settings automatically disabled to ensure maximum security.
Currently, there exists a Workspace Property for every game dubbed AllowThirdPartySales. Unfortunately, the functionality behind this setting had bugs and was never fully enabled. As such, we will be deprecating this setting in favor of a game-wide permission as outlined above in this post. Therefore, any use of this setting will not be applied.
This seems interesting to use in the game settings, and I mean a lot, but what would happen to the one inside Workspace, would it be decapitated in it, or is it different from the example you’ve shown? Interested in what will happen to it. Nevermind, I re-read it and I saw that it was being decapicated, good to hear that.
While these features are great! I am glad you are putting them in. These address the symptoms not the source. I am eagerly looking forwards to updates to the toolbox to reduce the vast amount frankly garbage in there. As a Roblox educator, kids are very eager to grab whatever looks cool, potentially ruining their games.
This is amazing! while I do not get things from the toolbox anymore, this will help newer devs be able to put a little bit of toolbox assets in their game without asking the players to buy a couch every 30 seconds, or teleport to a different game when you join!
This is one punch in the face for malicious models!
Anyways, I think it’s a little too extreme to either allow purchases created by someone else or not. I feel like there should be a white-list system that allows us to pass any exceptions so any purchases/teleports made by the specified users/groups are allowed even with the options disabled.
Props to Roblox to actually trying to fix the problem. It’s not a 100% solution to issues with malicious plugins/models, like say botting a plugin to make it seem like a good plugin when in fact it adds a backdoor to your game so paying clients are able to run code directly through the game without injecting code. (Then again it’s pretty hard to prevent something like that)
But Hey, Making it harder to do malicious actions is good in cases like these where it decreases the likelihood someone would try to do this to Inflate game numbers or sales of a say a shirt.
Aha! One less attack vector in games and less novice developers confused as to why unintended actions are occurring in their game. These are great features that should have been introduced long ago, but that doesn’t matter - point is they’re here, and that’s all that matters. Cheers!
Thankfully I almost never encounter an instance where I need any of these permissions, so I’m even happier that these will automatically be disabled for newer places.
still wish i could disable client-side teleports though
Sooo… I’m seeing by reading some of the replies that this is going to help eliminate toolbox viruses. Seems awesome! It looks like both properties are disabled by default, which essentially deletes almost all worries of toolbox items saying “Do you want to take Sedan for Free?” or whatever upon joining games that use free assets.
Something I didn’t fully understand, however. Third-party teleportation prompts do not mean those sent by the game itself, such as teleporting to a hub world, right?
yeah this update is quite great and all, but i have 2 things to say about it:
1.this should have been a feature years ago(when it was released or some time around there)
2.for those wondering, no it wont exterminate all backdoors, it will stop like 30% of them, which i guess is a great start.
It is set to private as it is just intended to be the point between enabled and disabled. So you can think of it like all places before are default enabled, and all after are default disabled. For the most part, that will be true, unless a place before it is added to a universe created after it. This is a universe (game-wide) setting not a place setting.
Now give us a feature to block require( id ) from non group or non profile accounts.
That’ll solve this huge backdoor issue that’s starting to arise with people getting smarter to sneak 'require id’s.
You guys disabled the feature to require( id ) from models that are not uncopylocked, but you leave it completely open for models that are? I don’t get the point if this feature was pulled from copylocked models but not uncopylocked ones? That just lets them continue using require maliciously while destroying another kind of marketplace that required or relied on hiding behind being copylocked.
I’ve been seeing multiple models that are being uploaded where they make a ’
require chain’, this module requires, this module requires, this module requires, this module requires…
Maybe provide whitelist or an option to block require( id ) on non group/profile models?
Edit: By what I mean for some services that relied on being private, what is the best 100% way of making sure a player is in a game in a http server? There is no way. There’s no way for even a developer with team create access to see the names of players in the server on the Roblox website.