Introducing Account Session Protection

I hope this post was a joke. Y’know just a little joke totally not someone confessing that their using illegal gambling websites totally not.

4 Likes

Amazing update, great to see this coming!
Unfortunately, there are alot of ways to steal your ROBLOSECURITY and this is actually scary. Thank god Roblox decided to end cookie stealing forever!

1 Like

That is yet another W update, cookie stealing was an issue for a long time now and I’m glad that it’s being fixed. The malicious browser extensions compromising player’s accounts was especially terrifying

1 Like

This is awesome! Thank you!!! I feel more safety!

1 Like

For those of us that use a singular user as a robot to query APIs to load things like latest sales transactions, popular games, etc. that will continue to work fine if we disable this account session protection?

Currently it works with it so long as I do not change IPs on the cookie session, but I will consider disabling this to make it more seamless on the user.

1 Like

They sent out mant warnings about this, It’s actually the reason I use it.
If you didn’t do that and you expect them to rollback, you are wrong!!

This is an awesome step in the right direction for user session security, though I’m left wondering more about a briefly-mentioned but very important detail:

How confident are you guys in ensuring that the way a device is identified can’t be easily spoofed? You don’t get a lot of usable data from purely nothing but HTTP requests. The only two vectors I can really think of are browser user agents (or other browser-persistent headers) and TLS fingerprinting, and it’s entirely possible for that type of data to be collected alongside the cookie itself too. Unless there’s more that this system can do, in which case that’d be good to hear.

4 Likes

This is an AMAZING feature, thanks now I can sleep at night knowing my acc is safe :slight_smile:

1 Like

10000% support this. I can’t tell you the amount of times that I’ve seen cookies leaked. The biggest issue is that automation runs on bot accounts that use a cookie where opencloud lacks support. It’s gotten less frequent over the years and opencloud prioritization has been interesting, it’s just not yet where it needs to be to move these users to opencloud.

I understand that rollout and testing is needed but, this should be automatically deployed w/ a long enough deadline. Opting out of a really, really good security feature that affects a lot of people: players, developers and hobbyists alike is not something I would encourage and allows people to continue to attack on different vectors.

You also have to realize that the people on the devforum are probably a fraction of the users who really need this (mainly players) and the biggest grab by phishing is free things offered by people or scam sites.

To reiterate, I definitely would like to see this on by default (which no option to disable) and utilized across all subdomains, wildcards, etc instead of a few. I do think that a strong, reasonable deadline is more than enough. Bad habits shouldn’t excuse their poor planning. I rather work with this on than to have the whole “what-if” scenario.

Scammers / phishers can just tell whoever to turn this off and now, you lost a solid chunk of what made this great in the first place.

We need to strike the right balance between many different concerns. Turning off the ability to opt-out while not providing appropriate Open Cloud surfaces yet would drop third-party tooling developers, which disproportionally includes creators and also affects their creator customers, into a gap which is not in line with respecting the community.

This is a highly significant improvement to account security even if opt-out-able, because it adds additional friction and several steps before an attack vector is effective. Of course, we can revisit whether an opt-out feature is necessary once we successfully support all relevant functionality used by our third-party tooling community on Open Cloud.

Again, we do not recommend opting out and it is at the user’s own risk, but there are currently valid use cases where this may be appropriate when used with benign third-party tooling. This is not related to rollout and testing.

2 Likes

How do we Opt-in? Or are we all automatically opt-in?

Oh, I just checked where the page is. It’s already Opt-in (enabled), so I am good to go then.

Im curious why you cant undo if you opt out?, is this a technical limitation or something?

It looks like Roblox is signing any requests on the protected endpoints they are using IndexedDB and CryptoKey to store the key in a way that it can only be used but can not be copied. You can’t copy the key cause of the extractable property. It also means that extensions won’t really be affected by this all they would need to do is use the key as they have access to it or even easier use CoreUtilities.httpService to make request to Roblox endpoints. Technically it wouldn’t be possible to make any requests outside of your session but malicious requests could still be made inside of your session.

3 Likes

I don’t know why I didn’t just think of adding extra data to requests that are made. That’s a nice solution.

1 Like

Amazing feature! Have wanted this for a LONG time.

Page doesn’t load… was trying to opt out for my team’s bot account until the features it currently makes use of become available through Open Cloud.


image

Will forward, in the future do you mind sending these as separate bug reports? We get notifications for new bug reports, it might not get noticed as quickly when posted as an announcement reply.

1 Like

Warnings or not, consumer policy prohibits the policy of not honouring a rollback. This is present in many countries.

That should be fixed now, apologies for the inconvenience. Please (hard) refresh if you still have the page open (see browser documentation for instructions). If you encounter any further issues with the page please do submit a separate bug report!

2 Likes