Opened 12 months ago

Last modified 5 months ago

#32330 new task

Think about providing a UI for global cookie settings

Reported by: gk Owned by: tbb-team
Priority: Medium Milestone:
Component: Applications/Tor Browser Version:
Severity: Normal Keywords: ux-team, TorBrowserTeam202006, tbb-9.0-issues
Cc: Actual Points:
Parent ID: Points:
Reviewer: Sponsor:


With the patch for #26345 we hid the global cookie settings as well while still allowing users to adjust their cookie settings on about:config as cookie permissions are controlled just by a preference, network.cookie.cookieBehavior.

We could think about bringing the cookie UI back, though.

Child Tickets

Change History (10)

comment:1 Changed 12 months ago by gk

Just to give some more options:

1) Leave the status quo because this is an advanced feature that risks users shooting themselves in the foot (think about how many users are actually disabling all cookies, or maybe even allowing all cookies)

2) Implement a new UI

3) Wait for our Enhanced Tracking Protection work (#30309) which might gives us back the UI for free.

I am fine with 1) or 3) but we should not spend time on 2) right now.

comment:2 Changed 12 months ago by antonela

Keywords: ux-team added

comment:3 Changed 12 months ago 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 thought continuing the conversation in the original ticket was the right thing to do.

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?


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 to 'hidden', why not do the same thing as the
(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"'

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 ?

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

comment:4 Changed 12 months ago by cypherpunks

In TBB 9.0, the default network.cookie.cookieBehavior value = 1 (only cookies from originating server). I don't want or need 1st or 3rd party cookies set from every site visited, sometimes for 10 seconds - doing research. Very rarely do I need cookies when surfing or looking for specific data - if not logging in.

If I DO need cookies for a few sites with data not found elsewhere (very rare), I do not want to change prefs in about:config, then change it back.

Before I do that, I'd use a cookie manager extension or just not use TBB, except in rare cases.
I don't want to wait to close TBB or access Mozilla's inaccurate cookie manager to delete cookies and other stored data. I could get a new TBB identity but that affects all open sites, not just one that "needed" cookies.

Some talk of "protecting" average users, by making it harder to change cookie prefs. While FAR more dangerous scripts - from unknown sites are enabled globally in NoScript to improve user experience. "That is illogical."

1) Why after the internet's track record, does anyone think that hackers, sites, corporations, world governments won't find a way to circumvent or spoof "originating server," or haven't already?
Owners of several sites or cooperating site owners can easily share cross site cookie data.

An astounding number of things regarding internet privacy, data collection and tracking individuals that "experts" said couldn't or wouldn't happen or were too expensive, too time consuming or (any reason here) - did and still are happening. People act like Edward Snowden's released data and court rulings on unconstitutional government activities never existed.

2) Why would anyone believe that governments or LEAs can't or won't force, bribe or coerce sites / corporations to retain and hand over data from cookies? Or that they can't and won't use cookies as another tracking tool? Because of some GDPR or similar policy? If all sites can set cookies and they're rarely cleared by average users, it becomes a much bigger prize for anyone.

If world governments are blatantly violating national constitutions on illegal spying and mass data collection on law abiding citizens (it's been proven) and ignore court rulings that many activities are unconstitutional, then governments or anyone else won't blink twice at violating any cookie or privacy policies.

What - governments, corporations aren't smart enough or don't have the resources to bypass anything as secure as a "first party isolate" browser rule or the like? It won't take a government to bypass something like that.

Terms or concepts like "won't," "couldn't," "not possible" simply no longer apply to elected governments or law enforcement, much less to violent or repressive regimes.

comment:5 Changed 12 months ago by sysrqb

Keywords: TorBrowserTeam202001 added

comment:6 Changed 9 months ago by pili

Keywords: TorBrowserTeam202002 added; TorBrowserTeam202001 removed

Moving tickets to February

comment:7 Changed 9 months ago by sysrqb

Deferring some more tickets from February 2020 to June 2020. Too many tickets, not enough time.

comment:8 Changed 8 months ago by sysrqb

Keywords: TorBrowserTeam202006 added; TorBrowserTeam202002 removed

Second attempt at deferring tickets until June.

comment:9 Changed 5 months ago by sysrqb

Keywords: tbb-9.5-issues added; tbb-9.0-issues removed

Batch move remaining tbb-9.0-issues -> 9.5-issues

comment:10 Changed 5 months ago by sysrqb

Keywords: tbb-9.0-issues added; tbb-9.5-issues removed
Note: See TracTickets for help on using tickets.