1599137 - Level 2 Trackers are not being blocked after an update

Status: RESOLVED WONTFIX

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

Description

[Simona Badau, Desktop QA]

Attachment: ETP.gif

Mozilla/5.0 (X11; Linux x86_64; rv:72.0) Gecko/20100101 Firefox/72.0
Build ID: 20191125095200

Affected versions:

• Nightly 72.0a1

Affected platforms:

• Ubuntu 18.04 x64
• Windows 10
• Mac OS X 10.14

Prerequisites:

• Download and install an older version of Firefox (where level 2 trackers are not being
  blocked) from: https://archive.mozilla.org/pub/firefox/nightly/2018/10/2018-10-01-10-01-47-mozilla- central/

Steps to reproduce:

1. Open Firefox (Nightly 64.0a1 in my case)
2. Update Firefox
3. Navigate to: https://senglehardt.com/test/trackingprotection/test_pages/tracking_protection.html
4. Look at the "Level 2 (Strict) List" section at the bottom of the page.

Actual results:

• After the update, the message "Cookies not blocked" is displayed.

Expected results:

• After the update, the message "Cookies BLOCKED" is displayed.

Comment 1

[(no longer active)]

Dimi, could you please have a look at this? Is this just a case of the URL classifier service not yet having had a chance to download the initial table?

Comment 2

[Dimi Lee [:dimi]]

I can't reproduce this bug in my local platform.

Simona, can you help record a video with additional two steps:

1. open about:url-classifier and check the provider section
2. open the profile local directory(path can be found in about:profiles) and check the files in the safebrowsing folder in that local directory.
   Thanks!

Comment 3

[Simona Badau, Desktop QA]

Attachment: NIrequest.gif

Comment 4

[Dimi Lee [:dimi]]

Hi Simona,
Could you help archive the safebrowsing folder(before updating Firefox when the folder contains .pset and .sbstore files) and upload it?
Thank you!!!

Comment 5

[Simona Badau, Desktop QA]

Attachment: safebrowsing.zip

Comment 6

[Dimi Lee [:dimi]]

It seems that some of the Safe Browsing databases in the profile were missing for some reasons before updating(I am not sure what was the root cause of this), so after updating to Firefox 72, we still didn't have the required database to block cookies. Cookie blocking should work when Safe Browsing triggers the next update.

Hi Simona,
Can you help check if you start Nightly 64 with a new profile, can you still reproduce this bug?

Comment 7

[Simona Badau, Desktop QA]

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

It seems that some of the Safe Browsing databases in the profile were missing for some reasons before updating(I am not sure what was the root cause of this), so after updating to Firefox 72, we still didn't have the required database to block cookies. Cookie blocking should work when Safe Browsing triggers the next update.

Hi Simona,
Can you help check if you start Nightly 64 with a new profile, can you still reproduce this bug?

Hi Dimi,
Every time I reproduced this issue it was on new profiles.

Comment 8

[Dimi Lee [:dimi]]

(In reply to Simona Badau from comment #7)

Hi Dimi,
Every time I reproduced this issue it was on new profiles.

Ah, right. You showed that in the uploaded video.

I just realized that we didn't include content-track-digest256 before Bug 1501461, that's why the older builds don't have the table in the profile.
After updating to builds supporting using the strict list for default cookie restrictions, we still need to wait until a Safe Browsing update is triggered to download the table to make the feature work.(not sure why I can't reproduce this in the first place, maybe my environment is a little bit messy...)

This is expected behavior unless we want to trigger an Safe Browsing update immediately after an build update.
Set this bug to WORKSFORME

Comment 9

[Dimi Lee [:dimi]]

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

This is expected behavior unless we want to trigger an Safe Browsing update immediately after an build update.
Set this bug to WORKSFORME

ah, sorry, I mean WONTFIX.

Comment 10

[Simona Badau, Desktop QA]

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

(In reply to Simona Badau from comment #7)

Hi Dimi,
Every time I reproduced this issue it was on new profiles.

Ah, right. You showed that in the uploaded video.

I just realized that we didn't include content-track-digest256 before Bug 1501461, that's why the older builds don't have the table in the profile.
After updating to builds supporting using the strict list for default cookie restrictions, we still need to wait until a Safe Browsing update is triggered to download the table to make the feature work.(not sure why I can't reproduce this in the first place, maybe my environment is a little bit messy...)

Dimi, how old is supposed to be the builds that don't have the table in the profile? I'm asking because I remember seeing this also in newer builds like Firefox 67 and Firefox 69 (the issue is indeed intermittent on the builds newer than Firefox 64).

Comment 11

[Dimi Lee [:dimi]]

(In reply to Simona Badau from comment #7)

Dimi, how old is supposed to be the builds that don't have the table in the profile? I'm asking because I remember seeing this also in newer builds like Firefox 67 and Firefox 69 (the issue is indeed intermittent on the builds newer than Firefox 64).

The table should be included by default within Firefox 65(or builds after).
You may see this in newer builds because of Bug 1599379. If you are still seeing this in builds after 73, please file a bug and I'll check it, thanks!

Comment 12

[(no longer active)]

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

This is expected behavior unless we want to trigger an Safe Browsing update immediately after an build update.

That makes sense to me, it's what I suspected to happen here. Thanks for checking.