Skip to content


Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP


dev: ensure new APIs "fail" gracefully when third party cookies are disabled #1352

lloyd opened this Issue · 7 comments

6 participants


disabling third party cookies is common among privacy conscious early adopters. The way this affects BrowserID is by causing API requests from iframes to fail. We should test the new APIs to ensure that our "failure" modes are as graceful as possible. An reasonable user facing behavior in this circumstance might be to just have the user have to authenticate at higher frequencies in this scenario.

We can work on this in dev by disabling third party cookies and testing via

@benadida benadida was assigned
@lloyd lloyd was assigned

taking this issue, as it is a ★★★★★ regression in dev with introduction of new experimental APIs. separate issues should be opened for other places in our code where disabling of 3rd party cookies can break things in confusing ways.


I've done a little testing via 123done and to assess how exactly third party cookies break our code with the new .experimental APIs. I tried chrome's "Block third-party cookies and site data" setting as disabling firefox's "accept third party cookies" as well as safari/iOS setting cookies to 'from visited'.

On chrome and firefox we break in the same way with the new APIs:

  • login/logout events are not fired at login (because we cannot authenticate in the commuication frame) so certain features won't work, and you will have to explicitly log in more often
  • related to the first issue, browserid won't be able to shorten session duration on non-owned machines.
  • calling .logout() does not trigger the .onlogout observer

On iOS, there are no detrimental affects, as the feature is not disabling 3rd party cookies, but just preventing cookies from working before the first visit to the site in question, not an issue for us.

Short story, the three points above can be mitigated in various ways, but in aggregate, given this feature is experimental, I don't see that they should block it. We should have QA do some focus work around 3rd party cookies with the new apis, however.

Given that, I'm downgrading this issue to a four star, and it's a rollup. I will open separate issues for each distinct manifestation of this and we can discuss mitigation tactics on a per-issue basis.

How does this sound? /cc @ozten @shane-tomlinson @benadida @callahad @vthunder


Is there anything that requires cookies to be sent in the http header? I.e., does the server respond with a different script, iframe content, etc. whether the cookie exists or not? What if the data is stored in localstorage, which I believe is being used already on supported platforms, and sent when needed?

I'm running into some persona issues with my auto-block-3rd-party-cookies-for-sites-that-can-track-me-across-X-sites add-on. appears to be a tracker given its cookie and 3rd party request, but it's by policy that Mozilla won't track the sites users visit, so somehow my add-on needs to allow cookies for known not-trackers.

Arguably the intent of my add-on is to prevent the potential of a site tracking users, and it should probably block the localstorage access workaround that I described above.. so this might not be a good long-term fix.

Edit: There's a Firefox bug to have "block 3rd party" also block local storage:


Is there a way to implement persona currently that works when third party cookies are disabled? 123done just shows a loading spinner for me.


Link this to #2999


Out of dev time in Beta 2. Bumping to Beta 3.


Closing since we decided to call .onready if we cannot figure out the state of the user.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.