Disable tracking protection UI in FF67-esr

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/

added BugSmashFund TorBrowserTeam201909R actualpoints::1 component::applications/tor browser ff68-esr owner::tbb-team points::1 priority::medium resolution::fixed severity::normal status::closed tbb-9.0-must-alpha tbb-no-uplift type::defect labels

Oops, typo

thereby harming their fingerprint.*

Version 68 of Firefox will be the next ESR.

Trac:
Keywords: ff67-esr deleted, ff68-esr added

Official announcement: https://blog.mozilla.org/futurereleases/2018/08/30/changing-our-approach-to-anti-tracking/

Adding Sponsor 44 to ESR68 tickets

Trac:
Sponsor: N/A to Sponsor44-can

Trac:
Keywords: N/A deleted, tbb-9.0-alpha-must, TorBrowserTeam201908 added

Trac:
Keywords: tbb-9.0-alpha-must deleted, tbb-9.0-must-alpha added

Moving must-alpha tickets to September.

Trac:
Keywords: TorBrowserTeam201908 deleted, TorBrowserTeam201909 added

Trac:
Points: N/A to 1

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

Trac:
Status: new to needs_review
Keywords: TorBrowserTeam201909 deleted, TorBrowserTeam201909R added

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?)

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

Trac:
Status: needs_review to closed
Resolution: N/A to fixed

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

Trac:
Resolution: fixed to N/A
Status: closed to reopened

Trac:
Status: reopened to needs_review

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

Trac:
Resolution: N/A to fixed
Status: needs_review to closed

Trac:
Actualpoints: N/A to 1

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.

Hello.

As you know, the current patch makes it impossible for normal users to disable cookies.

Disabling the tracking protection ui option is essential to prevent damaging fingerprinting.

But forcing users to accept cookies on their computer by hiding the ui button is a breach of trust and depending on the user/website usage pattern could compromise a users privacy.

There is legitimate reasons for users to want to block all cookies. There is legitimate reasons for users to want to manage/whitelist/blacklist cookies.

Telling normal users to disable cookies via about:config is unrealistic.

I do not ask for the patch that hides dangerous options to be reverted. But can you please move the cookie blocking preference back out of the hidden section? Or can you hide all other dangerous options in the new tracking protection section except the cookie blocking preference?

Trac:
Username: ghfsdhsdgsdgs
Status: closed to reopened
Resolution: fixed to N/A

Please don't reopen old tickets. This one got fixed in the sense that we disabled tracking protection. I've filed a new bug (#32330 (moved)) for your UI request even though I don't think we should work on it anytime soon.

Trac:
Resolution: N/A to fixed
Status: reopened to closed

Sorry. Since this is a software regression I thought continuing the conversation in the original ticket was the right thing to do.

Continued on #32330 (moved)

@cypherpunks @cypherpunks3 @gk @acat

Trac:
Username: ghfsdhsdgsdgs

BugSmashFund can be used for the ESR work done so far

Trac:
Keywords: N/A deleted, BugSmashFund added

Sponsor 44 only covered PM and Team Lead work

Trac:
Sponsor: Sponsor44-can to N/A

Trac:
Keywords: N/A deleted, tbb-no-uplift added

closed

changed time estimate to 8h

added 8h of time spent

mentioned in issue #30663 (moved)

mentioned in issue #31286 (moved)

mentioned in issue #32002 (moved)

mentioned in issue #32330 (moved)

mentioned in issue #33848 (moved)

moved to tpo/applications/tor-browser#26345 (closed)

mentioned in issue tpo/applications/tor-browser#32330