[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #32330 [Applications/Tor Browser]: Think about providing a UI for global cookie settings
#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
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs