Closed Bug 1525458 Opened 2 years ago Closed 2 years ago

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

Categories

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

defect

Tracking

()

RESOLVED FIXED
mozilla67
Tracking Status
firefox67 --- fixed

People

(Reporter: johannh, Assigned: ehsan)

References

Details

(Whiteboard: [anti-tracking])

Attachments

(4 files)

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.

Andrea, do you have cycles to take a look?

Flags: needinfo?(amarchesini)
Priority: -- → P2
Whiteboard: [privacytriage] → [anti-tracking]
Target Milestone: --- → mozilla67

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. :-(

Assignee: nobody → ehsan
Blocks: 1522210
Flags: needinfo?(amarchesini)

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!

Depends on: 1529728

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!

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. ;-)

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.

Blocks: 1520650
Pushed by eakhgari@mozilla.com:
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

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

Flags: needinfo?(ehsan)
Pushed by eakhgari@mozilla.com:
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
Duplicate of this bug: 1520650
No longer regressions: 1544509
You need to log in before you can comment on or make changes to this bug.