1525458 - When an exception is added for a site, all origins in the content blocking log are marked with cryptomining and fingerprinting

Status: RESOLVED FIXED

(Core :: Privacy: Anti-Tracking, defect, P2)

Description

[Johann Hofmann [:johannh]]

STR:

• Enable Cryptomining and Fingerprinting protections in about:config
• Visit https://www.netzwelt.de/
  (The content blocking log should show one origin with FP)
• Click "Turn Off Blocking for This Site" in the control center (add an exception)
• Look at the content blocking log for the site, you should see FP and CM codes on all entries, as far as I can tell.

Comment 1

[(no longer active)]

Andrea, do you have cycles to take a look?

Comment 3

[(no longer active)]

This is a regression originally from bug 1522210. There we added these cases: https://searchfox.org/mozilla-central/rev/4587d146681b16ff9878a6fdcba53b04f76abe1d/netwerk/url-classifier/UrlClassifierCommon.cpp#169-175. But that isn't the right thing to do, even the code that was there before was buggy, it causes every single origin visited in that function to emit an STATE_LOADED_TRACKING_CONTENT event. This is the kind of bug that you don't catch when all of the tests you have test that you have STATE_LOADED_TRACKING_CONTENT events where you expect them but not where you don't. :-(

Comment 4

[(no longer active)]

My fixes here cause some test failures due to bug 1529728 which I have to work around. The failures are purely timing related, for example on try they can only be observed on opt builds, not on debug. They also go away locally on opt builds when you enable MOZ_LOG=nsChannelClassifier:5, which made debugging them extra fun!

Comment 5

[(no longer active)]

https://www.netzwelt.de/ is a strange website. It will load a fingerprinting domain (sync.mathtag.com) when all of our protections are disabled, but not when we block tracking cookies!

Comment 6

[(no longer active)]

Oops, I was wondering why Andrea hasn't reviewed my patches here yet. I realized he has a great reason. I forgot to post them. ;-)

Comment 7

[(no longer active)]

Attachment: Bug 1525458 - Part 1: Only emit the loaded events for various content blocking categories in the presence of an allow-list entry for the top-level document when content would have been blocked otherwise;

Previously the code here used to emit the loaded events for every
resource examined by the URL Classifier Features (in other words, every
third party resource). But we only need to emit the events in cases
where without the presence of the allow-list we would have blocked the
content.

Comment 8

[(no longer active)]

Attachment: Bug 1525458 - Part 2: Update the anti-tracking tests to expect storage access right away when the top-level document is on the allow list and tracking cookies are being blocked per the cookie policy;

Depends on D20874

Comment 9

[(no longer active)]

Attachment: Bug 1525458 - Part 3: Work around bug 1529728 by disabling tracking annotations in flash blocking classifier tests;

Depends on D20875

Comment 10

[(no longer active)]

Attachment: Bug 1525458 - Part 4: Add a test that verifies that when the top-level page is on the content blocking allow-list, we don't emit unexpected content blocking events inside the content blocking log;

Depends on D20876

Comment 11

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/5ce026db31b0
Part 1: Only emit the loaded events for various content blocking categories in the presence of an allow-list entry for the top-level document when content would have been blocked otherwise; r=baku,dimi
https://hg.mozilla.org/integration/autoland/rev/c6177206b968
Part 2: Update the anti-tracking tests to expect storage access right away when the top-level document is on the allow list and tracking cookies are being blocked per the cookie policy; r=baku
https://hg.mozilla.org/integration/autoland/rev/1755b771e8c7
Part 3: Work around bug 1529728 by disabling tracking annotations in flash blocking classifier tests; r=baku
https://hg.mozilla.org/integration/autoland/rev/96c38e4a3d23
Part 4: Add a test that verifies that when the top-level page is on the content blocking allow-list, we don't emit unexpected content blocking events inside the content blocking log; r=baku

Comment 12

[Narcis Beleuzu [:NarcisB]]

Backed out for mochitest failures on test_chrome_ext_trackingprotection.html

Backout link: https://hg.mozilla.org/integration/autoland/rev/b3a4dde40f1543ca4b4579485cceadd9aefd7eca
Push link: https://treeherder.mozilla.org/#/jobs?repo=autoland&resultStatus=testfailed%2Cbusted%2Cexception%2Crunnable&selectedJob=231061099&revision=96c38e4a3d2302598a81e4928d8c9dd09b8afe08
Log link: https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=231061092&repo=autoland&lineNumber=3021

There were also failures on test_annotation_vs_TP.html
Log link: https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=231061091&repo=autoland&lineNumber=37972

Comment 13

[Narcis Beleuzu [:NarcisB]]

Also robocop failures on testTrackingProtection
Log link: https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=231048169&repo=autoland&lineNumber=1565

Comment 14

[Narcis Beleuzu [:NarcisB]]

Also bc failures on browser_contentBlocking.js
Log link: https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=231054701&repo=autoland&lineNumber=23887

Comment 15

[(no longer active)]

Oops, I had a typo which caused all of the bustage.

Comment 16

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/mozilla-inbound/rev/d32503125d27
Part 1: Only emit the loaded events for various content blocking categories in the presence of an allow-list entry for the top-level document when content would have been blocked otherwise; r=baku,dimi
https://hg.mozilla.org/integration/mozilla-inbound/rev/03f6a90e46bd
Part 2: Update the anti-tracking tests to expect storage access right away when the top-level document is on the allow list and tracking cookies are being blocked per the cookie policy; r=baku
https://hg.mozilla.org/integration/mozilla-inbound/rev/bfadbf643f32
Part 3: Work around bug 1529728 by disabling tracking annotations in flash blocking classifier tests; r=baku
https://hg.mozilla.org/integration/mozilla-inbound/rev/ca6099687694
Part 4: Add a test that verifies that when the top-level page is on the content blocking allow-list, we don't emit unexpected content blocking events inside the content blocking log; r=baku

Comment 17

[Raul Gurzau (:RaulG)]

https://hg.mozilla.org/mozilla-central/rev/d32503125d27
https://hg.mozilla.org/mozilla-central/rev/03f6a90e46bd
https://hg.mozilla.org/mozilla-central/rev/bfadbf643f32
https://hg.mozilla.org/mozilla-central/rev/ca6099687694