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

[lloyd]

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]

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]

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

[Mardak]

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]

Link this to #2999

[jaredhirsch]

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

[shane-tomlinson]

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

[geddski]

So...does Persona require 3rd party cookies be enabled? I ask because mobile Safari has them disabled by default.

[shane-tomlinson]

So...does Persona require 3rd party cookies be enabled? I ask because mobile Safari has them disabled by default.

Yep. Persona requires what Firefox calls "from visited". We use a persona.org hosted iframe embedded in the relier to generate an assertion. To generate the assertion, the iframe needs access to data stored in localStorage, which requires 3rd party cookies to be enabled. Mobile Safari used to work like Firefox's "from visited" where access to 3rd party cookies/localStorage was restricted until a user visited the 3rd party site directly. Persona was able to rely on this behavior, it doesn't matter if access to 3rd party cookies are disabled the first time a user visits any Persona enabled site, because the user would obviously not have a Persona session. The user would click the "sign in using Persona" button, a Persona popup would be shown, and the user is then considered to have visited Persona. Access to 3rd party cookies is granted, and we can generate the assertion.

I have not worked with Mobile Safari/Persona in a couple of years now and am unsure if this is the current behavior.