Closed Bug 1618515 Opened 5 years ago Closed 5 years ago

Cookies are not cleared after enabling "privacy.purge_trackers.enabled"

Categories

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

defect

Tracking

()

RESOLVED FIXED
mozilla75
Tracking Status
firefox75 --- fixed

People

(Reporter: sbadau, Assigned: johannh)

References

(Blocks 1 open bug)

Details

Attachments

(1 file)

Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:75.0) Gecko/20100101 Firefox/75.0
Build ID: 20200226213903

Affected versions

  • Nightly 75.0a1

Affected platforms
Ubuntu 16.04
Windows 10 x64
Mac OS X 10.15

Steps to reproduce

  1. Launch Firefox with a new profile.
  2. Go to about:config and set the preference "privacy.purge_trackers.enabled" to "true".
  3. Gather some cookies by navigating to:
  1. Go to about:preferences#privacy and observe the cookies from the "Manage Cookies and Site Data" dialog.
  2. Go to about:config and set "idle.lastDailyNotification" to "0".
  3. Allow your computer to go "idle" and after 2 minutes check the cookies list again (from the "Manage Cookies and Site Data" dialog).
  4. Open the Browser Console type the following command and press Enter:
    Services.obs.notifyObservers(null, "idle-daily");
  5. Go to about:preferences#privacy and observe the cookies from the "Manage Cookies and Site Data" dialog.
  6. Go to about:config and set the preference "privacy.userInteraction.expiration" to "1"
  7. Wait for 2 minutes, open the Browser console and type and Enter the following snippet:
    await Components.classes["@mozilla.org/purge-tracker-service;1"].getService(Components.interfaces.nsIPurgeTrackerService).purgeTrackingCookieJars()
  8. Go to about:preferences#privacy and observe the cookies from the "Manage Cookies and Site Data" dialog.

Expected result
3. Multiple cookies are created and some of them are from domains on the Disconnect Tracking Protection list (statcounter.com, www.internetbrands.com/, nr-data.net, mc.yandex.ru, statcounter.com) others are not (admetrica.ru. mozilla.org, bbc.co.uk, wikimedia.org, bbc.com).
6, 8 - the third-party cookies from domains on the Disconnect Tracking Protection list should be cleared.
11 - all the cookies from the Disconnect Protection list should be cleared.

Actual result
None of the attempts from steps 5, 7 9 and 10 are ended with cookies clearance. All the cookies that were initially created and visible in step 4 are also present in the "Manage Cookies and Site Data" dialog in steps 6, 8 and 11.

In steps 7 and 10, the following messages can be seen in the browser console, but even so, none of the cookies is cleared and the "Manage Cookies and Site Data" list is the same.
*** PurgeTrackerService: Purging trackers enabled, beginning batch. 2
*** PurgeTrackerService: All cookie purging finished, resetting list until tomorrow.

Type: task → defect

Thanks for filing the bug. Trying to reproduce this I found that there's indeed an issue with the purging (there's no principal.asciiHost), I just wanted to clarify some questions around your STR.

  • You're turning off ETP (cookie blocking) before loading pages that contain trackers, right? Otherwise you shouldn't get any of these cookies in the site data manager.

  • Also, https://senglehardt.com/test/prio/ for me doesn't load any trackers because of mixed content errors. CC Steve who might want to fix that.

  • Your steps contain a few duplicate ways to trigger purging, the different methods are EITHER:

    • Use Services.obs.notifyObservers(null, "idle-daily"); OR
    • Set idle.lastDailyNotification to "0" and wait a few minutes with your computer idle (not super reliable) OR
    • Call Components.classes["@mozilla.org/purge-tracker-service;1"].getService(Components.interfaces.nsIPurgeTrackerService).purgeTrackingCookieJars()

I'll fix this :)

Assignee: nobody → jhofmann
Status: NEW → ASSIGNED
Priority: -- → P1

(In reply to Johann Hofmann [:johannh] from comment #1)

Thanks for filing the bug. Trying to reproduce this I found that there's indeed an issue with the purging (there's no principal.asciiHost), I just wanted to clarify some questions around your STR.

  • You're turning off ETP (cookie blocking) before loading pages that contain trackers, right? Otherwise you shouldn't get any of these cookies in the site data manager.

Yes, I turn ETP off to get the cookies.

  • Your steps contain a few duplicate ways to trigger purging, the different methods are EITHER:
    • Use Services.obs.notifyObservers(null, "idle-daily"); OR
    • Set idle.lastDailyNotification to "0" and wait a few minutes with your computer idle (not super reliable) OR
    • Call Components.classes["@mozilla.org/purge-tracker-service;1"].getService(Components.interfaces.nsIPurgeTrackerService).purgeTrackingCookieJars()

In our testing we used this separately, here I added them together to prove I tried everything. :)

See Also: → 1619242

This is the cheapest solution to unblock the feature. These attributes probably shouldn't
be [noscript] to begin with, which is bug 1619242. The test addition is really simple and
ensures this test is covered. I filed bug 1619244 for rewriting this test, with the purpose
of making it easier to add additional cookie test cases.

Pushed by jhofmann@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/3f95826f96a8 Don't use [noscript] asciiHost attribute in cookie purging. r=Ehsan
Status: ASSIGNED → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla75
Flags: qe-verify+
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: