I really love how you can opt out of this to help devs still able to use cookies.
You can continue using the bot account, just opt out the bot as shown before harvesting the authentication token from browser.
Some of what you mention is covered by Open Cloud roadmap (e.g. group management APIs). For downloading specific versions of a place via Open Cloud please file a feature request if you do not see it on the roadmap.
(Note that messaging users in the way you suggest is not something we officially endorse. I would recommend filing a feature request on the need to send users notifications with a clarification on your use cases so we can properly fill the gap there.)
We continuously invest in safety of our APIs. We have entire teams working on these topics.
We’re making this announcement specifically because of the effect it has on creator usage of our APIs. Not all safety changes we make affect creator usage or are relevant to creators, so we don’t make announcements for every improvement in this area.
Can you clarify the question? We’re not removing any APIs due to this change, no.
No, this announcement does not mean to imply we will remove API endpoints. We are saying that the additional protections would make it much harder if not infeasible for your tooling to be calling these endpoints if you do not opt-out the authentication token.
Furthermore we’re trying to instill a best practice that your tooling should ideally not be using these endpoints and instead make feature requests for what you need to be added to Open Cloud, so we can properly accommodate for third-party tooling usage via Open Cloud, with proper contracts, scoped authorization and other best practices you will benefit from.
We realize that in the short-term this isn’t practical because it will take us time to offer everything you might need on Open Cloud, hence the opt-out is available for specific current scenarios.
Will forward this concern, thanks.
Seen and forwarded, thanks. Do you have any open thread on the .rbxm/.rbxmx issue you refer to?
Let me know if I’m understanding something incorrectly here, but to the best of my knowledge Studio doesn’t use any of the endpoints listed in this announcement if there is already an authenticated session. This change therefore shouldn’t influence the state of things here, right?
This is a big ask that I think has some open feature requests already. It doesn’t seem like there is actually a need to run Studio but instead have a way to run a headless engine for testing situations and such. I recommend funneling these needs into a separate thread as well. Rather than hearing the proposed solution it’d be great to learn more about the underlying needs because there might be multiple solutions for these needs.
I would presume this was in reference to the current hacky way to do this, thru run-in-roblox. A provided headless engine, to run tests and build games, would be the much more ideal solution.
The most recent feature request for this seems to be auto-locked:
I’d recommend writing your requests as needs “I want to do this” rather than “implement this feature”, it makes it easier for us to digest and prioritize rather than a post about a specific proposed solution. It seems like the need here is “I want to add validation that runs before I commit/publish” or “I can’t safely add new code on my live project” or something along those lines. What is linked is just one way to solve that need but it might not be the only or best solution.
I use Tarmac for uploading images, is this affected by the new update?
Hi, thanks for responding! I was under the belief that there was an open thread for this (I find it hard to believe that nobody made one, considering how long this has been an issue) but I can’t find one. Would it be helpful if I made one on the off chance that one does not exist?
That’s correct, except that there are existing solutions to authenticate Studio in a CI environment. They require a VPN or self-hosted runner, but they do work. roblox-ts
as an example was using a VPN to run tests until really recently (two weeks ago). My concern is that these changes will make processes like that even harder than they already are.
I accepted a long time ago we’d probably never get headless Studio, especially not one that works in CI/CD. This was during the “Roblox seems actively adversarial to Rojo” part of history though, and I realize times have changed. If the stance on e.g. roblox-cli
has changed, I’d be willing to revisit requesting a headless Studio version. Directly discussing it is outside of the scope of this thread, of course, but I wanted to mention the CI/CD use case here because cookie changes directly impact people using Studio for testing.
I’m aware of the past discussions around this and I would just encourage you (as above) to really try and home in on what are the underlying problems you want solving. We’re obviously not just creating new features for the sake of the features themselves. Try to describe what exactly you want us to help simplify and you can mention the roblox-cli take as a footnote as one potential solution. Initial impression from my side is that this kind of tooling seems useful but also very technical to set up and might not benefit a large portion of creators vs. something we could set up inside the engine for validation and testing (not saying either solution is better or worse, just saying there are interesting trade-offs to think through once we actually focus on the need).
It would be good to have if not just for tracking purposes. Please link to me here / in DMs after posting and I’ll attach it to some internal discussions.
I’ll forward that concern specifically, thanks.
it is country based. logging into the cookie from another country will invalidate it
Pretty cool!
kinda good seeing that roblox is adding more security features.
Here’s a feature request for it: Add an Open Cloud endpoint for uploading Roblox Models and Plugins
I fully understand that concern, and I agree. It would be a very technical to set up in nature, especially since a lot of people don’t touch terminals at all these days. However, I’m not sure what alternatives look like. There’s a set of underlying problems, but it’s hard to find a good middle ground where the needs of everyone are covered appropriately. I’ll make a feature request related to it soon™, but it will be hard to strip away a specific solution here since it’s the obvious one that I know would work. An in-engine solution, as an example, does not work for Rojo because a lot of what we need does not exist in the engine and in my opinion it’d be a bad idea to add some of it.
In the past, users who had been compromised and after that sought a rollback for their stolen assets were denied for not having specific account security enabled. For example, the correspondent in the screenshot below was denied a rollback due to 2-step via an authenticator not being enabled on their account.
My question is simple: Will the Account Restoration Team use the Account Session Protection as new argumentation to deny a rollback?
I have seen a plethora of Account Restoration Specialists use account security features as the go-to reason to deny a rollback. Even worse, you mention the following:
The opt-out ability reminds me of Support Agents denying rollback because 2SV via authenticator being not enabled. I can’t prove this will be the new policy of the Support Team going forward, but looking at their past behaviour. I wouldn’t put it past them to deny rollbacks due to certain account security features not being enabled.
As a user who has been compromised in the past and had great trouble fetching my assets back. This concerns me.
Re-linking from above in case you missed it:
https://en.help.roblox.com/hc/en-us/articles/18765146769812-Account-Session-Protection
Warning: If you turn off Account Session Protection, you are leaving your account vulnerable to security threats. If your account is compromised as a result of turning off Account Session Protection, Roblox will not be able to assist you. This change is irreversible.
We do not recommend opting out. Especially not if you have valuable items in your account. Opting out is not required whatsoever so this shouldn’t be an issue for you.
This opt-out feature is intended to help certain automation use cases that do not yet live on Open Cloud, which in a lot of cases doesn’t need to happen from high value accounts.
Opt out does not disabled account cookie regeneration.
They saw the list, but I don’t know if they read through it. The Innovation Awards being cancelled was a completely separate matter that I wasn’t really there for.
Nice To See Roblox Actually Fight Phishing, The Anti Exploit Prevention Article, And Now This, The Platform Is Changing, Into The Good Direction
no way roblox is releasing a good update
This is an amazing security update Thank you roblox now there won’t be any hackers as before!