1796117 - Enhanced Tracking Protection does not block properly on brand new profiles

Status: NEW

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

Description

[Timea Zsoldos [:zstimi/tzsoldos], Desktop QA]

Attachment: Screenshot 2022-10-19 at 15-17-40 https __senglehardt.com.png

Found in

• Firefox 107.0b2

Affected versions

• Firefox 107.0a1 (2022-10-16)
• Firefox 106.0b8
• Firefox 107.0b2

Tested platforms

• Affected platforms: All

Steps to reproduce

1. Open Firefox browser with a new profile.
2. Go to: https://senglehardt.com/test/trackingprotection/test_pages/fingerprinting.html and check the Information panel.

Expected result

• The "Blocked" string is displayed under the Fingerprinting section.

Actual result

• The "NOT blocked" string is displayed under the Fingerprinting section.

Regression range

• I will come back with regression range ASAP.

Additional notes

• Updating Firefox from Fx 106.0b8 to Fx 107.0b2 the "Blocked" string is displayed under
  the Fingerprinting section. Starting Firefox with new profile the issue is come back, the "NOT blocked" string is displayed under the Fingerprinting section.
  This issue also occurs in the case of cryptromining and tracking as well as fingerprinters.

Comment 1

[Tim Huang[:timhuang]]

Can you check if this only happens in a new profile?

I think this might be the case where Firefox hasn't got the update of the disconnect list from the server, so Firefox cannot tell if a resource is a fingerprinter before the list got updated.

I can reproduce the same issue. And it will go away right after the list gets updated.

Comment 2

[Tim Huang[:timhuang]]

Ah, please ignore my question, the comment 0 mentioned that it happens on new profiles.

Comment 3

[Ciprian Georgiu, Desktop QA]

We have managed to further investigate this issue using latest Nightly 108.0a1, and on an older Nightly build. It does not seem to be a regression since we are able to reproduce it on Nightly 96.0a1 (20211111211702) as well.

(In reply to Tim Huang[:timhuang] from comment #1)

Can you check if this only happens in a new profile?

I think this might be the case where Firefox hasn't got the update of the disconnect list from the server, so Firefox cannot tell if a resource is a fingerprinter before the list got updated.

I can reproduce the same issue. And it will go away right after the list gets updated.

We can confirm the above, the trackers are not being blocked on clean profiles until we wait for a couple of minutes (~5 min), or after a browser restart. This is intersting because the lists used to be automatically downloaded after opening the profile, or they could be manually triggered from about:url-classifier page. Now, we're getting a "cannot update" message in the Last update status column, when trying to trigger an update for "google4" or "mozilla" providers.

Let me know if anything else needs to be investigated here.

Comment 4

[Tim Huang[:timhuang]]

Dimi, is there any recent change that makes Firefox doesn't download the list on the fresh start?

Comment 5

[Dimi Lee [ooo 16.04 - 21.04］]

(In reply to Tim Huang[:timhuang] from comment #4)

Dimi, is there any recent change that makes Firefox doesn't download the list on the fresh start?

No, but we do see a higher frequent failure rate while downloading SafeBrowsing lists recently (Bug 1775718), I'm not sure if that is related to this issue or not.
:ciprian, does this issue occur intermittently or is this issue always reproducible on a new profile?

Comment 6

[Ciprian Georgiu, Desktop QA]

(In reply to Dimi Lee [:dimi][:dlee] from comment #5)

:ciprian, does this issue occur intermittently or is this issue always reproducible on a new profile?

It doesn't seem so, I've made 10 new profiles in Firefox and on each profile I was able to reproduce the bug.

Comment 7

[Dimi Lee [ooo 16.04 - 21.04］]

Very likely this issue has the same root cause as Bug 1797729