Sorry for the bump, but I just wanted say that SearchBlox has now been banned and removed from the Chrome Webstore.
Although this still isn’t patched, its still good to see that both of the most popular extensions used to bypass the privacy settings are gone.
2 Likes
Never mind. Turns out the creator of Searchblox appealed to Google and now Searchblox is back on the Chrome Web Store AND its open source now ._.
It’s worth saying that even if all these extensions are removed from the planet, it doesn’t help that some of the largest exploitation software have features that have abused this bug for years.
It’s absolute insanity to me that this hasn’t been resolved or had any further communication. When even the largest content creators on the platform complain about this single bug, Roblox has refused to fix this.
Roblox has lost potential influencers, lost growth, lost money, allowed serial harassment because they ignored this bug. What more will it take before someone at Roblox just take action.
6 Likes
Adding on top of that, the main source code has and still is open sourced and anyone can grab it and make their own plugin. The issue will still remain at large unless Roblox addresses it.
1 Like
also i just wanna point out that ther is even a Website someone made to bypass the Roblox privacy settings so if you think about it everyone could easily bypass the Roblox privacy settings.
In a recent announcement, the API this bug relies on has been formally deprecated. While this feature remains in production now, it’s healthy to see this problem finally being resolved.
The replacement for this API no longer uses avatar URLs in their request.
Replacement API
Depending on what your permissions are to the players, you get either
{"previousPageCursor": null, "nextPageCursor": null,
"data": [{
"id": "670ab1ab-c36f-42f3-a5c6-e5ecfa7e63cc",
"maxPlayers": 50, "playing": 1,
"playerTokens": [ "E5799AE12661A06754B9A597D9B491D0" ],
"players": [], "fps": 59.992252, "ping": 16
}]
}
{"previousPageCursor": null, "nextPageCursor": null,
"data": [{
"id": "670ab1ab-c36f-42f3-a5c6-e5ecfa7e63cc",
"maxPlayers": 50, "playing": 1,
"playerTokens": [ "E5799AE12661A06754B9A597D9B491D0" ],
"players": [
{ "playerToken": "E5799AE12661A06754B9A597D9B491D0",
"id": 8403307, "name": "railworks2", "displayName": "railworks2"
}],
"fps": 59.99297, "ping": 9
}]
}
That suggests that this problem looks to be resolved soon. Although maybe due to the freshness of this change, it remains possible to do this attack on loaded page with JS running (or the current vector) as the actual image URLs haven’t changed.
We’ll see how further developments and what “playerToken” means for this attack vector.
5 Likes
You can still use the Thumbnails API to redeem these player tokens into thumbnails, which the website needs to do.
1 Like
Well yes. The thumbnail API is an interesting point with how it deals with those playerTokens. It’s why my reply is not marked as a solution yet.
I’m aware of internal effort being done to improve this problem but this is just the first step it seems.
1 Like
You cannot redeem PlayerTokens into Thumbnails. If this were the case plugins like RoPro or BTR Roblox would still have there server finders available. Which they currently are not.
I say this because it has completely broken my plugin, which was used to find servers of a certain size, not snipe players who don’t want people to join them. Of course, the other API method would theoretically work.But it’s way too slow on big servers as it requires are linear search.
Well you can. Using Thumbnails Api and the following data:
[
{
"requestId": "undefined:undefined:AvatarHeadshot:48x48:null:regular",
"type": "AvatarHeadShot",
"token": "E5799AE12661A06754B9A597D9B491D0",
"format": null,
"size": "48x48"
}
]
you get this data:
{
"data": [
{
"requestId": "undefined:undefined:AvatarHeadshot:48x48:null:regular",
"errorCode": 0,
"errorMessage": "",
"targetId": 0,
"state": "Completed",
"imageUrl": "https://tr.rbxcdn.com/60593b07772526b08a1c283de5ebad2e/48/48/AvatarHeadshot/Png"
}
]
}
This is a known issue and is being resolved.
2 Likes
They could prevent redemption of certain player’s tokens such as star creators
Just quickly adding onto this; Roblox already patched that method they used I believe.
As shown in #70, the API endpoint that Synapse, used at the time of that comment in June 2020 based on leaked content from earlier in time, has been deleted but it’s not patched. Please see #74 for how to bypass it.
Maybe but I don’t think that solves the fundamental problem that if someone’s privacy settings explicitly reject you from joining them, blocked or global, that you should be able to join them in game explicitly.
Sure big devs and star creators are good, but what about big Twitch streamers who joined our platform for the first time and got harassed via this very bug, or smaller creators who don’t quite reach that status yet.
There’s been plenty of ideas suggested prior and Roblox is working on it.
Any suggestions should focus on solving the fundamental problem for everyone, not a minority.
1 Like
No, it is not. Stop framing this as an issue. The frontend site needs to be able to show thumbnails - that is a core part of the platform.
The feature you are requesting shouldn’t be “thumbnails for user tokens are visible and that’s bad”, it should be “users should be able to opt-out of having public thumbnails”.
Except it is an issue - Roblox is going to have to figure out an alternative way of doing it then ¯_(ツ)_/¯
If you read the post, it clearly demonstrates how this is an issue, as it’s blatantly bypassing user privacy settings.
2 Likes
Redeeming player tokens into thumbnails is not an issue, it is a behavior the site needs to show the player list. I never claimed the root issue (discovering users through their thumbnails) was invalid- I’m specifically referring to redeeming player tokens.
2 Likes
There is not being requested a feature here, but reported a problem that the very sentence you put qoutes on can be abused this way.
Your suggested solution is “users should be able to opt-out of having public thumbnails”. While this sounds great I do sort of disagree.
You do not need to have public apis that can reference tokens or other to a player’s thumbnails to show their thumbnail especially on a server list. They have the ability to change the system to make thumbnails show & referenced independently on their backend without you getting the information that a certain token or user matches that thumbnail. Because no one here needs to know that information at all, except Roblox which they can do on their backend, privately. It seems they are doing minor things in the process of a potentional fix that hopefully we’ll see soon but who knows when.
1 Like
Since the publication of this report and the updates since, while this issue has not been fully resolved I would like to update this thread to the latest.
Mainly that this issue has been mostly resolved as it is no longer all server members but rather the top 5. This is both on the web and in the backend
While it’s not entirely solved, it’s improved to a stage where the risk is lowered so such an extent that a reasonable compromise has been made. Does it help if you’re the first 5 people shown? No but I hope to see further improvements but this is where I’ll end my bug report on the matter.
4 Likes
Testing this, using extensions such as SearchBlox still finds the player despite the update. This has not lowered any risks really.
This looks to be an A/B test. I’m seeing API level reduction of threat.
Please clarify if you see similar server listings UI design as me.
2 Likes