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

RESOLVED FIXED in Firefox 67

Status

()

defect
P2
normal
RESOLVED FIXED
5 months ago
2 months ago

People

(Reporter: johannh, Assigned: Ehsan)

Tracking

unspecified
mozilla67
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox67 fixed)

Details

(Whiteboard: [anti-tracking])

Attachments

(4 attachments)

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.
Assignee

Comment 1

5 months ago

Andrea, do you have cycles to take a look?

Flags: needinfo?(amarchesini)
Assignee

Updated

5 months ago
Priority: -- → P2
Whiteboard: [privacytriage] → [anti-tracking]
Target Milestone: --- → mozilla67
Duplicate of this bug: 1527847
Assignee

Comment 3

4 months ago

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)
Assignee

Comment 4

4 months ago

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
Assignee

Comment 5

4 months ago

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!

Assignee

Comment 6

4 months ago

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

Assignee

Comment 7

4 months ago

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.

Assignee

Updated

4 months ago
Blocks: 1520650

Comment 11

4 months ago
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
Assignee

Comment 15

4 months ago

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

Flags: needinfo?(ehsan)

Comment 16

4 months ago
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
Assignee

Updated

3 months ago
Duplicate of this bug: 1520650
Regressions: 1544509
Assignee

Updated

2 months ago
No longer regressions: 1544509
You need to log in before you can comment on or make changes to this bug.