[tor-bugs] #32330 [Applications/Tor Browser]: Think about providing a UI for global cookie settings

[Tor Bug Tracker & Wiki]

#32330: Think about providing a UI for global cookie settings
--------------------------------------+--------------------------
 Reporter:  gk                        |          Owner:  tbb-team
     Type:  task                      |         Status:  new
 Priority:  Medium                    |      Milestone:
Component:  Applications/Tor Browser  |        Version:
 Severity:  Normal                    |     Resolution:
 Keywords:  tbb-9.0-issues, ux-team   |  Actual Points:
Parent ID:                            |         Points:
 Reviewer:                            |        Sponsor:
--------------------------------------+--------------------------

Comment (by ghfsdhsdgsdgs):

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


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

 Copy / Paste from other ticket:
 >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?

 Continued:

 Allowing a user to disable all cookies should be considered safe. It may
 increase the uniqueness of fingerprint compared to a virgin install of
 TTB. Yet disabling cookies means sites cannot identify the same user
 visiting the same site after they click the "new circuit for this site"
 button, or when the new circuits are created every 10 minutes.

 If a user visits a site via a 'good' circuit, gets a cookie, and then 10
 minutes later visits the same site via a 'bad' circuit, then that users
 entire browsing session can de-anonymized instead of just a 10 minute
 segment.
 Some users have more advanced threat models than others. We should not be
 making it more difficult for them to make their browsing safer.

 Allowing a user to accept third party cookies is arguably a bad idea
 because of:
 1) The increase in uniqueness in fingerprint from baseline TTB as above.
 2) Lets third party domains that may be ad networks track users over
 multiple sites.

 Unfortunately on certain poorly constructed sites with cdns and multiple
 domains and hotlink protection, enabling all, or whitelisting one, third
 party domain may be the only way to access unbreak that site.
 We can both agree that is an edge case. But if the site works on other
 browsers and not TTB, then users will think TTB is broken and will be
 tempted to visit the broken site non-anonymously.

 The standard behavior that users have come to expect is to be able to
 control their cookies in the settings. In some


 2) Sounds like a lot of work **so may I suggest a compromise**?

 Instead of setting the tracking-protection-container element inside
 identityPanel.inc.xul to 'hidden', why not do the same thing as the
 "identity-popup-breakageReportView-collection-section"
 (That's the 'Tor Browser Data Collection and Use' in the settings panel)

 and set individual items inside the tracking-protection-container to
 'readonly="true"'

 https://github.com/acatarineu/tor-
 browser/blob/41114401cd1d7d5327d1e2ddd057fc9548b27878/browser/components/controlcenter/content/identityPanel.inc.xul#L349

 readonly="true" greys out a given option in the settings. Because it is
 greyed out instead of hidden, there is no risk in breaking the layout.

 You could use this to grey out options in tracking-protection-container
 that are considered dangerous without disabling the CookiesSubview.

 This way. You don't need to create a new UI or backport and maintain the
 previous one. Any future changes by the firefox team to that UI will
 likely be auto merge-able since you are simply adding a new tag.

 Would greying out dangerous options be acceptable?

 Can we get the input of @cypherpunks @cypherpunks3 @gk @acat ?

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/32330#comment:3>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online