Closed Bug 1500639 Opened 6 years ago Closed 6 years ago

Setting urlclassifier.trackingAnnotationTable to strict doesn't work as well as one would hope

Categories

(Firefox :: Protections UI, defect)

defect
Not set
normal

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: ehsan.akhgari, Unassigned)

References

(Blocks 1 open bug)

Details

I was trying to get the new cookie policy to use the strict list today. I started by setting urlclassifier.trackingAnnotationTable to test-track-simple,base-track-digest256,content-track-digest256 but nothing seemed to changed. After many trial and error attempts it seemed that I should set urlclassifier.trackingTable to the same value first, and then reset it. After doing that, the new cookie policy was using the strict list correctly, as I would expect. But before I set urlclassifier.trackingTable, no matter what I did I couldn't get the urlclassifier.trackingAnnotationTable pref to work. Steven said he will retest with a new profile, this was on my main profile...
I can reproduce on a fresh profile. Steps: 1. New profile. Disable Fastblock. 2. Set: `urlclassifier.trackingAnnotationTable` to `test-track-simple,base-track-digest256,content-track-digest256` 3. Visit https://senglehardt.com/test/identity_providers/google.html, which loaded a resource from apis.google.com (on the strict list). No cookies are blocked 4. in about:preferences change the Tracking Protection list to Strict 5. revisit https://senglehardt.com/test/identity_providers/google.html. Cookies now blocked for the request to apis.google.com. 6. set TP back to the basic list 7. revisit https://senglehardt.com/test/identity_providers/google.html. Cookies still blocked. I suspect that Firefox only fetches the content list when it is consumed by tracking protection. After that, the list is available for annotations.
There is no bug here. If you set browser.safebrowsing.debug to true, you will messages like: Initializing update checker for https://shavar.services.mozilla.com/downloads?client=Firefox&appver=65.0a&pver=2.2 provided by mozilla Next update at <timestamp> Next update 59min from now It turns out that we update our lists every hour, and the privacy UI in Preferences forces this update to happen eagerly which causes step 4 in comment 1 to pull down the updates, but if at the end of step 3 you leave the browser for an hour and come back (or restart it again after an hour) you will see the content list being pulled down correctly and everything working as expected.
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.