Skip to content
This repository

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

Closed
lloyd opened this Issue March 29, 2012 · 7 comments

6 participants

Lloyd Hilaiel Ben Adida Shane Tomlinson Edward Lee hadleyrich Jared Hirsch
Lloyd Hilaiel
lloyd commented March 29, 2012

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 123done.org

Lloyd Hilaiel
lloyd commented April 06, 2012

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.

Lloyd Hilaiel
lloyd commented April 06, 2012

I've done a little testing via 123done and dev.myfavoritebeer.org 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

Edward Lee
Owner

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. persona.org 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: https://bugzilla.mozilla.org/show_bug.cgi?id=536509

hadleyrich

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

Shane Tomlinson
Collaborator

Link this to #2999

Jared Hirsch
Owner
6a68 commented April 02, 2013

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

Shane Tomlinson
Collaborator

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

Shane Tomlinson shane-tomlinson closed this June 13, 2013
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.