with 3rd party cookies disabled, primary IdP flow fails inexplicably

[lloyd]

The failure mode is confusing. We need to better message this to users, especially with gmail coming. labeling 4 star to spark discussion. It seems like there are a lot of issues around 3rd party cookies opened and closed, but none seem to address the primary idp case and get us a satisfying user facing error message.

[lloyd]

Our first problem, is how can we possible know that 3rd party cookies are disabled? Detection is non-trivial. Here's some noodling from the depths of IRC:

[14:08:13] <lloyd>   kthiessen: we only break when the user is configured to block ALL 3rd party cookies.  we work fine if they only block 3rd party cookies from sites you've never visited first party
[14:08:36] <lloyd>   kthiessen: and we work fine if there's a whitelist for your identity provider..
[14:08:43] <kthiessen>   lloyd: And what are the symptoms of the breakage?
[14:09:02] <lloyd>   kthiessen: appears as if you canceled out while in the dialog on the screen presented by your IdP.
[14:09:13] <lloyd>   kthiessen: basically, inexplicable failure
[14:09:39]   aelliott (aelliott@moz-73476B80.hfc.comcastbusiness.net) joined the channel.
[14:09:54] <lloyd>   kthiessen: I opened this to track: https://github.com/mozilla/browserid/issues/3520
[14:10:03] <kthiessen>   *nod* Can we try to set a third-party cookie, say for 'testingpersonacookies.net' and send up a warning if we can't read it?
[14:10:14] <jedp>    lloyd it's weird - next try failed on 'compute-cluter' only; and next try failed on 'bcrypt'
[14:10:16] <lloyd>   kthiessen: that wouldn't be sufficiently granular
[14:10:33] <lloyd>   kthiessen: because unless you've visited testingpersonacookies.net, then we can't test the exact scenario
[14:10:44] <lloyd>   kthiessen: a user visits persona first party when they open the dialog
[14:11:11] <lloyd>   kthiessen: if your cookie setting is like "only allow 3rd party cookies to sites I've visited", then I believe that test would unnecesarily blcok you from using persona
[14:11:56]   rseys (rseys@E48845AB.3A9F9BD4.4C2245EF.IP) left IRC. (Ping timeout)
[14:12:25] <kthiessen>   So we need a site we know they've visited, but that isn't *.persona.org?  Can we check HTTP referees?  (I know it's a hack.)
[14:13:22] <kthiessen>   (Auto-correct on Colloquy is going to be the death of me.  Referrers, spelt the way HTTP likes it.)

[jaredhirsch]

@lloyd related: #3220 and a branch I've got cooking to improve localstorage detection: jaredhirsch/browserid@dev...issue_3220_improve_localstorage_detection

[lloyd]

@6a68 right! relationship is that detecting broken local storage will help us detect blocked 3rd party cookies, because the two things tend to be disabled in lockstep?

[lloyd]

This occurs with firefox when 3rd party cookies is set to "never". Or with chrome when "Block third-party cookies and site data" is selected.

It's interesting to consider user facing messaging vs. just making it work, which would take a creative, tricky, but small protocol change.

[shane-tomlinson]

I am amazed no issue has been filed about this before, we have been discussing it as a problem for at least 6 months!

[shane-tomlinson]

Similar, but not exact - #3169

[shane-tomlinson]

An approach similar to what the communication iframe does can be used:

• Embed an iframe from a 3rd party. When sending the iframe, the 3rd party sets a cookie.
• Have the iframe make an XHR/script/img call to the 3rd party with a cookie set.
• Upon receiving the request, the 3rd party checks whether it received the cookie.
• If so, send back a signal to the iframe that says "yep, got it".
• The signal is then relayed from the 3rd party iframe to the dialog.
• The dialog prints user facing messaging that says "hey man, your 3rd party cookies are disabled and we can't sign you in with such oppressive strategies."

[lloyd]

rather detecting and messaging, I'l like to see if we can actually solve the underlying problem.

[seanmonstar]

It seems terrible that we'd need to message people that if they want to use
this awesome new sign in system, they need to stop being protective about
their cookies.
On Jun 13, 2013 3:44 AM, "Shane Tomlinson" notifications@github.com wrote:

An approach similar to what the communication iframe does can be used:

• Embed an iframe from a 3rd party. When sending the iframe, the 3rd
  party sets a cookie.
• Have the iframe make an XHR/script/img call to the 3rd party with a
  cookie set.
• Upon receiving the request, the 3rd party checks whether it received
  the cookie.
• If so, send back a signal to the iframe that says "yep, got it".
• The signal is then relayed from the 3rd party iframe to the dialog.
• The dialog prints user facing messaging that says "hey man, your 3rd
  party cookies are disabled and we can't sign you in with such oppressive
  strategies."

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/3520#issuecomment-19384288
.

[superawesome]

So, we've rolled out IdP for @mozilla.com users now, and hit this right away. I realize that ideally we'd like to solve this altogether, but in the interim I'd like to have some sensible user feedback about what the problem is. Right now it fails in a completely inexplicable (and highly frustrating) manner.

[callahad]

+1. Can we stand up a domain and try to set a third party cookie with it as part of the dialog's bootup?

[seanmonstar]

could we with each our of idps (yahoo bridge, gmail bridge, mozidp), include a simple cookie check on the provisioning page, and if cookies don't stick, raiseProvisioningError('no 3rd party cookies')?

[callahad]

I'd rather do this once at the shim level, instead of N times at N providers, if at all possible...

[shane-tomlinson]

@callahad - #3520 (comment) - same approach I was thinking about. Unfortunately, the shim isn't the place to do it because that won't take care of detecting disabled 3rd party cookies for pseudo-native implementations like FirefoxOS. As an alternative, we can embed 3rd party iframe in the dialog to do the check.

[callahad]

@shane-tomlinson Sorry, that's what I meant -- the popup hosted at login.persona.org could embed an iframe to persona-cookie-check.org or similar.

[lloyd]

Because of differing browser behavior, I worry about the subtleties here.

the feature we require is for a cookie set first party, to be readable third party. If we want to do a check and better messaging (rather than a protocol change to fix the underlying problem) I think it needs to be extremely similar to the feature that we need.

Basically positing that the various checkboxes that browser's offer around "3rd party cookies", impose different restrictions.

On Jul 18, 2013, at 6:47 AM, Dan Callahan notifications@github.com wrote:

@shane-tomlinson Sorry, that's what I meant -- the popup hosted at login.persona.org could embed an iframe to persona-cookie-check.org or similar.

—
Reply to this email directly or view it on GitHub.

[shane-tomlinson]

Link to #2079

[TanviHacks]

Is there a plan to get rid of the need for 3rd party cookies altogether? So that users who block all third party cookies don't need to add an exception?

[lloyd]

Yes! A small change to the idp protocol will allow users with 3rd party cookies completely disabled to use persona. This user will need to authenticate more frequently.

TanviHacks notifications@github.com wrote:

Is there a plan to get rid of the need for 3rd party cookies altogether? So that users who block all third party cookies don't need to add an exception?

---

Reply to this email directly or view it on GitHub:
#3520 (comment)

[ozten]

I think the plan goes like this:

• IdPs should use domains or sub-domains that users actually frequently use.
  • In Firefox, you use custom Cookie rules and set Accept 3rd Party Cookies to "Visited"
• Mozilla is a more nuanced 3rd party cookie policy