Opened 6 years ago

Closed 4 years ago

#3100 closed defect (fixed)

Reduce security prefs into a few groups

Reported by: mikeperry Owned by: mikeperry
Priority: High Milestone: TorBrowserBundle 2.3.x-stable
Component: TorBrowserButton Version:
Severity: Keywords: tbb-disk-leak, tbb-usability, MikePerry201302d
Cc: pmezard@…, intrigeri@…, g.koppen@… Actual Points: 12
Parent ID: Points:
Reviewer: Sponsor:

Description (last modified by mikeperry)

We should reduce the number of preferences into levels of security rather than the myriad of individual behavior controls we have now.

Reducing the number of options can reduce the ability of users to fragment themselves into different anonymity sets through fingerprinting.

Our translators will hate us for a while, but there will be less words to translate total.

I want to get the set down to the following options:

  • Don't record browsing history or website data (enables Private Browsing Mode)
  • Disable browser plugins (such as Flash)
  • Restrict third party cookies and other tracking data
  • Change details that distinguish you from other Tor Browser users

Those last two might be better as per-site options.

I don't think we need much else. The rest of the options will remain buried in about:config.

The last two should also be removed once we get a better per-site Privacy UI (see #5273 and the UI mockup in https://www.torproject.org/projects/torbrowser/design/#identifier-linkability)

Child Tickets

Change History (19)

comment:1 Changed 6 years ago by mikeperry

  • Description modified (diff)

comment:2 Changed 6 years ago by mikeperry

  • Description modified (diff)

comment:3 Changed 6 years ago by mikeperry

  • Description modified (diff)
  • Summary changed from Transform security prefs into slider/groups to Reduce security prefs into a few groups

comment:4 Changed 6 years ago by mikeperry

  • Milestone set to TorBrowserBundle 2.3.x-stable

comment:5 Changed 6 years ago by mikeperry

We should keep the existing prefs in an "Advanced" pane, as they will be useful for debugging to isolate the source of breakage.

comment:6 Changed 6 years ago by mikeperry

#4220 was dupped to this. We should also stop enforcing weird prefs like the update pref on every startup.

comment:7 Changed 5 years ago by pmezard

  • Cc pmezard@… added

comment:8 Changed 5 years ago by mikeperry

  • Keywords tbb-disk-leak added
  • Type changed from enhancement to defect

We've had enough random regressions due to Private Browsing Mode protecting users against disk leaks that we've custom coded that shipping it on by default and governed by the third option would save us a lot of headache.

comment:9 Changed 5 years ago by intrigeri

  • Cc intrigeri@… added

comment:10 Changed 5 years ago by mikeperry

  • Description modified (diff)
  • Keywords tbb-usability added

Block plugins and resist fingerprinting should not be a global choices long-term. See #5273 and the updated design doc.

comment:11 follow-up: Changed 5 years ago by mikeperry

  • Description modified (diff)

I think "Defend against third party tracking" probably should be its own option, since the way we do it now involves disabling stuff like DOM Storage and third party cookies, which may actually break more than the ideal solution would.

comment:12 in reply to: ↑ 11 Changed 5 years ago by gk

  • Cc g.koppen@… added

Replying to mikeperry:

I think "Defend against third party tracking" probably should be its own option, since the way we do it now involves disabling stuff like DOM Storage and third party cookies, which may actually break more than the ideal solution would.

That label seems misleading to me: Fingerprinting might be done by third parties as well and is a means of tracking, too. Thus, if a user checks "Defend against third party tracking" she might come to think that fingerprinting is handled as well (which is not the case) which could lead to unexpected behavior. Maybe something like "Defend against third party identifiers" might fit better here.

comment:13 Changed 5 years ago by mikeperry

  • Keywords MikePerry201212d added

comment:14 Changed 5 years ago by mikeperry

  • Keywords MikePerry201302d added; MikePerry201212d removed

comment:15 Changed 4 years ago by mikeperry

  • Description modified (diff)

I'm tentatively going with these four strings (see description update).

comment:16 Changed 4 years ago by nickm

I think those options are going to need more explanation.

I vote for something like:

  _ 
 |_| Option description

    Long option description. Lorem ipsum dolor sit amet, consectetur adipiscing elit.
    Ut sed libero at justo mollis lobortis id nec neque. Donec mattis vulputate condimentum. In
    sollicitudin lorem ac purus aliquam aliquet. Aliquam hendrerit mollis dolor, non fringilla 

  _ 
 |_| nunc eleifend vitae. 

    Cum sociis natoque penatibus et magnis dis parturient montes, nascetur ridiculus mus.
    Sed iaculis, eros ac dapibus dictum, erat elit tempor sem, accumsan accumsan mi enim
    bibendum quam. Nulla facilisi. Donec libero eros, pretium vel feugiat non, mattis in neque. 
...

For each option, we should explain what it does, why you want to leave it on, under what circumstances (if any) you might want to disable it, and what the risks of turning it off might be.

Also, if possible, we should use the same verb for all the options if we mean the same thing. "Block", "prevent", "resist", and "disable" all mean approximately but not exactly the same thing -- if we're trying to get across a subtle gradation of meaning there, it's probably too subtle. If we're trying to communicate the same thing, though, we should probably use the same verb.

comment:17 Changed 4 years ago by mikeperry

  • Description modified (diff)

comment:18 Changed 4 years ago by mikeperry

  • Description modified (diff)

comment:19 Changed 4 years ago by mikeperry

  • Actual Points set to 12
  • Resolution set to fixed
  • Status changed from new to closed

Pretty sure we're not going to have time to get the formatting and the wording right for the option descriptions before FF17 drops. I created #8227 for that bit.

The actual code + option text is done, though. The pref strings match this ticket description. Will merge it to origin/master shortly. Calling this fixed.

Note: See TracTickets for help on using tickets.