Closed Bug 1599137 Opened 1 year ago Closed 1 year ago

Level 2 Trackers are not being blocked after an update

Categories

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

defect
Not set
normal

Tracking

()

RESOLVED WONTFIX
Tracking Status
firefox72 --- affected

People

(Reporter: simona.marcu, Assigned: dimi)

References

(Blocks 1 open bug)

Details

Attachments

(3 files)

Attached image 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:

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.
Component: Protections UI → Privacy: Anti-Tracking
Product: Firefox → Core
Blocks: etp-level-2-list
No longer blocks: cookierestrictions, 1599069

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?

Flags: needinfo?(dlee)

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!
Assignee: nobody → dlee
Status: NEW → ASSIGNED
Flags: needinfo?(dlee) → needinfo?(simona.marcu)
Attached image NIrequest.gif
Flags: needinfo?(simona.marcu)

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!!!

Flags: needinfo?(simona.marcu)
Attached file safebrowsing.zip
Flags: needinfo?(simona.marcu)
Blocks: 1599379

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?

No longer blocks: 1599379
Flags: needinfo?(simona.marcu)

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

Flags: needinfo?(simona.marcu)

(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

Status: ASSIGNED → RESOLVED
Closed: 1 year ago
Resolution: --- → WORKSFORME

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

Resolution: WORKSFORME → WONTFIX

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

Flags: needinfo?(dlee)

(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!

Flags: needinfo?(dlee)

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

You need to log in before you can comment on or make changes to this bug.