Opened 16 months ago

Closed 4 weeks ago

Last modified 13 days ago

#26345 closed defect (fixed)

Disable tracking protection UI in FF67-esr

Reported by: cypherpunks Owned by: tbb-team
Priority: Medium Milestone:
Component: Applications/Tor Browser Version:
Severity: Normal Keywords: ff68-esr, tbb-9.0-must-alpha, TorBrowserTeam201909R
Cc: gk Actual Points: 1
Parent ID: Points: 1
Reviewer: Sponsor: Sponsor44-can

Description

Some of its parts are already live and well in Nightly (such as the Tracking Protection switch in the hamburger menu). This makes it particularly devastating since more users may be tempted to enable it thereby harming their fingerprinting.

https://bugzilla.mozilla.org/show_bug.cgi?id=1461743

https://www.ghacks.net/2018/06/10/mozilla-plans-to-push-tracking-protection-in-firefox/

Child Tickets

Change History (15)

comment:1 Changed 16 months ago by cypherpunks

Oops, typo

thereby harming their fingerprint.*

comment:2 Changed 15 months ago by arthuredelstein

Keywords: ff68-esr added; ff67-esr removed

Version 68 of Firefox will be the next ESR.

comment:4 Changed 2 months ago by pili

Sponsor: Sponsor44-can

Adding Sponsor 44 to ESR68 tickets

comment:5 Changed 7 weeks ago by gk

Keywords: tbb-9.0-alpha-must TorBrowserTeam201908 added

comment:6 Changed 6 weeks ago by acat

Keywords: tbb-9.0-must-alpha added; tbb-9.0-alpha-must removed

comment:7 Changed 6 weeks ago by gk

Keywords: TorBrowserTeam201909 added; TorBrowserTeam201908 removed

Moving must-alpha tickets to September.

comment:8 Changed 6 weeks ago by pili

Points: 1

comment:9 Changed 5 weeks ago by acat

Keywords: TorBrowserTeam201909R added; TorBrowserTeam201909 removed
Status: newneeds_review

Here is a patch for review: https://github.com/acatarineu/tor-browser/commit/26345

I think with the current preferences we should not be blocking anything from the Firefox
Enhanced Tracking Protection/Content Blocking, other than the 3rd party cookies (which is the same as esr60).

With respect to that, Firefox moved the UI for changing cookie blocking preference (network.cookie.cookieBehavior) to the new content blocking section in about:preferences. If we hide that (as the patch currently does), there is no way that users can change it via UI. I'm not sure if that's so bad, since this would only be for advanced users that know what they are doing, and still is possible to modify it via about:config.

We currently block all 3rd party cookies (although there is #21905 to revise that), and this makes the "shield" icon in the siteIdentity UI appear, so that had to be hidden too.

There are some requests because of this feature going in the background from time to time. The ones that I have checked are coming from UrlClassifierSkipListService.jsm. But I guess we can deal with that in a separate ticket together with some other background requests that are still happening.

comment:10 Changed 4 weeks ago by gk

FWIW: populateCategoryContents() (https://searchfox.org/mozilla-esr68/source/browser/components/preferences/in-content/privacy.js#691) is the important function here to see what actually got enabled. Due to a combination of us setting prefs (privacy.trackingprotection.pbmode.enabled to false) and defaults already set we seem indeed to land at the status quo compared to esr60 modulo the UI changes (so I guess we should be good here with the second remaining item mentioned in comment:17:ticket:27601?)

comment:11 in reply to:  9 Changed 4 weeks ago by gk

Resolution: fixed
Status: needs_reviewclosed

Replying to acat:

Here is a patch for review: https://github.com/acatarineu/tor-browser/commit/26345

I think with the current preferences we should not be blocking anything from the Firefox
Enhanced Tracking Protection/Content Blocking, other than the 3rd party cookies (which is the same as esr60).

Yes (see my last comment).

With respect to that, Firefox moved the UI for changing cookie blocking preference (network.cookie.cookieBehavior) to the new content blocking section in about:preferences. If we hide that (as the patch currently does), there is no way that users can change it via UI. I'm not sure if that's so bad, since this would only be for advanced users that know what they are doing, and still is possible to modify it via about:config.

Looking at the result of the hiding it seems this is okay. We want to avoid users shooting themselves in the foot by clicking on some of those options.

We currently block all 3rd party cookies (although there is #21905 to revise that), and this makes the "shield" icon in the siteIdentity UI appear, so that had to be hidden too.

There are some requests because of this feature going in the background from time to time. The ones that I have checked are coming from UrlClassifierSkipListService.jsm. But I guess we can deal with that in a separate ticket together with some other background requests that are still happening.

Yes, please file a new ticket for that if needed. The patch looks okay to me, especially as this is a temporary measure anyway given that we are interested tin using tracking protection for performance improvements later on.

Cherry-picked to tor-browser-68.1.0esr-9.0-2 (commit cbf4dfb66958590b64cf5b2fc63ff0ed9e2d7d0e).

comment:12 Changed 4 weeks ago by acat

Resolution: fixed
Status: closedreopened

I forgot the menu item in panelUI, fixup in https://github.com/acatarineu/tor-browser/commit/26345+1.

comment:13 Changed 4 weeks ago by acat

Status: reopenedneeds_review

comment:14 in reply to:  12 Changed 4 weeks ago by gk

Resolution: fixed
Status: needs_reviewclosed

Replying to acat:

I forgot the menu item in panelUI, fixup in https://github.com/acatarineu/tor-browser/commit/26345+1.

Nice catch! Looks good and cherry-picked to tor-browser-68.1.0esr-9.0-2 (commit ea79fd5825ed9ea4e148baa473da3b97356bb38f).

comment:15 Changed 13 days ago by acat

Actual Points: 1
Note: See TracTickets for help on using tickets.