search

Automattic / jetpack

Security, performance, marketing, and design tools — Jetpack is made by WordPress experts to make WP sites safer and faster, and help you grow your traffic.
https://jetpack.com/
Other
1.59k stars 798 forks source link

Connecting my wp.com account fails in FF with strict tracking protection #19878

Open jsnajdr opened 3 years ago

jsnajdr commented 3 years ago

Steps to reproduce the issue

  1. Use Firefox with Enhanced Tracking Protection set to "strict"
  2. Create a jurassic.ninja site and try to connect Jetpack to your wp.com account
  3. After logging-in in a popup, I eventually got to this screen in the flow:
Screenshot 2021-05-18 at 11 19 07

Clicking the "Approve" button failed to connect me and I can't make further progress.

Some analysis of what's going on: The "connect as ..." box is an iframe loaded from https://jetpack.wordpress.com/jetpack.authorize_iframe. That iframe, although it's cross-origin (jurassic.ninja site loads wordpress.com frame), is loaded with the wordpress_logged_in cookie, so the frame knows who I am. The request and response also contain a wpcom3rdParty cookie. So, if Jetpack tried to detect blocked 3rd party cookies here, the detection failed and concluded that 3rd party cookies are OK.

Then the iframe loads a nested iframe: the REST proxy. Now on this iframe request the 3rd party login cookies (wordpress_sec and wordpress_logged_in) are blocked. The iframe is not authorized and the REST request that is supposed to connect the site:

https://public-api.wordpress.com/rest/v1/jetpack-blogs/:site/jetpack-login

is not authenticated.

Why was the /jetpack.authorize_iframe allowed to use 3rd party cookies and the REST proxy iframe was not? I'm not sure, but Firefox probably decided that with some heuristics. wordpress.com is a domain I previously visited as first party and logged in there. That can be taken into account. And that heuristic no longer applies for the second nested iframe.

jeherve commented 3 years ago

Thanks for the report. The iFramed connection flow is going away in the next release (see #19872), so this shouldn't be an issue for much longer.

jsnajdr commented 3 years ago

Thanks for the response. I should also note that when trying the same task in Safari, with ITP enabled and 3rd party cookies strictly blocked with no exceptions, the flow was different. No popup window with login, no iframes. There was a top-level navigation to wordpress.com/jetpack/connect and back and the connection proceeded flawlessly.

jeherve commented 3 years ago

There was a top-level navigation to wordpress.com/jetpack/connect and back and the connection proceeded flawlessly.

Yes, this is the old flow that will become the default flow again in the next release.

With the current iFramed flow, we've tried to properly fallback to the non-iFramed flow when necessary (see #19037 for some more details / examples), but as you've experienced it's not perfect. This is one of the reasons the iFramed flow is going away.

jsnajdr commented 3 years ago

To confirm my understanding: it is the "in place flow" that will be removed and it will be removed despite the good results (17% increase in finished connections) reported in p1HpG7-8SU-p2?

jeherve commented 3 years ago

That's the one, yes. You can find out more about all this in p1HpG7-bJT-p2