1527639 - [Content Blocking] Cryptominers and Fingerprinters are not blocked immediately on a clean profile

Status: RESOLVED WORKSFORME

(Firefox :: Protections UI, defect)

Description

[Ciprian Georgiu, Desktop QA]

Affected versions

• latest Nightly 67.0a1

Affected platforms

• Windows 10 x64
• macOS 10.13
• Ubuntu 16.04 x64

Prerequisites
Launch Firefox on a clean profile.
Set the following prefs to true in about:config

• privacy.trackingprotection.cryptomining.enabled
• privacy.trackingprotection.fingerprinting.enabled
• browser.contentblocking.cryptomining.preferences.ui.enabled
• browser.contentblocking.fingerprinting.preferences.ui.enabled

Steps to reproduce

1. Go to the following test page https://senglehardt.com/test/trackingprotection/test_pages/fingerprinting_and_cryptomining.html

Expected result

• The shield icon is turn on, and Cryptominers/Fingerprinters are blocked on the test page.

Actual result

• The shield icon doesn't turn on, and Cryptominers/Fingerprinters are NOT blocked on the test page.

Regression range

• Not a regression, I was able to reproduce this on 67.0a1 (2019-02-12) as well, when this feature first landed.

Additional notes

• It seems that this issue happens only on clean profiles, after leaving the Firefox idle for a couple of hours the blocking starts to work again correctly.

Comment 1

[Ciprian Georgiu, Desktop QA]

(In reply to Ciprian Georgiu [:ciprian_georgiu], Release Desktop QA from comment #0)

Additional notes

• It seems that this issue happens only on clean profiles, after leaving the Firefox idle for a couple of hours the blocking starts to work again correctly.

Hi Ehsan, if I'm not mistaken this required some time for the actual block to happen in Firefox. Could you please clarify this behavior for us? Otherwise we are inclined to believe that this is a blocker from our QA perspective.

Comment 2

[Steven Englehardt [:englehardt]]

Does manually triggering a list update fix the issue? You can do so in about:url-classifier by clicking Trigger Update in the mozilla row.

Comment 3

[Ethan Tseng [:ethan]]

Dimi, do you think this issue was caused by the mechanism of Safe Browsing module?
We are wondering why this bug didn't happen for Tracking Protection and Cookie Restriction.

Comment 4

[(no longer active)]

safebrowsing tables are downloaded upon first startup when we trigger update checking here: https://searchfox.org/mozilla-central/rev/01b4b3830ea3cae2e9e431019afa6391b471c6da/toolkit/components/url-classifier/SafeBrowsing.jsm#157. These tables are placed in the safebrowsing subdirectory of the profile folder. Any feature that depends on the safebrowsing backend will not work before these tables are downloaded and are in place.

For me the updates happen quite fast, I think based on comment 0 the initial update happened before the prefs for the fingerprinting and cryptomining features were set so maybe those tables were not downloaded?

Next time you can check the safebrowsing folder under your profile directory looking for base-fingerprinting-track-digest256.* and base-cryptomining-track-digest256.*.

Comment 5

[Dimi Lee [:dimi]]

I am thinking the same thing as Ehsan's comment.
If you launch a new profile and then set those configurations in about:config, it is likely that SafeBrowsing update is triggered already so the changes need to wait until next update to take effect(60 mins)

Comment 6

[Ciprian Georgiu, Desktop QA]

(In reply to Steven Englehardt [:englehardt] from comment #2)

Does manually triggering a list update fix the issue? You can do so in about:url-classifier by clicking Trigger Update in the mozilla row.

Yes, I can confirm that manually triggering the list update fix the issue.

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

For me the updates happen quite fast, I think based on comment 0 the initial update happened before the prefs for the fingerprinting and cryptomining features were set so maybe those tables were not downloaded?

I think that was the case, the safebrowsing tables were't downloaded yet, in the profile folder.

We re-checked this morning and everything worked as expected, the base-fingerprinting-track-digest256.* and base-cryptomining-track-digest256.* were downloaded correctly.

We noticed that if put those files directly in the safebrowsing folder and then open Firefox the fingerprinting and cryptomining feature starts to work as well.

Thank you for the guidance and extra info provided in such short notice. I think we're going to close this bug as WFM!