Steps to reproduce:

1. Go to https://senglehardt.com/test/ads/facebook_conversion.html?fbclid=IwAR0xGU9TqQTWKR0ZFtrb3WN7PlDE77eRx267VGvM0OhXwg78u0XPzddWINc.
2. Click on "Click me to go to englehardt-tracker.com".

In Storage Inspector (devtools) after step 1, you'll have an "_fbc" cookie on senglehardt.com with a specific value (e.g. fb.1.1563910520903.IwAR0xGU9TqQTWKR0ZFtrb3WN7PlDE77eRx267VGvM0OhXwg78u0XPzddWINc). After step 2, for englehardt-tracker.com, you will also have an "_fbc" cookie with the exact same value set. A cross-site tracking identifier has been established by Facebook.

This circumvention works through the code that is embedded in englehardt-tracker.com through this script: https://connect.facebook.net/signals/config/727812094219915?v=2.9.1&r=stable (Script A, fetched on July 23rd 2019). Inside that script Facebook starts by reading document.referrer (which is https://senglehardt.com/test/ads/facebook_conversion.html?fbclid=IwAR0xGU9TqQTWKR0ZFtrb3WN7PlDE77eRx267VGvM0OhXwg78u0XPzddWINc, Attachment B) and then passing that to a function that decodes the fbclid argument out of the URL (see Attachment C). Then the code parses out any existing _fbc cookie and tries to update the value it reads from there with the newly captured dat (see Attachment D) and finally it writes it to the cookie database (see Attachment E & F).

Currently the fbclid link decoration tag is used in order to perform ad conversion measurement by rewriting ad hyperlink href locations when the user is on www.facebook.com (as well as other outbound hyperlinks on that website). The link decoration tag is read from location.href through another code path. However, the mechanism outlined above allows for propagation of this identifier in the scenario where the user browses from facebook.com, clicks on an ad to go to a.example, and from there clicks on a hyperlink to go to b.example. Specifically this mechanism allows tying the visit to b.example with the visits to a.example as well as facebook.com. The latter is required for the purpose of ad click conversion measurement, but the former is not. Therefore, this mechanism is viewed as a circumvention of ETP under this clause of our Anti-Tracking Policy.

As per that policy, I'm proposing to deploy a fix against this circumvention, by doing the following:

• When document.referrer is accessed, if the referrer URL includes an fbclid link decoration URL parameter, trim it down to the eTLD+1.

This is compatible with the mitigation that WebKit recently took against a similar attack (see https://bugs.webkit.org/show_bug.cgi?id=198227).

One interesting observation is that the URL of the script that contains the circumvention code contains a version number. It seems like this was added in the 2.9.* version of this script and the 2.8.* and older versions do not contain this same code (based on looking for ".referrer" in the script source).

I have a fix here which seems to work using the anti-tracking-url-decoration bucket deployed to the staging server. Still need to write tests for it. Will probably upload the entire patch set tomorrow.

This patch series allows us to match a list of URL decoration annotations through remote settings bucket anti-tracking-url-decoration which Gecko uses in order to identify URL decoration argument names which should trigger downgrading of document.referrer to the registrable domain. Currently fbclid is the only URL decoration argument on this list.

With a build including these patches, if we repeat the STR in comment 0, no _fbc cookie gets created on englehardt-tracker.com. From within the script execution context of englehard-tracker.com, there is no access to the tracking identifier in fbclid any more.

https://hg.mozilla.org/integration/autoland/rev/c4d5dc9736c5
https://hg.mozilla.org/integration/autoland/rev/7a2afd37681f
https://hg.mozilla.org/integration/autoland/rev/2603d1255733
https://hg.mozilla.org/integration/autoland/rev/53ed42cffc74

https://hg.mozilla.org/mozilla-central/rev/c4d5dc9736c5
https://hg.mozilla.org/mozilla-central/rev/7a2afd37681f
https://hg.mozilla.org/mozilla-central/rev/2603d1255733
https://hg.mozilla.org/mozilla-central/rev/53ed42cffc74

Note that this currently doesn't work as expected in Nightly. Bug 1571770 part 2 will fix that.

Comment on attachment 9081720 [details]
Bug 1568341 - Part 1: Add a component for consuming the anti-tracking-url-decoration remote settings bucket and making it available to content processes;

Beta/Release Uplift Approval Request

• User impact if declined: In bug 1525727 we enabled ETP for Firefox 69. Without this fix, users with ETP turned on would be potentially vulnerable to their browsing history being correlated to their Facebook accounts through the mechanism described in comment 0. We need to backport this fix to beta in order to fix that issue.

• Is this code covered by automated tests?: Yes

• Has the fix been verified in Nightly?: Yes

• Needs manual test from QE?: Yes

• If yes, steps to reproduce: Steps to reproduce:

  Go to https://senglehardt.com/test/ads/facebook_conversion.html?fbclid=IwAR0xGU9TqQTWKR0ZFtrb3WN7PlDE77eRx267VGvM0OhXwg78u0XPzddWINc.
  Click on "Click me to go to englehardt-tracker.com".

In Storage Inspector (devtools) after step 1, you'll have an "_fbc" cookie on senglehardt.com with the following value fb.1.1563910520903.IwAR0xGU9TqQTWKR0ZFtrb3WN7PlDE77eRx267VGvM0OhXwg78u0XPzddWINc. After step 2, for englehardt-tracker.com, you should not see an "_fbc" cookie being set.

• List of other uplifts needed: Bug 1571770
• Risk to taking this patch: Medium
• Why is the change risky/not risky? (and alternatives if risky): This fix is with medium risk. While the fix itself has an automated test and has been verified manually, it is adding some new code, and there is a slight chance that it would introduce e.g. a new crash. That being said, it has been baking in Nightly for about a week now with no serious issues, so I think the likelihood of that is minor, but the risk is present since this isn't a small code change.

There aren't any easier alternatives available unfortunately. This was actually the simplest approach that we could think of in order to address this issue.

• String changes made/needed: None

Reproduced the initial issue using an old Nightly build: 20190723034754
Verified - fixed on latest Nightly 70.0a1 (Build id: 20190808214929) on Windows 10, Ubuntu 18.04 and Mac OS 10.14

Comment on attachment 9081720 [details]
Bug 1568341 - Part 1: Add a component for consuming the anti-tracking-url-decoration remote settings bucket and making it available to content processes;

Fixes an ETP circumvention. Approved for 69.0b13.

RyanVM pinged me on IRC to ask if we want to backport this to ESR68. I think the only motivation for doing so would be Fennec shipping ETP off of ESR. That being said, I think the risk of this backport for ESR is way too much for me to be comfortable nominating these for an uplift unfortunately. That, plus the fact that on mobile many users probably use the Facebook native app as opposed to their mobile website would make me inclined to suggest to not backport this to ESR.

Chris, what do you think?

https://hg.mozilla.org/releases/mozilla-beta/rev/4c5561a2a35f
https://hg.mozilla.org/releases/mozilla-beta/rev/cb67222721b8
https://hg.mozilla.org/releases/mozilla-beta/rev/bb5e43a61268
https://hg.mozilla.org/releases/mozilla-beta/rev/ef2dbdb0271b

(In reply to :Ehsan Akhgari from comment #20)

RyanVM pinged me on IRC to ask if we want to backport this to ESR68. I think the only motivation for doing so would be Fennec shipping ETP off of ESR.

Does this you would recommend uplifting this change to ESR 68 if we don't enable ETP by default in ESR 68? Our current plan is to enable ETP by default in Fennec ESR 68.1 (September 3).

That being said, I think the risk of this backport for ESR is way too much for me to be comfortable nominating these for an uplift unfortunately. That, plus the fact that on mobile many users probably use the Facebook native app as opposed to their mobile website would make me inclined to suggest to not backport this to ESR.

This does look like a big change. Let's not uplift to ESR 68 for now.

Does this ETP circumvention just mean Facebook can track users? But the Facebook website and Facebook comments on other websites still work correctly with or without backporting your fix?

Per the last couple comments, I don't think we need to track this for ESR68.

(In reply to Chris Peterson [:cpeterson] from comment #22)

(In reply to :Ehsan Akhgari from comment #20)

RyanVM pinged me on IRC to ask if we want to backport this to ESR68. I think the only motivation for doing so would be Fennec shipping ETP off of ESR.

Does this you would recommend uplifting this change to ESR 68 if we don't enable ETP by default in ESR 68? Our current plan is to enable ETP by default in Fennec ESR 68.1 (September 3).

To be clear, I meant that we wouldn't even discuss uplifting it to ESR if it weren't because of Fennec enabling ETP by default. But I still wouldn't recommend the uplift due to risk.

That being said, I think the risk of this backport for ESR is way too much for me to be comfortable nominating these for an uplift unfortunately. That, plus the fact that on mobile many users probably use the Facebook native app as opposed to their mobile website would make me inclined to suggest to not backport this to ESR.

This does look like a big change. Let's not uplift to ESR 68 for now.

Sounds good.

Does this ETP circumvention just mean Facebook can track users?

It means that when the user clicks on a link from facebook.com to foo.com, and then clicks on another link from that website to go to bar.com, if the Facebook SDK is embedded on bar.com, Facebook may be able to associate the user's browsing on bar.com with their Facebook identity.

But the Facebook website and Facebook comments on other websites still work correctly with or without backporting your fix?

That is right.

Reproduced the initial issue using an old Beta build: 20190807220259
Verified - fixed on latest Beta 69.0b13 (64-bit) (Build id: 20190812173625) on Windows 10, Ubuntu 18.04 and Mac OS 10.14