You can clone with
HTTPS or Subversion.
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
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 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:
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. 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
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.