Opened 2 years ago

Closed 12 months ago

Last modified 6 months 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, BugSmashFund, tbb-no-uplift
Cc: gk Actual Points: 1
Parent ID: Points: 1
Reviewer: Sponsor:

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

comment:1 Changed 2 years ago by cypherpunks

Oops, typo

thereby harming their fingerprint.*

comment:2 Changed 2 years ago by arthuredelstein

Keywords: ff68-esr added; ff67-esr removed

Version 68 of Firefox will be the next ESR.

comment:4 Changed 15 months ago by pili

Sponsor: Sponsor44-can

Adding Sponsor 44 to ESR68 tickets

comment:5 Changed 14 months ago by gk

Keywords: tbb-9.0-alpha-must TorBrowserTeam201908 added

comment:6 Changed 14 months ago by acat

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

comment:7 Changed 14 months ago by gk

Keywords: TorBrowserTeam201909 added; TorBrowserTeam201908 removed

Moving must-alpha tickets to September.

comment:8 Changed 14 months ago by pili

Points: 1

comment:9 Changed 14 months 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 14 months 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 14 months 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 14 months 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 14 months ago by acat

Status: reopenedneeds_review

comment:14 in reply to:  12 Changed 14 months 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 months ago by acat

Actual Points: 1

comment:16 Changed 12 months ago by ghfsdhsdgsdgs

Resolution: fixed
Status: closedreopened

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?

comment:17 Changed 12 months ago by gk

Resolution: fixed
Status: reopenedclosed

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) for your UI request even though I don't think we should work on it anytime soon.

comment:18 Changed 12 months ago by ghfsdhsdgsdgs

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

@cypherpunks @cypherpunks3 @gk @acat

Last edited 12 months ago by ghfsdhsdgsdgs (previous) (diff)

comment:19 Changed 11 months ago by pili

Keywords: BugSmashFund added

BugSmashFund can be used for the ESR work done so far

comment:20 Changed 11 months ago by pili

Sponsor: Sponsor44-can

Sponsor 44 only covered PM and Team Lead work

comment:21 Changed 6 months ago by acat

Keywords: tbb-no-uplift added
Note: See TracTickets for help on using tickets.