Re: [tor-bugs] #25658 [Applications/Tor Browser]: Activity 2.1: Improve user understanding and user control by clarifying Tor Browser's security features

[Tor Bug Tracker & Wiki]

#25658: Activity 2.1: Improve user understanding and user control by clarifying 
Tor
Browser's security features
-+-
 Reporter:  isabela  |  Owner:
 |  antonela
 Type:  project  | Status:  new
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ux-team, GeorgKoppen201812,  |  Actual Points:
  TorBrowserTeam201904   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor17
-+-

Comment (by gk):

 Replying to [comment:116 cypherpunks]:
 > Tor Browser 8.5 has completely broken the browsing experience.  Many
 websites on "standard" mode still break--but with the removal of the
 NoScript widget from the toolbar, users have absolutely no obvious way to
 fix things.  Further, "safer" and "safest" mode are so thoroughly broken
 they might as well be removed entirely.  I understand design is an
 iterative process.  I also understand the destination will be better than
 the status quo.
 >
 > This update was botched.  Many websites still break in standard mode,
 but there is no obvious way to un-break them.  Most websites totally break
 in safest mode, but this essential un-breaking control is suddenly buried
 deep within menus and hidden from the user.
 >
 > It's ironic that an issue titled, "Improve user understanding and user
 control by clarifying Tor Browser's security features" results in a Tor
 Browser release that confuses users by removing a key user control over
 Tor Browser security features.  The icing on the cake is Georg's last
 comment, "We'll postpone site-specific permissions for 9.0. Taking this
 ticket off of our 8.5 radar for now.".  Re-read the issue title for added
 comedic effect.

 Thanks. It seems #30600 is the ticket you wanted to comment on. (I'd still
 be curious to see answers to my questions there, actually, given that
 those sites mentioned in that bug work on standard level in my Tor Browser
 and I don't have seen any website broken on standard in 8.5 yet which got
 then fixed by some NoScript modifications via the toolbar icon)

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #25658 [Applications/Tor Browser]: Activity 2.1: Improve user understanding and user control by clarifying Tor Browser's security features

[Tor Bug Tracker & Wiki]

#25658: Activity 2.1: Improve user understanding and user control by clarifying 
Tor
Browser's security features
-+-
 Reporter:  isabela  |  Owner:
 |  antonela
 Type:  project  | Status:  new
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ux-team, GeorgKoppen201812,  |  Actual Points:
  TorBrowserTeam201904   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor17
-+-
Changes (by gk):

 * status:  needs_information => new


Comment:

 Seems we got all the information we need.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #25658 [Applications/Tor Browser]: Activity 2.1: Improve user understanding and user control by clarifying Tor Browser's security features

[Tor Bug Tracker & Wiki]

#25658: Activity 2.1: Improve user understanding and user control by clarifying 
Tor
Browser's security features
-+-
 Reporter:  isabela  |  Owner:
 |  antonela
 Type:  project  | Status:
 |  needs_information
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ux-team, GeorgKoppen201812,  |  Actual Points:
  TorBrowserTeam201904   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor17
-+-

Comment (by cypherpunks):

 Tor Browser 8.5 has completely broken the browsing experience.  Many
 websites on "standard" mode still break--but with the removal of the
 NoScript widget from the toolbar, users have absolutely no obvious way to
 fix things.  Further, "safer" and "safest" mode are so thoroughly broken
 they might as well be removed entirely.  I understand design is an
 iterative process.  I also understand the destination will be better than
 the status quo.

 This update was botched.  Many websites still break in standard mode, but
 there is no obvious way to un-break them.  Most websites totally break in
 safest mode, but this essential un-breaking control is suddenly buried
 deep within menus and hidden from the user.

 It's ironic that an issue titled, "Improve user understanding and user
 control by clarifying Tor Browser's security features" results in a Tor
 Browser release that confuses users by removing a key user control over
 Tor Browser security features.  The icing on the cake is Georg's last
 comment, "We'll postpone site-specific permissions for 9.0. Taking this
 ticket off of our 8.5 radar for now.".  Re-read the issue title for added
 comedic effect.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #25658 [Applications/Tor Browser]: Activity 2.1: Improve user understanding and user control by clarifying Tor Browser's security features

[Tor Bug Tracker & Wiki]

#25658: Activity 2.1: Improve user understanding and user control by clarifying 
Tor
Browser's security features
-+-
 Reporter:  isabela  |  Owner:
 |  antonela
 Type:  project  | Status:
 |  needs_information
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ux-team, GeorgKoppen201812,  |  Actual Points:
  TorBrowserTeam201904   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor17
-+-
Changes (by gk):

 * keywords:  ux-team, GeorgKoppen201812, tbb-8.5-must, TorBrowserTeam201904
 => ux-team, GeorgKoppen201812, TorBrowserTeam201904


Comment:

 Replying to [comment:113 gk]:
 > Adding this on our `tbb-8.5-must` radar at least for comment:110.

 That's been done in #29973. We'll postpone site-specific permissions for
 9.0. Taking this ticket off of our 8.5 radar for now.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #25658 [Applications/Tor Browser]: Activity 2.1: Improve user understanding and user control by clarifying Tor Browser's security features

[Tor Bug Tracker & Wiki]

#25658: Activity 2.1: Improve user understanding and user control by clarifying 
Tor
Browser's security features
-+-
 Reporter:  isabela  |  Owner:
 |  antonela
 Type:  project  | Status:
 |  needs_information
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ux-team, GeorgKoppen201812,  |  Actual Points:
  TorBrowserTeam201903, tbb-8.5-must |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor17
-+-
Changes (by gk):

 * keywords:  ux-team, GeorgKoppen201812, TorBrowserTeam201903, tbb-8.5 =>
 ux-team, GeorgKoppen201812, TorBrowserTeam201903, tbb-8.5-must


Comment:

 Adding this on our `tbb-8.5-must` radar at least for comment:110. We might
 want to tackle #29886 for that as well. And we should at least have a
 precise understanding about what to do with the per-site security
 settings.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #25658 [Applications/Tor Browser]: Activity 2.1: Improve user understanding and user control by clarifying Tor Browser's security features

[Tor Bug Tracker & Wiki]

#25658: Activity 2.1: Improve user understanding and user control by clarifying 
Tor
Browser's security features
-+-
 Reporter:  isabela  |  Owner:
 |  antonela
 Type:  project  | Status:
 |  needs_information
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ux-team, GeorgKoppen201812,  |  Actual Points:
  TorBrowserTeam201903, tbb-8.5  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor17
-+-

Comment (by gk):

 One thing we should keep in mind when designing the exception part is
 doing it in a way that future iterations, which might make substantial
 changes to what we think should be allowed/blocked, say, on the medium
 level, could still make use of it.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #25658 [Applications/Tor Browser]: Activity 2.1: Improve user understanding and user control by clarifying Tor Browser's security features

[Tor Bug Tracker & Wiki]

#25658: Activity 2.1: Improve user understanding and user control by clarifying 
Tor
Browser's security features
-+-
 Reporter:  isabela  |  Owner:
 |  antonela
 Type:  project  | Status:
 |  needs_information
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ux-team, GeorgKoppen201812,  |  Actual Points:
  TorBrowserTeam201903, tbb-8.5  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor17
-+-

Comment (by gk):

 Replying to [comment:109 antonela]:
 > Replying to [comment:107 gk]:
 >
 > > What I mean is not a redesign of how per-site security settings should
 work but we thought about making site-specific settings _as they are
 available today_ accessible. Ideas we had were outlined in section 2.2 of
 the proposal.
 >
 > Got it! I approached a UI for what is described at 2.2.
 >
 > [[Image(https://trac.torproject.org/projects/tor/raw-
 attachment/ticket/25658/25658%20-%202.2.png, 700px)]]

 The control center looks good to me. For the URL bar see more below.

 > Questions:
 >
 > - ` By default only the option to temporarily allow JavaScript would be
 visible.` When? On the Default level? Or in all security levels?

 Only when a security level would block it, I think. I think the active
 content one should at least be visible if a user clicked on a click-to-
 play icon and got, e.g. WebGL going. But we could have that for a future
 iteration if we wanted.

 > - What happens when user enable/disable JS or Active Content? Should
 they reload to apply effects?

 Yes.

 > - We cannot prompt users to enable JS for each website who wants to use
 JS. How are we going to balance it? One option could be to not prompt
 users but enable it automatically and giving users visual feedback at the
 URL bar with the colored icon. If this is the road we are going to take,
 then we should expose this in global settings as an opt-in.

 It's meant to be used as a feature for power users, ideally never ever.
 So, no, I would not want to prompt users. I think we could have a little
 icon in the URL bar grayed out, and that's it as an indicator. I wonder
 whether we should put this icon on the right side of the URL bar, though,
 given that users might click on it by accident when they only wanted to
 see the circuit being used.

 > - Can users save trusted sites in any safe way? Those trusted sites
 could have JS enabled, even if the global security level is `Safest`.

 I don't know yet. We could think about saving those permissions in a
 future iteration. In general, I am a bit reluctant to optimize things for
 power users, in particular as the slider should not used that way, or only
 with great care.

 > - The gear icon at the Control Center goes to `about:preferences#privacy
 Permissions`. Should we incorporate JS and Active Content as an option
 there too?

 No. The permissions we give are site-specific (which is why they are in
 the URL bar) but do not apply to the whole browser session (which those on
 the preferences pane do). We should not mix that (in fact one of our big
 goals with the redesign was to make that distinction clearer).

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #25658 [Applications/Tor Browser]: Activity 2.1: Improve user understanding and user control by clarifying Tor Browser's security features

[Tor Bug Tracker & Wiki]

#25658: Activity 2.1: Improve user understanding and user control by clarifying 
Tor
Browser's security features
-+-
 Reporter:  isabela  |  Owner:
 |  antonela
 Type:  project  | Status:
 |  needs_information
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ux-team, GeorgKoppen201812,  |  Actual Points:
  TorBrowserTeam201903, tbb-8.5  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor17
-+-

Comment (by gk):

 It seems there are remaining `stopOpenSecuritySettingsObserver()` pieces
 left in `torbutton.js`. I assume this is an oversight and we should delete
 them as well (in a fixup commit)? Noted on our blog:
 https://blog.torproject.org/comment/280343#comment-280343.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #25658 [Applications/Tor Browser]: Activity 2.1: Improve user understanding and user control by clarifying Tor Browser's security features

[Tor Bug Tracker & Wiki]

#25658: Activity 2.1: Improve user understanding and user control by clarifying 
Tor
Browser's security features
-+-
 Reporter:  isabela  |  Owner:
 |  antonela
 Type:  project  | Status:
 |  needs_information
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ux-team, GeorgKoppen201812,  |  Actual Points:
  TorBrowserTeam201903, tbb-8.5  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor17
-+-

Comment (by antonela):

 Replying to [comment:107 gk]:

 > What I mean is not a redesign of how per-site security settings should
 work but we thought about making site-specific settings _as they are
 available today_ accessible. Ideas we had were outlined in section 2.2 of
 the proposal.

 Got it! I approached a UI for what is described at 2.2.

 [[Image(https://trac.torproject.org/projects/tor/raw-
 attachment/ticket/25658/25658%20-%202.2.png, 700px)]]

 Questions:

 - ` By default only the option to temporarily allow JavaScript would be
 visible.` When? On the Default level? Or in all security levels?

 - What happens when user enable/disable JS or Active Content? Should they
 reload to apply effects?

 - We cannot prompt users to enable JS for each website who wants to use
 JS. How are we going to balance it? One option could be to not prompt
 users but enable it automatically and giving users visual feedback at the
 URL bar with the colored icon. If this is the road we are going to take,
 then we should expose this in global settings as an opt-in.

 - Can we save trusted sites in any safe way? Those trusted sites could
 have JS enabled, even if the global security level is `Safest`.

 - The gear icon at the Control Center goes to `about:preferences#privacy
 Permissions`. Should we incorporate JS and Active Content as an option
 there too?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #25658 [Applications/Tor Browser]: Activity 2.1: Improve user understanding and user control by clarifying Tor Browser's security features

[Tor Bug Tracker & Wiki]

#25658: Activity 2.1: Improve user understanding and user control by clarifying 
Tor
Browser's security features
-+-
 Reporter:  isabela  |  Owner:
 |  antonela
 Type:  project  | Status:
 |  needs_information
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ux-team, GeorgKoppen201812,  |  Actual Points:
  TorBrowserTeam201903, tbb-8.5  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor17
-+-
Changes (by antonela):

 * Attachment "25658 - 2.2.png" added.


--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #25658 [Applications/Tor Browser]: Activity 2.1: Improve user understanding and user control by clarifying Tor Browser's security features

[Tor Bug Tracker & Wiki]

#25658: Activity 2.1: Improve user understanding and user control by clarifying 
Tor
Browser's security features
-+-
 Reporter:  isabela  |  Owner:
 |  antonela
 Type:  project  | Status:
 |  needs_information
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ux-team, GeorgKoppen201812,  |  Actual Points:
  TorBrowserTeam201903, tbb-8.5  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor17
-+-
Changes (by gk):

 * keywords:  ux-team, GeorgKoppen201812, TorBrowserTeam201903R, tbb-8.5 =>
 ux-team, GeorgKoppen201812, TorBrowserTeam201903, tbb-8.5


Comment:

 Nothing to review here, we are back at the `needs_information` stage.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #25658 [Applications/Tor Browser]: Activity 2.1: Improve user understanding and user control by clarifying Tor Browser's security features

[Tor Bug Tracker & Wiki]

#25658: Activity 2.1: Improve user understanding and user control by clarifying 
Tor
Browser's security features
-+-
 Reporter:  isabela  |  Owner:
 |  antonela
 Type:  project  | Status:
 |  needs_information
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ux-team, GeorgKoppen201812,  |  Actual Points:
  TorBrowserTeam201903R, tbb-8.5 |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor17
-+-

Comment (by gk):

 Replying to [comment:106 antonela]:
 > Replying to [comment:105 gk]:
 > >
 > > 1) 2.2: What to do about per-site security settings and how to expose
 them to users?
 >
 > This ticket includes a 2.2 proposal in the comment:33 and per-site
 security settings has been discussed at #21034.

 What I mean is not a redesign of how per-site security settings should
 work but we thought about making site-specitic settings _as they are
 available today_ accessible. Ideas we had were outlined in section 2.2 of
 the proposal. Do we still think we should do that or something similar (I
 am not talking about redesigning our slider as you e.g. suggested in
 comment:33)? Or do we think just taking the buttons of the toolbar and
 requiring for folks to add them manually if needed is enough?

 > >
 > > 2) 3.1: Where have my extensions gone? (which is essentially the point
 about which I brought up in my last comment)
 >
 > It is tricky. We can anticipate users about this change, but it will not
 remove the question if we are stepping over the local toolbar setting.
 >
 > The proposal explains why we are removing the NoScript extension icon
 but will be useful to have a paragraph to describe it in simple words at
 our release post. Maybe, why custom settings in NoScript are discouraged
 should be the focus of this explainer and at the end, users can customize
 their toolbar by `Menu > Customize...`

 Yes, mentioning it in our release post is definitely a thing we should do.
 I was wondering whether there is more we could/should do here, though.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #25658 [Applications/Tor Browser]: Activity 2.1: Improve user understanding and user control by clarifying Tor Browser's security features

[Tor Bug Tracker & Wiki]

#25658: Activity 2.1: Improve user understanding and user control by clarifying 
Tor
Browser's security features
-+-
 Reporter:  isabela  |  Owner:
 |  antonela
 Type:  project  | Status:
 |  needs_information
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ux-team, GeorgKoppen201812,  |  Actual Points:
  TorBrowserTeam201903R, tbb-8.5 |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor17
-+-

Comment (by antonela):

 Replying to [comment:105 gk]:
 >
 > 1) 2.2: What to do about per-site security settings and how to expose
 them to users?

 This ticket includes a 2.2 proposal in the comment:33 and per-site
 security settings has been discussed at #21034.

 >
 > 2) 3.1: Where have my extensions gone? (which is essentially the point
 about which I brought up in my last comment)

 It is tricky. We can anticipate users about this change, but it will not
 remove the question if we are stepping over the local toolbar setting.

 The proposal explains why we are removing the NoScript extension icon but
 will be useful to have a paragraph to describe it in simple words at our
 release post. Maybe, why custom settings in NoScript are discouraged
 should be the focus of this explainer and at the end, users can customize
 their toolbar by `Menu > Customize...`

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #25658 [Applications/Tor Browser]: Activity 2.1: Improve user understanding and user control by clarifying Tor Browser's security features

[Tor Bug Tracker & Wiki]

#25658: Activity 2.1: Improve user understanding and user control by clarifying 
Tor
Browser's security features
-+-
 Reporter:  isabela  |  Owner:
 |  antonela
 Type:  project  | Status:
 |  needs_information
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ux-team, GeorgKoppen201812,  |  Actual Points:
  TorBrowserTeam201903R, tbb-8.5 |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor17
-+-

Comment (by gk):

 Replying to [comment:104 mcs]:
 > Replying to [comment:103 gk]:
 > > I am wondering what happens if users had customized their toolbar, say
 by adding a home button or custom extension buttons. While those vanish,
 too?
 >
 > I think the answer is "yes." Another way to solve the upgrade issue
 would be to "surgically" relocate the Torbutton toolbar item and then
 insert the new Security Settings one in the correct place. Maybe that can
 be implemented in a followup ticket.

 Okay, that's what I expected. Looking back at the proposal it seems we
 might want to think about the following two items closer:

 1) 2.2: What to do about per-site security settings and how to expose them
 to users?

 2) 3.1: Where have my extensions gone? (which is essentially the point
 about which I brought up in my last comment)

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #25658 [Applications/Tor Browser]: Activity 2.1: Improve user understanding and user control by clarifying Tor Browser's security features

[Tor Bug Tracker & Wiki]

#25658: Activity 2.1: Improve user understanding and user control by clarifying 
Tor
Browser's security features
-+-
 Reporter:  isabela  |  Owner:
 |  antonela
 Type:  project  | Status:
 |  needs_information
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ux-team, GeorgKoppen201812,  |  Actual Points:
  TorBrowserTeam201903R, tbb-8.5 |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor17
-+-

Comment (by mcs):

 Replying to [comment:103 gk]:
 > I am wondering what happens if users had customized their toolbar, say
 by adding a home button or custom extension buttons. While those vanish,
 too?

 I think the answer is "yes." Another way to solve the upgrade issue would
 be to "surgically" relocate the Torbutton toolbar item and then insert the
 new Security Settings one in the correct place. Maybe that can be
 implemented in a followup ticket.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #25658 [Applications/Tor Browser]: Activity 2.1: Improve user understanding and user control by clarifying Tor Browser's security features

[Tor Bug Tracker & Wiki]

#25658: Activity 2.1: Improve user understanding and user control by clarifying 
Tor
Browser's security features
-+-
 Reporter:  isabela  |  Owner:
 |  antonela
 Type:  project  | Status:
 |  needs_information
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ux-team, GeorgKoppen201812,  |  Actual Points:
  TorBrowserTeam201903R, tbb-8.5 |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor17
-+-

Comment (by gk):

 Reading
 {{{
Toolbars are reset
 to
 the Tor Browser default when the new 'inserted_security_level' pref is
 false. Coupled with the changes in tor-browser, users which upgrade
 will
 have their toolbars reset to the new design.
 }}}
 I am wondering what happens if users had customized their toolbar, say by
 adding a home button or custom extension buttons. While those vanish, too?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #25658 [Applications/Tor Browser]: Activity 2.1: Improve user understanding and user control by clarifying Tor Browser's security features

[Tor Bug Tracker & Wiki]

#25658: Activity 2.1: Improve user understanding and user control by clarifying 
Tor
Browser's security features
-+-
 Reporter:  isabela  |  Owner:
 |  antonela
 Type:  project  | Status:
 |  needs_information
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ux-team, GeorgKoppen201812,  |  Actual Points:
  TorBrowserTeam201903R, tbb-8.5 |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor17
-+-

Comment (by gk):

 FWIW, we can use #24653 to tackle the mobile side of this ticket.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #25658 [Applications/Tor Browser]: Activity 2.1: Improve user understanding and user control by clarifying Tor Browser's security features

[Tor Bug Tracker & Wiki]

#25658: Activity 2.1: Improve user understanding and user control by clarifying 
Tor
Browser's security features
-+-
 Reporter:  isabela  |  Owner:
 |  antonela
 Type:  project  | Status:
 |  needs_information
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ux-team, GeorgKoppen201812,  |  Actual Points:
  TorBrowserTeam201903R, tbb-8.5 |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor17
-+-
Changes (by gk):

 * status:  needs_review => needs_information


Comment:

 I applied the Torbutton patch to `master` (commit
 5a3d6d26e1f8046b20e51d93ca9457a729063bfc) and added both the tor-browser
 patch and the fixup to `tor-browser-60.5.0esr-8.5-1` (commits
 a7ba005d5398a29d95320a5e8c02bf050e58f08b and
 d76b18ccef4ba4cb5be25f8c81b5817610f4d292). I did not have a chance to look
 over the tor-browser patch yet but from the comments in this ticket it
 *seems* it fixes #29554 as well. I'll close that ticket, but please reopen
 if I was wrong. What about #23359? Are done here as well in the sense that
 the buttons are not shown anymore?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #25658 [Applications/Tor Browser]: Activity 2.1: Improve user understanding and user control by clarifying Tor Browser's security features

[Tor Bug Tracker & Wiki]

#25658: Activity 2.1: Improve user understanding and user control by clarifying 
Tor
Browser's security features
-+-
 Reporter:  isabela  |  Owner:
 |  antonela
 Type:  project  | Status:
 |  needs_review
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ux-team, GeorgKoppen201812,  |  Actual Points:
  TorBrowserTeam201903R, tbb-8.5 |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor17
-+-
Changes (by mcs):

 * Attachment "0001-fixup-Bug-25658-Replace-security-slider-with-
 securit.patch" added.

 fixup to relocate the Torbutton toolbar item

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #25658 [Applications/Tor Browser]: Activity 2.1: Improve user understanding and user control by clarifying Tor Browser's security features

[Tor Bug Tracker & Wiki]

#25658: Activity 2.1: Improve user understanding and user control by clarifying 
Tor
Browser's security features
-+-
 Reporter:  isabela  |  Owner:
 |  antonela
 Type:  project  | Status:
 |  needs_review
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ux-team, GeorgKoppen201812,  |  Actual Points:
  TorBrowserTeam201903R, tbb-8.5 |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor17
-+-

Comment (by mcs):

 Replying to [comment:98 pospeselr]:
 > Updated torbutton to handle user upgrade correctly and excises the fix
 for #27478 (will put that in a new branch and post to that ticket). Also
 rebased it against latest torbutton master. Fixed whitespace issues in
 tor-browser and torbutton with a `git rebase --whitespace=fix HEAD~1`
 >
 > torbutton:
 https://gitweb.torproject.org/user/richard/torbutton.git/commit/?h=bug_25658_v2
 > torbrowser: https://gitweb.torproject.org/user/richard/tor-
 browser.git/commit/?h=bug_25658_v5

 Looks good to me, except I think per comment:79 we want the Torbutton icon
 to be relocated to the right side of the toolbar. I will attach a fixup
 patch.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #25658 [Applications/Tor Browser]: Activity 2.1: Improve user understanding and user control by clarifying Tor Browser's security features

[Tor Bug Tracker & Wiki]

#25658: Activity 2.1: Improve user understanding and user control by clarifying 
Tor
Browser's security features
-+-
 Reporter:  isabela  |  Owner:
 |  antonela
 Type:  project  | Status:
 |  needs_review
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ux-team, GeorgKoppen201812,  |  Actual Points:
  TorBrowserTeam201903R, tbb-8.5 |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor17
-+-
Changes (by pospeselr):

 * status:  needs_revision => needs_review


--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #25658 [Applications/Tor Browser]: Activity 2.1: Improve user understanding and user control by clarifying Tor Browser's security features

[Tor Bug Tracker & Wiki]

#25658: Activity 2.1: Improve user understanding and user control by clarifying 
Tor
Browser's security features
-+-
 Reporter:  isabela  |  Owner:
 |  antonela
 Type:  project  | Status:
 |  needs_revision
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ux-team, GeorgKoppen201812,  |  Actual Points:
  TorBrowserTeam201903R, tbb-8.5 |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor17
-+-

Comment (by pospeselr):

 updated torbutton patch that handles user upgrade correctly and excises
 the fix for #27478 (will put that in a new branch and post to that
 ticket):

 https://gitweb.torproject.org/user/richard/torbutton.git/commit/?h=bug_25658_v2

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #25658 [Applications/Tor Browser]: Activity 2.1: Improve user understanding and user control by clarifying Tor Browser's security features

[Tor Bug Tracker & Wiki]

#25658: Activity 2.1: Improve user understanding and user control by clarifying 
Tor
Browser's security features
-+-
 Reporter:  isabela  |  Owner:
 |  antonela
 Type:  project  | Status:
 |  needs_revision
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ux-team, GeorgKoppen201812,  |  Actual Points:
  TorBrowserTeam201903R, tbb-8.5 |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor17
-+-

Comment (by mcs):

 Replying to [comment:94 pospeselr]:
 > I was more curious if there was a way to determine that the browser had
 been updated, so that we can then put the Security Level button in the
 toolbar. Inserting the button is just a matter of finding the right js to
 call.

 I think you only want to add the Security Level button one time, not after
 every update. Usually that is handled by setting a hidden pref (similar to
 `extensions.torbutton.inserted_button`).

 > new branch with latest tor-browser changes:
 https://gitweb.torproject.org/user/richard/tor-
 browser.git/commit/?h=bug_25658_v4

 Everything looks good except there is a trailing space on the `line-
 height: 1em; ` line in
 `browser/components/securitylevel/content/securityLevelPreferences.css`.

 Is there a new Torbutton patch or is that still in progress?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #25658 [Applications/Tor Browser]: Activity 2.1: Improve user understanding and user control by clarifying Tor Browser's security features

[Tor Bug Tracker & Wiki]

#25658: Activity 2.1: Improve user understanding and user control by clarifying 
Tor
Browser's security features
-+-
 Reporter:  isabela  |  Owner:
 |  antonela
 Type:  project  | Status:
 |  needs_revision
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ux-team, GeorgKoppen201812,  |  Actual Points:
  TorBrowserTeam201903R, tbb-8.5 |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor17
-+-
Changes (by gk):

 * status:  needs_review => needs_revision


Comment:

 I've been looking at commit 843976bb2f88dc08cbefc28024b4a271a5cfa92a (the
 Torbutton patch). Two small requests:

 1) I think the Torbutton icon fixup (aka #27478) is orthogonal to the sec
 slider changes. It's fine having both on the same branch but could you put
 them into different commits (with own bug numbers etc.) and adapt the
 commit message? That way it's easier to keep track of the changes.

 2) Looking at your new SVG icons, it seems you have added some superflous
 whitespace, both at the end of
 {{{
 +  
 }}}
 and at the beginning of
 {{{
 +   https://trac.torproject.org/projects/tor/ticket/25658#comment:96>
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #25658 [Applications/Tor Browser]: Activity 2.1: Improve user understanding and user control by clarifying Tor Browser's security features

[Tor Bug Tracker & Wiki]

#25658: Activity 2.1: Improve user understanding and user control by clarifying 
Tor
Browser's security features
-+-
 Reporter:  isabela  |  Owner:
 |  antonela
 Type:  project  | Status:
 |  needs_review
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ux-team, GeorgKoppen201812,  |  Actual Points:
  TorBrowserTeam201903R, tbb-8.5 |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor17
-+-
Changes (by pospeselr):

 * status:  needs_revision => needs_review


--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #25658 [Applications/Tor Browser]: Activity 2.1: Improve user understanding and user control by clarifying Tor Browser's security features

[Tor Bug Tracker & Wiki]

#25658: Activity 2.1: Improve user understanding and user control by clarifying 
Tor
Browser's security features
-+-
 Reporter:  isabela  |  Owner:
 |  antonela
 Type:  project  | Status:
 |  needs_revision
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ux-team, GeorgKoppen201812,  |  Actual Points:
  TorBrowserTeam201903R, tbb-8.5 |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor17
-+-

Comment (by pospeselr):

 Replying to [comment:92 mcs]:
 > Thanks for the updated branches. Kathy and I noticed only a few
 remaining things:
 >
 > securityLevel.js - SecurityLevelStrings:
 >  Is it worth it to rely on the getLocale() function from Torbutton?
 >  (maybe your answer is "yes")

 My inclination is to leave it with the torbutton implementation, since it
 presumably works :)

 > Regarding the question you asked about how to handle the toolbar icons
 in an upgrade situation, I don't think there is a simple solution. You
 probably need to dig through
 `browser/components/customizableui/CustomizableUI.jsm` and figure out what
 to do. Hopefully you can do what is needed by using some combination of
 `addWidgetToArea()`, `removeWidgetFromArea()`, and
 `moveWidgetWithinArea()`. There is probaly also a way to get the UI to
 reconfigure itself after the `browser.uiCustomization.state` pref is
 modified, so you could edit that pref value via code... but we should
 probably avoid completely resetting everyone's toolbars to the default set
 of icons.

 I was more curious if there was a way to determine that the browser had
 been updated, so that we can then put the Security Level button in the
 toolbar. Inserting the button is just a matter of finding the right js to
 call.

 new branch with latest tor-browser changes:
 https://gitweb.torproject.org/user/richard/tor-
 browser.git/commit/?h=bug_25658_v4

 Screenshot with updated about:preferences ui:
 
https://trac.torproject.org/projects/tor/attachment/ticket/25658/screenshot06.png

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #25658 [Applications/Tor Browser]: Activity 2.1: Improve user understanding and user control by clarifying Tor Browser's security features

[Tor Bug Tracker & Wiki]

#25658: Activity 2.1: Improve user understanding and user control by clarifying 
Tor
Browser's security features
-+-
 Reporter:  isabela  |  Owner:
 |  antonela
 Type:  project  | Status:
 |  needs_revision
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ux-team, GeorgKoppen201812,  |  Actual Points:
  TorBrowserTeam201903R, tbb-8.5 |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor17
-+-
Changes (by pospeselr):

 * Attachment "screenshot06.png" added.


--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #25658 [Applications/Tor Browser]: Activity 2.1: Improve user understanding and user control by clarifying Tor Browser's security features

[Tor Bug Tracker & Wiki]

#25658: Activity 2.1: Improve user understanding and user control by clarifying 
Tor
Browser's security features
-+-
 Reporter:  isabela  |  Owner:
 |  antonela
 Type:  project  | Status:
 |  needs_revision
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ux-team, GeorgKoppen201812,  |  Actual Points:
  TorBrowserTeam201903R, tbb-8.5 |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor17
-+-
Changes (by antonela):

 * Attachment "3.x-restore-defaults.png" added.


--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #25658 [Applications/Tor Browser]: Activity 2.1: Improve user understanding and user control by clarifying Tor Browser's security features

[Tor Bug Tracker & Wiki]

#25658: Activity 2.1: Improve user understanding and user control by clarifying 
Tor
Browser's security features
-+-
 Reporter:  isabela  |  Owner:
 |  antonela
 Type:  project  | Status:
 |  needs_revision
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ux-team, GeorgKoppen201812,  |  Actual Points:
  TorBrowserTeam201903R, tbb-8.5 |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor17
-+-

Comment (by antonela):

 Re: Restore Defaults for Custom Settings.

 We have the right UI implementation at the Security Level doorhanger based
 on reviewed mocks.  Comment:86 is suggesting that we can have a better
 revert action flow at `about:preferences`.

 [[Image(https://trac.torproject.org/projects/tor/raw-
 attachment/ticket/25658/3.0.3-restore-defaults.png, 700px)]]
 [[Image(https://trac.torproject.org/projects/tor/raw-
 attachment/ticket/25658/3.x-restore-defaults.png, 700px)]]

 Do you think is better to remove the `Restore Defaults` button for all
 cases and just add the `Restore Defaults` inline link when `Custom` is
 enabled? I think so.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #25658 [Applications/Tor Browser]: Activity 2.1: Improve user understanding and user control by clarifying Tor Browser's security features (was: Actity 2.1: Improve user understanding a

[Tor Bug Tracker & Wiki]

#25658: Activity 2.1: Improve user understanding and user control by clarifying 
Tor
Browser's security features
-+-
 Reporter:  isabela  |  Owner:
 |  antonela
 Type:  project  | Status:
 |  needs_revision
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ux-team, GeorgKoppen201812,  |  Actual Points:
  TorBrowserTeam201903R, tbb-8.5 |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor17
-+-
Changes (by antonela):

 * Attachment "3.x-restore-defaults.png" removed.


--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #25658 [Applications/Tor Browser]: Activity 2.1: Improve user understanding and user control by clarifying Tor Browser's security features

[Tor Bug Tracker & Wiki]

#25658: Activity 2.1: Improve user understanding and user control by clarifying 
Tor
Browser's security features
-+-
 Reporter:  isabela  |  Owner:
 |  antonela
 Type:  project  | Status:
 |  needs_revision
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ux-team, GeorgKoppen201812,  |  Actual Points:
  TorBrowserTeam201903R, tbb-8.5 |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor17
-+-
Changes (by antonela):

 * Attachment "3.0.3-restore-defaults.png" added.


--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #25658 [Applications/Tor Browser]: Activity 2.1: Improve user understanding and user control by clarifying Tor Browser's security features

[Tor Bug Tracker & Wiki]

#25658: Activity 2.1: Improve user understanding and user control by clarifying 
Tor
Browser's security features
-+-
 Reporter:  isabela  |  Owner:
 |  antonela
 Type:  project  | Status:
 |  needs_revision
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ux-team, GeorgKoppen201812,  |  Actual Points:
  TorBrowserTeam201903R, tbb-8.5 |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor17
-+-
Changes (by antonela):

 * Attachment "3.x-restore-defaults.png" added.


--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #25658 [Applications/Tor Browser]: Activity 2.1: Improve user understanding and user control by clarifying Tor Browser's security features

[Tor Bug Tracker & Wiki]

#25658: Activity 2.1: Improve user understanding and user control by clarifying 
Tor
Browser's security features
-+-
 Reporter:  isabela  |  Owner:
 |  antonela
 Type:  project  | Status:
 |  needs_revision
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ux-team, GeorgKoppen201812,  |  Actual Points:
  TorBrowserTeam201903R, tbb-8.5 |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor17
-+-

Comment (by mcs):

 Thanks for the updated branches. Kathy and I noticed only a few remaining
 things:

 securityLevel.js - SecurityLevelStrings:
  Is it worth it to rely on the getLocale() function from Torbutton?
  (maybe your answer is "yes")

 securityLevel.js - SecurityLevelPanel:
   Remove the comment inside `openAdvancedSecuritySettings()`.

 securityLevelPanel.css:
   Please remove the commented out `margin` lines.

 Regarding the question you asked about how to handle the toolbar icons in
 an upgrade situation, I don't think there is a simple solution. You
 probably need to dig through
 `browser/components/customizableui/CustomizableUI.jsm` and figure out what
 to do. Hopefully you can do what is needed by using some combination of
 `addWidgetToArea()`, `removeWidgetFromArea()`, and
 `moveWidgetWithinArea()`. There is probaly also a way to get the UI to
 reconfigure itself after the `browser.uiCustomization.state` pref is
 modified, so you could edit that pref value via code... but we should
 probably avoid completely resetting everyone's toolbars to the default set
 of icons.

 By the way, it will be easier for us to look at what you fixed during a
 review cycle if you adopt the practice of creating and pushing new
 branches instead of doing an amend commit followed by a forced push (that
 way, we can easily compare the old and new branches).

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #25658 [Applications/Tor Browser]: Activity 2.1: Improve user understanding and user control by clarifying Tor Browser's security features

[Tor Bug Tracker & Wiki]

#25658: Activity 2.1: Improve user understanding and user control by clarifying 
Tor
Browser's security features
-+-
 Reporter:  isabela  |  Owner:
 |  antonela
 Type:  project  | Status:
 |  needs_revision
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ux-team, GeorgKoppen201812,  |  Actual Points:
  TorBrowserTeam201903R, tbb-8.5 |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor17
-+-

Comment (by pospeselr):

 Replying to [comment:89 antonela]:
 > Replying to [comment:86 mcs]:
 > > 5. If custom mode is triggered, it is a little confusing that there is
 no text in about:preferences to encourage the user to switch back to one
 of the default levels (new users may even think custom is a good thing).
 Also, there is nothing in about:preferences that associates the `Restore
 Defaults` button with fixing the "custom problem." Finally, we might want
 to hide the `Restore Defaults` button when it is not applicable instead of
 disabling it (I think users will wonder why it is disabled). These issues
 might be worth looking at in future iteration.
 > >
 > Good call. We included the revert action for custom settings at the
 doorhanger. I think we can easily add the `Restore defaults` blue primary
 link at the selected level in `about:preferences` too.

 Hey antonela, could you clarify how this should look?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #25658 [Applications/Tor Browser]: Activity 2.1: Improve user understanding and user control by clarifying Tor Browser's security features

[Tor Bug Tracker & Wiki]

#25658: Activity 2.1: Improve user understanding and user control by clarifying 
Tor
Browser's security features
-+-
 Reporter:  isabela  |  Owner:
 |  antonela
 Type:  project  | Status:
 |  needs_revision
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ux-team, GeorgKoppen201812,  |  Actual Points:
  TorBrowserTeam201903R, tbb-8.5 |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor17
-+-

Comment (by mcs):

 Here are our comments on the Torbutton changes:

 1. Shorten the first line of the commit message if possible.

 2. `src/chrome/content/preferences.js` is no longer used and should be
 removed.

 3. The following entities are no longer used and should be removed from
 the.dtd files:
 * torbutton.context_menu.preferences
 * torbutton.context_menu.preferences.key
 * torbutton.prefs.custom_warning
 * torbutton.prefs.restore_defaults

 4. You don't need to add empty `securityLevel.properties` files; all of
 the necessary files will be added when Georg runs the `trans_tools/import-
 translations.sh` script before making a release.

 5. Related to point 4: please add support for `securityLevel.properties`
 to `trans_tools/import-translations.sh`. And maybe open a ticket to have
 emmapeel add it to Transifex.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #25658 [Applications/Tor Browser]: Activity 2.1: Improve user understanding and user control by clarifying Tor Browser's security features

[Tor Bug Tracker & Wiki]

#25658: Activity 2.1: Improve user understanding and user control by clarifying 
Tor
Browser's security features
-+-
 Reporter:  isabela  |  Owner:
 |  antonela
 Type:  project  | Status:
 |  needs_revision
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ux-team, GeorgKoppen201812,  |  Actual Points:
  TorBrowserTeam201903R, tbb-8.5 |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor17
-+-

Comment (by antonela):

 Replying to [comment:86 mcs]:

 > This is an impressive piece of work. Kathy and I finished reviewing the
 tor-browser changes as well as the overall behavior. We are still working
 on our review of the torbutton changes but hope to post our comments later
 today. Here are our comments on behavior (most of these are for Antonela
 to look at):
 >
 It is! Thanks for this review mcs/brade!


 > 1. It would be nice to have a dynamic tooltip for the toolbar item so
 that the active level is visible, e.g., `Security Level: Safer`
 >
 Yes, it shouldn't be so hard. To be clear, do you mean a label at the
 toolbar? Or a good copy that replaces this `Security Settings`?
 https://share.riseup.net/#IVhf0vupZqeSezuQSBzTGg. If is the second, then
 your suggestion is great.


 > 2. It would be nice to eliminate "slider" everywhere, including from the
 `Learn more` link. That will require some coordination with the
 maintainers of tb-manual.torproject.org. Maybe use https://tb-
 manual.torproject.org/.../security-settings.html
 >
 Agreed. I'm syncing with Maggie from the community team this week to have
 the Manual updated as well.



 > 3. The Marvel app design uses the term `Default` instead of `Standard`.
 Am I looking at the wrong design?
 >
 You are looking at the right design, and I think we should keep the same
 labels we have now. Defaults are negotiable and `Standard` works better
 for this scenario.



 > 4. The Marvel app design has an disclosure arrow (`>`) in the panel for
 "Advanced Security Settings". Is that important to include in the
 implementation?
 >
 You right. We are using the `...` to announce the navigation. I think we
 are ok. It aims to replicate the Firefox pattern we have at the Control
 Center doorhanger.



 > 5. If custom mode is triggered, it is a little confusing that there is
 no text in about:preferences to encourage the user to switch back to one
 of the default levels (new users may even think custom is a good thing).
 Also, there is nothing in about:preferences that associates the `Restore
 Defaults` button with fixing the "custom problem." Finally, we might want
 to hide the `Restore Defaults` button when it is not applicable instead of
 disabling it (I think users will wonder why it is disabled). These issues
 might be worth looking at in future iteration.
 >
 Good call. We included the revert action for custom settings at the
 doorhanger. I think we can easily add the `Restore defaults` blue primary
 link at the selected level in `about:preferences` too.


 > 6. On macOS at least, the toolbar layout does not match the proposal.
 With a clean profile, the Torbutton icon is on the left side of the
 toolbar instead of the right side and the NoScript and HTTPS-E icons are
 present.
 >

 I got the same issue before and I think is because somehow we are sharing
 profiles between stable configuration and nightly one. Since I have more
 than a dozen Tor Browsers installed in my computer, I cannot debug this
 properly.


 > 7. Related to 6., after upgrading from an 8.5a8 profile, there is one
 additional problem: the security settings icon is missing from the
 toolbar.
 >
 I think this one was fixed on a recent commit. pospeselr?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #25658 [Applications/Tor Browser]: Activity 2.1: Improve user understanding and user control by clarifying Tor Browser's security features

[Tor Bug Tracker & Wiki]

#25658: Activity 2.1: Improve user understanding and user control by clarifying 
Tor
Browser's security features
-+-
 Reporter:  isabela  |  Owner:
 |  antonela
 Type:  project  | Status:
 |  needs_revision
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ux-team, GeorgKoppen201812,  |  Actual Points:
  TorBrowserTeam201903R, tbb-8.5 |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor17
-+-

Comment (by pospeselr):

 Thanks mcs, that's a nice thing to say :)

 1. That sounds reasonable and easily done
 2. Agree, the link is currently a placeholder. I opened #29657 to track
 this.
 3. I brought this up with antonela previously, and the direction was to
 use Standard rather than Default
 4. I took some liberty here, and opted to use the ellipsis syntax to match
 the existing 'Clear Cookies and Site Data...' command at the bottom of the
 Site Information dialog in firefox.
 5. This sounds reasonable, will wait for antonela to comment.
 6. Yeah I *believe* the version you have doesn't have my toolbar changes.
 A clean build (on Linux) has NoScript and HTTPS-Everywhere removed, will
 have to look into the torbutton issue. #23359 will need to be fixed before
 the icons work correctly.
 7. This behaviour is expected as there isn't any upgrade logic in place.
 How is this sort of thing usually handled?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #25658 [Applications/Tor Browser]: Activity 2.1: Improve user understanding and user control by clarifying Tor Browser's security features

[Tor Bug Tracker & Wiki]

#25658: Activity 2.1: Improve user understanding and user control by clarifying 
Tor
Browser's security features
-+-
 Reporter:  isabela  |  Owner:
 |  antonela
 Type:  project  | Status:
 |  needs_revision
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ux-team, GeorgKoppen201812,  |  Actual Points:
  TorBrowserTeam201903R, tbb-8.5 |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor17
-+-
Changes (by mcs):

 * status:  needs_review => needs_revision


Comment:

 Here are our comments on the tor-browser changes (by the way, thanks for
 writing code that is nicely organized and easy to read):

 High level questions for Georg and others:
 1. Should we add copyright notices to the
 `browser/components/securitylevel/` files?
 2. Should we rename the `security_slider` pref and migrate the old value
 at this time, or later, or never? Maybe use the name
 `torbrowser.security_level` and migrate to contiguous values (1-3).


 Commit message:
 1. The first line is very long. Maybe shorten to `Bug 25658: Replace
 security slider with security level UI`.
 2. s/hangar/hanger/ (two occurrences).

 browser/app/profile/000-tor-browser.js - there are some additional
 NoScript and HTTPS-E references that should be removed from the
 `browser.uiCustomization.state` value:
 * https-everywhere-button
 * https-everywhere_eff_org-browser-action
 * _73a6fe31-595d-460b-a920-fcc0f8843232_-browser-action

 securityLevelPanel.css - please combine all of the margin-related rules
 into one within each CSS selector block, or at least put them on adjacent
 lines so it is easy to spot the margin things.

 securityLevel.js - SecurityLevelStrings:
 1. The `intialize our strings with en-US defaults...` comment seems a
 little backwards. Maybe replace with `read localized strings from
 Torbutton; use hard-coded en-US strings as fallback`
 2. Is it worth it to rely on the `getlocale()` function from Torbutton?
 3. There is one `/` missing after `https:` in the URL. It still works
 though!

 securityLevel.js - SecurityLevelPrefs:
 1. The `_str` suffix for the pref name constants is a little confusing.
 Maybe use `_pref` instead.

 securityLevel.js - SecurityLevelButton:
 1. Consider renaming `securitySlider` to `securityLevel` (and maybe rename
 the pref getter too).
 2. Kathy and I think the function name `_readPrefsInternal` could be
 better, e.g., replace all occurrences with `_configUIFromPrefs()`.

 securityLevel.js - SecurityLevelPanel:
 1. In the `panel` getter, `_panel` is set but not used anywhere else.
 Maybe you meant to cache that value?
 2. Remove the comment inside `openAdvancedSecuritySettings()`.
 3. For `_populateXUL()`: if you have time and can do it cleanly, consider
 adding a helper function that sets the strings within each of the three
 radio sections (the code is very similar for each).

 securityLevel.js - SecurityLevelPreferences:
 1. _populateXUL(): remove blank line before closing brace within
 `vboxStandard` section.

 securityLevel.js - miscellaneous typos:
  s/abotu/about/
  s/hangar/hanger/
  s/lable/label/
  s/re-render/re-renders/
  s/scurity/security/
  s/upate/update/
  s/if(/if (/

 securityLevel.js - remove blank lines at the beginning of function bodies:
  SecurityLevelButton.init()
  SecurityLevelButton.onCustomizeEnd()
  SecurityLevelPreferences.init()
  SecurityLevelPreferences.selectSecurityLevel()

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #25658 [Applications/Tor Browser]: Activity 2.1: Improve user understanding and user control by clarifying Tor Browser's security features

[Tor Bug Tracker & Wiki]

#25658: Activity 2.1: Improve user understanding and user control by clarifying 
Tor
Browser's security features
-+-
 Reporter:  isabela  |  Owner:
 |  antonela
 Type:  project  | Status:
 |  needs_review
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ux-team, GeorgKoppen201812,  |  Actual Points:
  TorBrowserTeam201903R, tbb-8.5 |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor17
-+-

Comment (by mcs):

 This is an impressive piece of work. Kathy and I finished reviewing the
 tor-browser changes as well as the overall behavior. We are still working
 on our review of the torbutton changes but hope to post our comments later
 today. Here are our comments on behavior (most of these are for Antonela
 to look at):
 1. It would be nice to have a dynamic tooltip for the toolbar item so that
 the active level is visible, e.g., `Security Level: Safer`
 2. It would be nice to eliminate "slider" everywhere, including from the
 `Learn more` link. That will require some coordination with the
 maintainers of tb-manual.torproject.org. Maybe use https://tb-
 manual.torproject.org/.../security-settings.html
 3. The Marvel app design uses the term `Default` instead of `Standard`. Am
 I looking at the wrong design?
 4. The Marvel app design has an disclosure arrow (`>`) in the panel for
 "Advanced Security Settings". Is that important to include in the
 implementation?
 5. If custom mode is triggered, it is a little confusing that there is no
 text in about:preferences to encourage the user to switch back to one of
 the default levels (new users may even think custom is a good thing).
 Also, there is nothing in about:preferences that associates the `Restore
 Defaults` button with fixing the "custom problem." Finally, we might want
 to hide the `Restore Defaults` button when it is not applicable instead of
 disabling it (I think users will wonder why it is disabled). These issues
 might be worth looking at in future iteration.
 6. On macOS at least, the toolbar layout does not match the proposal. With
 a clean profile, the Torbutton icon is on the left side of the toolbar
 instead of the right side and the NoScript and HTTPS-E icons are present.
 7. Related to 6., after upgrading from an 8.5a8 profile, there is one
 additional problem: the security settings icon is missing from the
 toolbar.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #25658 [Applications/Tor Browser]: Activity 2.1: Improve user understanding and user control by clarifying Tor Browser's security features

[Tor Bug Tracker & Wiki]

#25658: Activity 2.1: Improve user understanding and user control by clarifying 
Tor
Browser's security features
-+-
 Reporter:  isabela  |  Owner:
 |  antonela
 Type:  project  | Status:
 |  needs_review
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ux-team, GeorgKoppen201812,  |  Actual Points:
  TorBrowserTeam201903R, tbb-8.5 |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor17
-+-

Comment (by pospeselr):

 Amended the tor-browser patch with a fix for #29554 :
 https://gitweb.torproject.org/user/richard/tor-
 browser.git/diff/browser/components/preferences/in-
 content/preferences.js?h=bug_25658_v3

 Clicking 'Advanced Security Settings...' in the hangar now properly
 navigates the user to the new Security Level settings.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #25658 [Applications/Tor Browser]: Activity 2.1: Improve user understanding and user control by clarifying Tor Browser's security features

[Tor Bug Tracker & Wiki]

#25658: Activity 2.1: Improve user understanding and user control by clarifying 
Tor
Browser's security features
-+-
 Reporter:  isabela  |  Owner:
 |  antonela
 Type:  project  | Status:
 |  needs_review
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ux-team, GeorgKoppen201812,  |  Actual Points:
  TorBrowserTeam201903R, tbb-8.5 |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor17
-+-

Comment (by antonela):

 The dark theme version looks legit

 [[Image(https://trac.torproject.org/projects/tor/raw-
 
attachment/ticket/25658/Captura%20de%20pantalla%202019-03-07%20a%20la(s)%2012.48.15%20p.%20m..png,
 700px)]]

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #25658 [Applications/Tor Browser]: Activity 2.1: Improve user understanding and user control by clarifying Tor Browser's security features

[Tor Bug Tracker & Wiki]

#25658: Activity 2.1: Improve user understanding and user control by clarifying 
Tor
Browser's security features
-+-
 Reporter:  isabela  |  Owner:
 |  antonela
 Type:  project  | Status:
 |  needs_review
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ux-team, GeorgKoppen201812,  |  Actual Points:
  TorBrowserTeam201903R, tbb-8.5 |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor17
-+-
Changes (by antonela):

 * Attachment "Captura de pantalla 2019-03-07 a la(s) 12.48.15 p. m..png"
 added.


--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #25658 [Applications/Tor Browser]: Activity 2.1: Improve user understanding and user control by clarifying Tor Browser's security features

[Tor Bug Tracker & Wiki]

#25658: Activity 2.1: Improve user understanding and user control by clarifying 
Tor
Browser's security features
-+-
 Reporter:  isabela  |  Owner:
 |  antonela
 Type:  project  | Status:
 |  needs_review
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ux-team, GeorgKoppen201812,  |  Actual Points:
  TorBrowserTeam201903R  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor17
-+-

Comment (by pospeselr):

 Amended my tor-browser commit ( https://gitweb.torproject.org/user/richard
 /tor-browser.git/commit/?h=bug_25658_v3 ) to include antonela's design
 tweaks and removed noscript from the toolbar. Also fixed the left-align
 issues.

 Updated about:preferences screenshot:

 
https://trac.torproject.org/projects/tor/attachment/ticket/25658/screenshot05.png

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #25658 [Applications/Tor Browser]: Activity 2.1: Improve user understanding and user control by clarifying Tor Browser's security features

[Tor Bug Tracker & Wiki]

#25658: Activity 2.1: Improve user understanding and user control by clarifying 
Tor
Browser's security features
-+-
 Reporter:  isabela  |  Owner:
 |  antonela
 Type:  project  | Status:
 |  needs_review
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ux-team, GeorgKoppen201812,  |  Actual Points:
  TorBrowserTeam201903R  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor17
-+-
Changes (by pospeselr):

 * Attachment "screenshot05.png" added.

 about:preferences tweaks

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #25658 [Applications/Tor Browser]: Activity 2.1: Improve user understanding and user control by clarifying Tor Browser's security features

[Tor Bug Tracker & Wiki]

#25658: Activity 2.1: Improve user understanding and user control by clarifying 
Tor
Browser's security features
-+-
 Reporter:  isabela  |  Owner:
 |  antonela
 Type:  project  | Status:
 |  needs_review
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ux-team, GeorgKoppen201812,  |  Actual Points:
  TorBrowserTeam201903R  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor17
-+-

Comment (by pospeselr):

 **gk**:

 No the screenshots are not from a fresh Tor Browser, rather it's a pre-
 built tor-browser with the new firefox bits deployed over it. If I'm
 understanding things correctly, I can update the 000-torbrowser.js file to
 remove the extension icons from the toolbar. I'll do a full tor-browser-
 build once my changes for torbutton are complete and fix any other issues
 that pop up.

 **antonela**:

 I can make all these change (:

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #25658 [Applications/Tor Browser]: Activity 2.1: Improve user understanding and user control by clarifying Tor Browser's security features

[Tor Bug Tracker & Wiki]

#25658: Activity 2.1: Improve user understanding and user control by clarifying 
Tor
Browser's security features
-+-
 Reporter:  isabela  |  Owner:
 |  antonela
 Type:  project  | Status:
 |  needs_review
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ux-team, GeorgKoppen201812,  |  Actual Points:
  TorBrowserTeam201903R  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor17
-+-

Comment (by antonela):

 Replying to [comment:77 pospeselr]:
 > Patch for torbutton hopefully later this week!

 It looks awesome! Thanks for this work pospeselr!

 A few minor UI details in `about:preferences#`

 - Let's move the `Learn More` link after description. It will looks like

 {{{
 Disable certain web features that can be used to attack your
 security and anonymity. Learn More
 }}}

 - Standard, Safer and Safest titles, could we have it in **bold**?
 - Could we have 2x bottom padding (probably, 6px) between each option?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #25658 [Applications/Tor Browser]: Activity 2.1: Improve user understanding and user control by clarifying Tor Browser's security features

[Tor Bug Tracker & Wiki]

#25658: Activity 2.1: Improve user understanding and user control by clarifying 
Tor
Browser's security features
-+-
 Reporter:  isabela  |  Owner:
 |  antonela
 Type:  project  | Status:
 |  needs_review
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ux-team, GeorgKoppen201812,  |  Actual Points:
  TorBrowserTeam201903R  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor17
-+-

Comment (by gk):

 Just from a quick glance at the screenshots. Are those from a fresh Tor
 Browser? I am asking because one of the ideas related to this ticket was
 to reorganize the toolbar while we are at it, see:
 https://gitweb.torproject.org/tor-browser-spec.git/tree/proposals/101
 -security-controls-redesign.txt section 2.1. At the end we would omit the
 HTTPS-E and NoScript icon and the Torbutton one would be at the right side
 next to the URL bar. Back then when I worked on this ticket I looked at
 that a bit and it was not obvious at least how to prevent WebExtensions
 from showing their icons by default on the toolbar. But maybe I just did
 not look deep enough...

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #25658 [Applications/Tor Browser]: Activity 2.1: Improve user understanding and user control by clarifying Tor Browser's security features

[Tor Bug Tracker & Wiki]

#25658: Activity 2.1: Improve user understanding and user control by clarifying 
Tor
Browser's security features
-+-
 Reporter:  isabela  |  Owner:
 |  antonela
 Type:  project  | Status:
 |  needs_review
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ux-team, GeorgKoppen201812,  |  Actual Points:
  TorBrowserTeam201903R  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor17
-+-
Changes (by gk):

 * keywords:  ux-team, GeorgKoppen201812, TorBrowserTeam201902R => ux-team,
 GeorgKoppen201812, TorBrowserTeam201903R
 * cc: mcs, brade (added)


--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #25658 [Applications/Tor Browser]: Activity 2.1: Improve user understanding and user control by clarifying Tor Browser's security features

[Tor Bug Tracker & Wiki]

#25658: Activity 2.1: Improve user understanding and user control by clarifying 
Tor
Browser's security features
-+-
 Reporter:  isabela  |  Owner:
 |  antonela
 Type:  project  | Status:
 |  needs_review
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ux-team, GeorgKoppen201812,  |  Actual Points:
  TorBrowserTeam201902R  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor17
-+-
Changes (by pospeselr):

 * status:  assigned => needs_review
 * keywords:  ux-team, GeorgKoppen201812, TorBrowserTeam201902 => ux-team,
 GeorgKoppen201812, TorBrowserTeam201902R


Comment:

 tor-browser patch for review! Implements the new Security Level toolbar
 button, hangar, and about:preferences options.

 https://gitweb.torproject.org/user/richard/tor-
 browser.git/commit/?h=bug_25658_v3=a44cbb0565a532847d33552ac71bfa73a0902180

 screenshots:

 
https://trac.torproject.org/projects/tor/attachment/ticket/25658/screenshot01.png
 
https://trac.torproject.org/projects/tor/attachment/ticket/25658/screenshot02.png
 
https://trac.torproject.org/projects/tor/attachment/ticket/25658/screenshot03.png
 
https://trac.torproject.org/projects/tor/attachment/ticket/25658/screenshot04.png

 Patch for torbutton hopefully later this week!

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #25658 [Applications/Tor Browser]: Activity 2.1: Improve user understanding and user control by clarifying Tor Browser's security features

[Tor Bug Tracker & Wiki]

#25658: Activity 2.1: Improve user understanding and user control by clarifying 
Tor
Browser's security features
-+-
 Reporter:  isabela  |  Owner:
 |  antonela
 Type:  project  | Status:
 |  assigned
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ux-team, GeorgKoppen201812,  |  Actual Points:
  TorBrowserTeam201902   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor17
-+-
Changes (by pospeselr):

 * Attachment "screenshot04.png" added.


--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #25658 [Applications/Tor Browser]: Activity 2.1: Improve user understanding and user control by clarifying Tor Browser's security features

[Tor Bug Tracker & Wiki]

#25658: Activity 2.1: Improve user understanding and user control by clarifying 
Tor
Browser's security features
-+-
 Reporter:  isabela  |  Owner:
 |  antonela
 Type:  project  | Status:
 |  assigned
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ux-team, GeorgKoppen201812,  |  Actual Points:
  TorBrowserTeam201902   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor17
-+-
Changes (by pospeselr):

 * Attachment "screenshot02.png" added.


--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #25658 [Applications/Tor Browser]: Activity 2.1: Improve user understanding and user control by clarifying Tor Browser's security features

[Tor Bug Tracker & Wiki]

#25658: Activity 2.1: Improve user understanding and user control by clarifying 
Tor
Browser's security features
-+-
 Reporter:  isabela  |  Owner:
 |  antonela
 Type:  project  | Status:
 |  assigned
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ux-team, GeorgKoppen201812,  |  Actual Points:
  TorBrowserTeam201902   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor17
-+-
Changes (by pospeselr):

 * Attachment "screenshot03.png" added.


--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #25658 [Applications/Tor Browser]: Activity 2.1: Improve user understanding and user control by clarifying Tor Browser's security features

[Tor Bug Tracker & Wiki]

#25658: Activity 2.1: Improve user understanding and user control by clarifying 
Tor
Browser's security features
-+-
 Reporter:  isabela  |  Owner:
 |  antonela
 Type:  project  | Status:
 |  assigned
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ux-team, GeorgKoppen201812,  |  Actual Points:
  TorBrowserTeam201902   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor17
-+-
Changes (by pospeselr):

 * Attachment "screenshot01.png" added.


--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #25658 [Applications/Tor Browser]: Activity 2.1: Improve user understanding and user control by clarifying Tor Browser's security features

[Tor Bug Tracker & Wiki]

#25658: Activity 2.1: Improve user understanding and user control by clarifying 
Tor
Browser's security features
-+-
 Reporter:  isabela  |  Owner:
 |  antonela
 Type:  project  | Status:
 |  assigned
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ux-team, TorBrowserTeam201812,   |  Actual Points:
  GeorgKoppen201812  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor17
-+-
Changes (by antonela):

 * Attachment "assets.zip" added.


--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #25658 [Applications/Tor Browser]: Activity 2.1: Improve user understanding and user control by clarifying Tor Browser's security features

[Tor Bug Tracker & Wiki]

#25658: Activity 2.1: Improve user understanding and user control by clarifying 
Tor
Browser's security features
-+-
 Reporter:  isabela  |  Owner:
 |  antonela
 Type:  project  | Status:
 |  assigned
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ux-team, TorBrowserTeam201812,   |  Actual Points:
  GeorgKoppen201812  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor17
-+-

Comment (by gk):

 Note to self: we need to adapt the onboarding here as well, pointing to
 the new place of the settings.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #25658 [Applications/Tor Browser]: Activity 2.1: Improve user understanding and user control by clarifying Tor Browser's security features

[Tor Bug Tracker & Wiki]

#25658: Activity 2.1: Improve user understanding and user control by clarifying 
Tor
Browser's security features
-+-
 Reporter:  isabela  |  Owner:
 |  antonela
 Type:  project  | Status:
 |  assigned
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ux-team, TorBrowserTeam201812,   |  Actual Points:
  GeorgKoppen201812  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor17
-+-

Comment (by gk):

 Replying to [comment:31 gk]:
 > #27511 is a duplicate (for the "New Identity" on the toolbar part).

 Thinking more about it that's the wrong decision. Let's have this idea in
 an own ticket and do not clutter this bug more with orthogonal features. I
 reopened #27511.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #25658 [Applications/Tor Browser]: Activity 2.1: Improve user understanding and user control by clarifying Tor Browser's security features

[Tor Bug Tracker & Wiki]

#25658: Activity 2.1: Improve user understanding and user control by clarifying 
Tor
Browser's security features
-+-
 Reporter:  isabela  |  Owner:
 |  antonela
 Type:  project  | Status:
 |  assigned
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ux-team, TorBrowserTeam201812,   |  Actual Points:
  GeorgKoppen201812  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor17
-+-
Changes (by gk):

 * cc: arthuredelstein (added)


Comment:

 #22980 is a duplicate.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #25658 [Applications/Tor Browser]: Activity 2.1: Improve user understanding and user control by clarifying Tor Browser's security features

[Tor Bug Tracker & Wiki]

#25658: Activity 2.1: Improve user understanding and user control by clarifying 
Tor
Browser's security features
-+-
 Reporter:  isabela  |  Owner:
 |  antonela
 Type:  project  | Status:
 |  assigned
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ux-team, TorBrowserTeam201812,   |  Actual Points:
  GeorgKoppen201812  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor17
-+-
Changes (by gk):

 * keywords:  ux-team, TorBrowserTeam201811 => ux-team,
 TorBrowserTeam201812, GeorgKoppen201812


--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #25658 [Applications/Tor Browser]: Activity 2.1: Improve user understanding and user control by clarifying Tor Browser's security features

[Tor Bug Tracker & Wiki]

#25658: Activity 2.1: Improve user understanding and user control by clarifying 
Tor
Browser's security features
---+---
 Reporter:  isabela|  Owner:  antonela
 Type:  project| Status:  assigned
 Priority:  High   |  Milestone:
Component:  Applications/Tor Browser   |Version:
 Severity:  Normal | Resolution:
 Keywords:  ux-team, TorBrowserTeam201811  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:  Sponsor17
---+---

Comment (by antonela):

 Replying to [comment:68 gk]:
 > We did not talk about the restart "options" yesterday. Are those two you
 have included in the prototype two options for the same thing or are they
 supposed to show up at the same time or...?
 >
 yes, two options for the same intent.

 > I am wondering whether we should just strongly encourage to restart
 after the slider level change or indeed require a restart before the new
 settings are applied. I am inclined to do the former as this feels more
 natural on that preference pane given that all the other options "go live"
 once the users selects them. But I don't feel too strongly about it.

 Agreed. The option a] is a typical pattern in Chrome70. It is great
 because the button pill shows up right close to the cursor pointer. The
 user attention is already there.
 The option b] is using a Firefox warning approach.

 a] downgrade, safest → safer
 ​https://marvelapp.com/a66fg97/screen/50342988
 b] downgrade, safest → safer
 ​https://marvelapp.com/a66fg97/screen/50342987

 Which one do you prefer?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #25658 [Applications/Tor Browser]: Activity 2.1: Improve user understanding and user control by clarifying Tor Browser's security features

[Tor Bug Tracker & Wiki]

#25658: Activity 2.1: Improve user understanding and user control by clarifying 
Tor
Browser's security features
---+---
 Reporter:  isabela|  Owner:  antonela
 Type:  project| Status:  assigned
 Priority:  High   |  Milestone:
Component:  Applications/Tor Browser   |Version:
 Severity:  Normal | Resolution:
 Keywords:  ux-team, TorBrowserTeam201811  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:  Sponsor17
---+---

Comment (by antonela):

 Replying to [comment:67 gk]:
 > Sounds good. We probably should grey out the security settings on the
 `about:preferences` page indicating additionally that the user is in
 custom mode until they restored reset they settings to one of the three
 defaults.

 Great. I'm using default Firefox Photon warnings and I made a quick
 prototype to see how it works. Grey out is a good option, not sure if
 strong enough, but the change is visible when users go back to a tab or
 open a new one. We have a redundant link to `about:preferences#security`.
 Not bad, tho.

 https://marvelapp.com/a66fg97/screen/50307825 - open a new tab to start
 the flow
 https://design.firefox.com/photon/patterns/warnings.html

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #25658 [Applications/Tor Browser]: Activity 2.1: Improve user understanding and user control by clarifying Tor Browser's security features

[Tor Bug Tracker & Wiki]

#25658: Activity 2.1: Improve user understanding and user control by clarifying 
Tor
Browser's security features
---+---
 Reporter:  isabela|  Owner:  antonela
 Type:  project| Status:  assigned
 Priority:  High   |  Milestone:
Component:  Applications/Tor Browser   |Version:
 Severity:  Normal | Resolution:
 Keywords:  ux-team, TorBrowserTeam201811  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:  Sponsor17
---+---

Comment (by gk):

 Replying to [comment:66 antonela]:
 > As we signed yesterday, the prototype is updated with the shield icon.
 > https://marvelapp.com/a66fg97/screen/50307815

 We did not talk about the restart "options" yesterday. Are those two you
 have included in the prototype two options for the same thing or are they
 supposed to show up at the same time or...?

 I am wondering whether we should just strongly encourage to restart after
 the slider level change or indeed require a restart before the new
 settings are applied. I am inclined to do the former as this feels more
 natural on that preference pane given that all the other options "go live"
 once the users selects them. But I don't feel too strongly about it.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #25658 [Applications/Tor Browser]: Activity 2.1: Improve user understanding and user control by clarifying Tor Browser's security features

[Tor Bug Tracker & Wiki]

#25658: Activity 2.1: Improve user understanding and user control by clarifying 
Tor
Browser's security features
---+---
 Reporter:  isabela|  Owner:  antonela
 Type:  project| Status:  assigned
 Priority:  High   |  Milestone:
Component:  Applications/Tor Browser   |Version:
 Severity:  Normal | Resolution:
 Keywords:  ux-team, TorBrowserTeam201811  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:  Sponsor17
---+---

Comment (by gk):

 Replying to [comment:65 antonela]:
 > Replying to [comment:64 mcs]:
 > > Replying to [comment:45 gk]:
 > > > One final thought: What do we do in the new design once a user flips
 a preference that is governed by our security controls essentially kicking
 themselves off that security level to something custom? Right now our UI
 gives the hint with the option to restore the default state. It seems to
 me we should keep that in the new UI as well.
 > >
 >
 > To be on the same page about this specific user story:
 > I'm a technical user at the safest mode and I cannot see a .svg content.
 I go to `about:config` and I enable .svg support. Then I'm back to my tab,
 I reload and see the blocked content now.

 Yes.

 > How do we want this kind of `Restore Defaults` work? per tab or global?

 Gobal. The preferences that are governed by the slider and causing the
 "custom" mode are global as well.

 > How this`Restore Defaults` works now? Does it put the current security
 setting level at default? or does it put the general settings to default?

 It keeps all prefs from the current level and which did not get flipped as
 they are the dialog and button mcs included above is shown. If defaults
 are restored the users goes back to the security level they were on before
 flipping prefs in `about:config`.

 > For both cases, I'd add an alert at the doorhanger and lead the user
 restore defaults at `about:preferences#security`, as illustrated in
 comment:55
 > https://marvelapp.com/a66fg97/screen/50343707

 Sounds good. We probably should grey out the security settings on the
 `about:preferences` page indicating additionally that the user is in
 custom mode until they restored reset they settings to one of the three
 defaults.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #25658 [Applications/Tor Browser]: Activity 2.1: Improve user understanding and user control by clarifying Tor Browser's security features

[Tor Bug Tracker & Wiki]

#25658: Activity 2.1: Improve user understanding and user control by clarifying 
Tor
Browser's security features
---+---
 Reporter:  isabela|  Owner:  antonela
 Type:  project| Status:  assigned
 Priority:  High   |  Milestone:
Component:  Applications/Tor Browser   |Version:
 Severity:  Normal | Resolution:
 Keywords:  ux-team, TorBrowserTeam201811  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:  Sponsor17
---+---

Comment (by antonela):

 As we signed yesterday, the prototype is updated with the shield icon.
 https://marvelapp.com/a66fg97/screen/50307815

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #25658 [Applications/Tor Browser]: Activity 2.1: Improve user understanding and user control by clarifying Tor Browser's security features

[Tor Bug Tracker & Wiki]

#25658: Activity 2.1: Improve user understanding and user control by clarifying 
Tor
Browser's security features
---+---
 Reporter:  isabela|  Owner:  antonela
 Type:  project| Status:  assigned
 Priority:  High   |  Milestone:
Component:  Applications/Tor Browser   |Version:
 Severity:  Normal | Resolution:
 Keywords:  ux-team, TorBrowserTeam201811  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:  Sponsor17
---+---

Comment (by antonela):

 Replying to [comment:64 mcs]:
 > Replying to [comment:45 gk]:
 > > One final thought: What do we do in the new design once a user flips a
 preference that is governed by our security controls essentially kicking
 themselves off that security level to something custom? Right now our UI
 gives the hint with the option to restore the default state. It seems to
 me we should keep that in the new UI as well.
 >

 To be on the same page about this specific user story:
 I'm a technical user at the safest mode and I cannot see a .svg content. I
 go to `about:config` and I enable .svg support. Then I'm back to my tab, I
 reload and see the blocked content now.

 How do we want this kind of `Restore Defaults` work? per tab or global?
 How this`Restore Defaults` works now? Does it put the current security
 setting level at default? or does it put the general settings to default?

 For both cases, I'd add an alert at the doorhanger and lead the user
 restore defaults at `about:preferences#security`, as illustrated in
 comment:55
 https://marvelapp.com/a66fg97/screen/50343707

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #25658 [Applications/Tor Browser]: Activity 2.1: Improve user understanding and user control by clarifying Tor Browser's security features

[Tor Bug Tracker & Wiki]

#25658: Activity 2.1: Improve user understanding and user control by clarifying 
Tor
Browser's security features
---+---
 Reporter:  isabela|  Owner:  antonela
 Type:  project| Status:  assigned
 Priority:  High   |  Milestone:
Component:  Applications/Tor Browser   |Version:
 Severity:  Normal | Resolution:
 Keywords:  ux-team, TorBrowserTeam201811  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:  Sponsor17
---+---

Comment (by mcs):

 Replying to [comment:45 gk]:
 > One final thought: What do we do in the new design once a user flips a
 preference that is governed by our security controls essentially kicking
 themselves off that security level to something custom? Right now our UI
 gives the hint with the option to restore the default state. It seems to
 me we should keep that in the new UI as well.

 For reference, the following screenshot shows how that looks in the
 current design (Tor Browser 8.0.x):

 [[Image(TB 8.0.3 custom prefs.png)]]

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #25658 [Applications/Tor Browser]: Activity 2.1: Improve user understanding and user control by clarifying Tor Browser's security features

[Tor Bug Tracker & Wiki]

#25658: Activity 2.1: Improve user understanding and user control by clarifying 
Tor
Browser's security features
---+---
 Reporter:  isabela|  Owner:  antonela
 Type:  project| Status:  assigned
 Priority:  High   |  Milestone:
Component:  Applications/Tor Browser   |Version:
 Severity:  Normal | Resolution:
 Keywords:  ux-team, TorBrowserTeam201811  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:  Sponsor17
---+---
Changes (by mcs):

 * Attachment "TB 8.0.3 custom prefs.png" added.

 Tor Browser 8.0.x security dialog after a pref governed by the slider has
 been flipped via about:config

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #25658 [Applications/Tor Browser]: Activity 2.1: Improve user understanding and user control by clarifying Tor Browser's security features

[Tor Bug Tracker & Wiki]

#25658: Activity 2.1: Improve user understanding and user control by clarifying 
Tor
Browser's security features
---+---
 Reporter:  isabela|  Owner:  antonela
 Type:  project| Status:  assigned
 Priority:  High   |  Milestone:
Component:  Applications/Tor Browser   |Version:
 Severity:  Normal | Resolution:
 Keywords:  ux-team, TorBrowserTeam201811  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:  Sponsor17
---+---

Comment (by pili):

 If the shield doesn't work out, I made this up out of antonela's tor
 browser icon:

 [[Image(https://trac.torproject.org/projects/tor/raw-
 attachment/ticket/25658/onions-security.png, 100px)]]

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #25658 [Applications/Tor Browser]: Activity 2.1: Improve user understanding and user control by clarifying Tor Browser's security features

[Tor Bug Tracker & Wiki]

#25658: Activity 2.1: Improve user understanding and user control by clarifying 
Tor
Browser's security features
---+---
 Reporter:  isabela|  Owner:  antonela
 Type:  project| Status:  assigned
 Priority:  High   |  Milestone:
Component:  Applications/Tor Browser   |Version:
 Severity:  Normal | Resolution:
 Keywords:  ux-team, TorBrowserTeam201811  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:  Sponsor17
---+---
Changes (by pili):

 * Attachment "onions-security.png" added.


--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #25658 [Applications/Tor Browser]: Activity 2.1: Improve user understanding and user control by clarifying Tor Browser's security features

[Tor Bug Tracker & Wiki]

#25658: Activity 2.1: Improve user understanding and user control by clarifying 
Tor
Browser's security features
---+---
 Reporter:  isabela|  Owner:  antonela
 Type:  project| Status:  assigned
 Priority:  High   |  Milestone:
Component:  Applications/Tor Browser   |Version:
 Severity:  Normal | Resolution:
 Keywords:  ux-team, TorBrowserTeam201811  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:  Sponsor17
---+---

Comment (by antonela):

 Replying to [comment:61 brade]:
 > If we need to stick with the padlock, I think it would be clearer if
 state "1" was an unlocked padlock vs. 2 and 3 with the locked padlock.  Do
 you have space to "open" the padlock for state 1?

 At the first iterations of this ticket, the initial feedback I received
 was to ''don't show the first state as insecure because using Tor Browser
 on default mode is safer than regular browsers''. What is true.

 That said, I gave a try
 [[Image(https://trac.torproject.org/projects/tor/raw-
 attachment/ticket/25658/25658%20-%2010.png, 700px)]]

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #25658 [Applications/Tor Browser]: Activity 2.1: Improve user understanding and user control by clarifying Tor Browser's security features

[Tor Bug Tracker & Wiki]

#25658: Activity 2.1: Improve user understanding and user control by clarifying 
Tor
Browser's security features
---+---
 Reporter:  isabela|  Owner:  antonela
 Type:  project| Status:  assigned
 Priority:  High   |  Milestone:
Component:  Applications/Tor Browser   |Version:
 Severity:  Normal | Resolution:
 Keywords:  ux-team, TorBrowserTeam201811  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:  Sponsor17
---+---
Changes (by antonela):

 * Attachment "25658 - 10.png" added.


--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #25658 [Applications/Tor Browser]: Activity 2.1: Improve user understanding and user control by clarifying Tor Browser's security features

[Tor Bug Tracker & Wiki]

#25658: Activity 2.1: Improve user understanding and user control by clarifying 
Tor
Browser's security features
---+---
 Reporter:  isabela|  Owner:  antonela
 Type:  project| Status:  assigned
 Priority:  High   |  Milestone:
Component:  Applications/Tor Browser   |Version:
 Severity:  Normal | Resolution:
 Keywords:  ux-team, TorBrowserTeam201811  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:  Sponsor17
---+---

Comment (by brade):

 If we need to stick with the padlock, I think it would be clearer if state
 "1" was an unlocked padlock vs. 2 and 3 with the locked padlock.  Do you
 have space to "open" the padlock for state 1?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #25658 [Applications/Tor Browser]: Activity 2.1: Improve user understanding and user control by clarifying Tor Browser's security features

[Tor Bug Tracker & Wiki]

#25658: Activity 2.1: Improve user understanding and user control by clarifying 
Tor
Browser's security features
---+---
 Reporter:  isabela|  Owner:  antonela
 Type:  project| Status:  assigned
 Priority:  High   |  Milestone:
Component:  Applications/Tor Browser   |Version:
 Severity:  Normal | Resolution:
 Keywords:  ux-team, TorBrowserTeam201811  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:  Sponsor17
---+---

Comment (by antonela):

 Replying to [comment:58 gk]:
 > What happened to those suggestions in comment:26?

 As i said in comment:48, the shield icon is being used by firefox for the
 `content blocking` feature.

 https://support.mozilla.org/en-US/kb/control-center-site-privacy-and-
 security-firefox#w_content-blocking

 If this is not relevant for our browser, then we can use a shield icon.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #25658 [Applications/Tor Browser]: Activity 2.1: Improve user understanding and user control by clarifying Tor Browser's security features

[Tor Bug Tracker & Wiki]

#25658: Activity 2.1: Improve user understanding and user control by clarifying 
Tor
Browser's security features
---+---
 Reporter:  isabela|  Owner:  antonela
 Type:  project| Status:  assigned
 Priority:  High   |  Milestone:
Component:  Applications/Tor Browser   |Version:
 Severity:  Normal | Resolution:
 Keywords:  ux-team, TorBrowserTeam201811  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:  Sponsor17
---+---

Comment (by pili):

 Replying to [comment:58 gk]:
 > Replying to [comment:57 antonela]:
 > > Replying to [comment:56 gk]:
 > >
 > > > What about mcs's comment:54 which seems like a good thing to do to
 me.
 > >
 > > Yes, is a good thing. But we have been trying to have a different icon
 for each state since March. The iterations I made were 8 and nothing seems
 to convince us.
 >
 > What happened to those suggestions in comment:26?

 That could be interesting to explore with the onion analogy you have safe
 which shows all the layers of the onion, safer which shows half the layers
 (similar to what we have for the tor browser icon and safest which shows
 no onion layers...

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #25658 [Applications/Tor Browser]: Activity 2.1: Improve user understanding and user control by clarifying Tor Browser's security features

[Tor Bug Tracker & Wiki]

#25658: Activity 2.1: Improve user understanding and user control by clarifying 
Tor
Browser's security features
---+---
 Reporter:  isabela|  Owner:  antonela
 Type:  project| Status:  assigned
 Priority:  High   |  Milestone:
Component:  Applications/Tor Browser   |Version:
 Severity:  Normal | Resolution:
 Keywords:  ux-team, TorBrowserTeam201811  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:  Sponsor17
---+---

Comment (by gk):

 Replying to [comment:57 antonela]:
 > Replying to [comment:56 gk]:
 >
 > > What about mcs's comment:54 which seems like a good thing to do to me.
 >
 > Yes, is a good thing. But we have been trying to have a different icon
 for each state since March. The iterations I made were 8 and nothing seems
 to convince us.

 What happened to those suggestions in comment:26?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #25658 [Applications/Tor Browser]: Activity 2.1: Improve user understanding and user control by clarifying Tor Browser's security features

[Tor Bug Tracker & Wiki]

#25658: Activity 2.1: Improve user understanding and user control by clarifying 
Tor
Browser's security features
---+---
 Reporter:  isabela|  Owner:  antonela
 Type:  project| Status:  assigned
 Priority:  High   |  Milestone:
Component:  Applications/Tor Browser   |Version:
 Severity:  Normal | Resolution:
 Keywords:  ux-team, TorBrowserTeam201811  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:  Sponsor17
---+---
Changes (by antonela):

 * Attachment "25658 - 9.png" added.


--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #25658 [Applications/Tor Browser]: Activity 2.1: Improve user understanding and user control by clarifying Tor Browser's security features

[Tor Bug Tracker & Wiki]

#25658: Activity 2.1: Improve user understanding and user control by clarifying 
Tor
Browser's security features
---+---
 Reporter:  isabela|  Owner:  antonela
 Type:  project| Status:  assigned
 Priority:  High   |  Milestone:
Component:  Applications/Tor Browser   |Version:
 Severity:  Normal | Resolution:
 Keywords:  ux-team, TorBrowserTeam201811  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:  Sponsor17
---+---

Comment (by antonela):

 Replying to [comment:56 gk]:

 > What about mcs's comment:54 which seems like a good thing to do to me.

 Yes, is a good thing. But we have been trying to have a different icon for
 each state since March. The iterations I made were 8 and nothing seems to
 convince us.

 This idea aims to have *one* icon that people can rely upon to refer to
 security settings and as a plus, we have the doorhanger, one click far, to
 have more information. Pretty similar on what Firefox is doing with their
 privacy features.

 If you think that having a number solves this requirement, like what you
 have cited in your proposal, I'm in. Despite the fact that is hard for
 non-technical users to define if the security is incremental and defer it
 by numbers, is ok if you think that this is the way to indicate users
 their security level. 1 is the default? 2 is safer? 3 is safest?

 Let me know and I'll include it.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #25658 [Applications/Tor Browser]: Activity 2.1: Improve user understanding and user control by clarifying Tor Browser's security features

[Tor Bug Tracker & Wiki]

#25658: Activity 2.1: Improve user understanding and user control by clarifying 
Tor
Browser's security features
---+---
 Reporter:  isabela|  Owner:  antonela
 Type:  project| Status:  assigned
 Priority:  High   |  Milestone:
Component:  Applications/Tor Browser   |Version:
 Severity:  Normal | Resolution:
 Keywords:  ux-team, TorBrowserTeam201811  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:  Sponsor17
---+---

Comment (by gk):

 Replying to [comment:55 antonela]:
 > Based on last meeting discussions:
 >
 > **2.1.2 Showing Security Slider State**
 > Doorhanger, icon and about:preferences#privacy
 > https://marvelapp.com/a66fg97/screen/50307815

 What about mcs's comment:54 which seems like a good thing to do to me.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #25658 [Applications/Tor Browser]: Activity 2.1: Improve user understanding and user control by clarifying Tor Browser's security features

[Tor Bug Tracker & Wiki]

#25658: Activity 2.1: Improve user understanding and user control by clarifying 
Tor
Browser's security features
---+---
 Reporter:  isabela|  Owner:  antonela
 Type:  project| Status:  assigned
 Priority:  High   |  Milestone:
Component:  Applications/Tor Browser   |Version:
 Severity:  Normal | Resolution:
 Keywords:  ux-team, TorBrowserTeam201811  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:  Sponsor17
---+---

Comment (by antonela):

 Based on last meeting discussions:

 **2.1.2 Showing Security Slider State**
 Doorhanger, icon and about:preferences#privacy
 https://marvelapp.com/a66fg97/screen/50307815

 **2.1.2.X Change Security Level and Restart to Apply Changes**
 I made two options for this, and i think we may need to consider a third
 one too.

 If a user is downgrading their security level, then we can have one of
 this options:
 - a] a micro button
 - b] a top stripe alert

 If a user is upgrading, I'm not sure if the previous options are strong
 enough to encourage users to restart. If jumping the restart will put
 users in risk, then we can consider having a full-page warning.

 a] downgrade, safest → safer https://marvelapp.com/a66fg97/screen/50342988
 b] downgrade, safest → safer https://marvelapp.com/a66fg97/screen/50342987

 **2.2 Dealing with Per-Site Security Settings - only safer and safest
 mode**
 Users will be able to enable `javascript` and `active content` per site,
 only on safer and safest mode. They can easily switch them at the Control
 Center.
 https://marvelapp.com/a66fg97/screen/50307825

 **3.x Restore Default Security Settings**
 All features in `firefox:preferences` have a short (two lines) description
 about how they work. I included a draft copy there and also the default
 `Restore Defaults` button.
 https://marvelapp.com/a66fg97/screen/50343707

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #25658 [Applications/Tor Browser]: Activity 2.1: Improve user understanding and user control by clarifying Tor Browser's security features

[Tor Bug Tracker & Wiki]

#25658: Activity 2.1: Improve user understanding and user control by clarifying 
Tor
Browser's security features
---+---
 Reporter:  isabela|  Owner:  antonela
 Type:  project| Status:  assigned
 Priority:  High   |  Milestone:
Component:  Applications/Tor Browser   |Version:
 Severity:  Normal | Resolution:
 Keywords:  ux-team, TorBrowserTeam201811  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:  Sponsor17
---+---

Comment (by mcs):

 Replying to [comment:52 pili]:
 > Replying to [comment:51 kevun]:
 > > I love the way this looks. The only thing I see here that might be a
 bit confusing is that Safer and Safest have the same icon on the UI.
 > >
 >
 > Maybe we can have the safest onion be green? Plus points for using the
 styleguide colours :)

 As someone who is red/green color impaired, I don't think it is a good
 idea to rely on color as the '''only''' distinguishing trait. I like the
 idea if having three icons (for Default, Safer, and Safest) that differ in
 some way even if we were to render them without color (but using color is
 good too).

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #25658 [Applications/Tor Browser]: Activity 2.1: Improve user understanding and user control by clarifying Tor Browser's security features

[Tor Bug Tracker & Wiki]

#25658: Activity 2.1: Improve user understanding and user control by clarifying 
Tor
Browser's security features
---+---
 Reporter:  isabela|  Owner:  antonela
 Type:  project| Status:  assigned
 Priority:  High   |  Milestone:
Component:  Applications/Tor Browser   |Version:
 Severity:  Normal | Resolution:
 Keywords:  ux-team, TorBrowserTeam201810  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:  Sponsor17
---+---

Comment (by pili):

 Replying to [comment:51 kevun]:
 > I love the way this looks. The only thing I see here that might be a bit
 confusing is that Safer and Safest have the same icon on the UI.
 >

 Maybe we can have the safest onion be green? Plus points for using the
 styleguide colours :)

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #25658 [Applications/Tor Browser]: Activity 2.1: Improve user understanding and user control by clarifying Tor Browser's security features

[Tor Bug Tracker & Wiki]

#25658: Activity 2.1: Improve user understanding and user control by clarifying 
Tor
Browser's security features
---+---
 Reporter:  isabela|  Owner:  antonela
 Type:  project| Status:  assigned
 Priority:  High   |  Milestone:
Component:  Applications/Tor Browser   |Version:
 Severity:  Normal | Resolution:
 Keywords:  ux-team, TorBrowserTeam201810  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:  Sponsor17
---+---

Comment (by kevun):

 Replying to [comment:48 antonela]:
 > **2.1.1 Removing HTTPS Everywhere and NoScript from the Toolbar - Done**
 >
 > **2.1.2 Showing Security Slider State**
 >
 > Since the shield icon is being used by Firefox for the Content Blocking
 feature, I made a new one for the Tor Security Settings.
 >
 > I think is better if when users click to the icon, they go directly to
 `about:preferences#security` page.
 >
 > Both Safer and Safest levels will have the firefox violet active color
 once active.
 > Both Safer and Safest levels will have permissions per-site.
 >
 > **2.1.2.X Change Security Level and Restart to Apply Changes**
 >
 > As we discussed, once a user changes the security level Tor Browser
 needs to restart to apply changes. The safest way to do it is restarting
 with a new identity.
 >
 > **2.1.3 Reorganizing the Toolbar - Done**
 >
 > **2.2 Dealing with Per-Site Security Settings**
 >
 > Safer level will allow enabling javascript per session.
 > Safest level will allow enabling javascript and active content per
 session.
 >
 > **3.x Restore Default Security Settings**
 >
 > When a user wants to have their current per-site Preference back to
 default (javascript nor active content allowed), it can use the [x] at the
 control center and a message will appear, as current firefox, "You may
 need to reload to apply changes."
 >
 > When a user wants to have the global Security Settings back to default,
 then they can click to "Default" in about:preferences#security and a
 prompt will appear to confirm the Restart with new identity.
 >
 >
 > Here is the concept. If all the details above are ok, I'll update the
 prototype.
 >
 >
 
https://trac.torproject.org/projects/tor/attachment/ticket/25658/25658%20-%208.png

 I love the way this looks. The only thing I see here that might be a bit
 confusing is that Safer and Safest have the same icon on the UI.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #25658 [Applications/Tor Browser]: Activity 2.1: Improve user understanding and user control by clarifying Tor Browser's security features

[Tor Bug Tracker & Wiki]

#25658: Activity 2.1: Improve user understanding and user control by clarifying 
Tor
Browser's security features
---+---
 Reporter:  isabela|  Owner:  antonela
 Type:  project| Status:  assigned
 Priority:  High   |  Milestone:
Component:  Applications/Tor Browser   |Version:
 Severity:  Normal | Resolution:
 Keywords:  ux-team, TorBrowserTeam201810  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:  Sponsor17
---+---

Comment (by antonela):

 Replying to [comment:49 cypherpunks3]:
 > Replying to [comment:9 antonela]:
 > > Replying to [comment:8 cypherpunks]:
 > > > (Also a note on the `about:preferences` changes: I think they're
 unnecessary since the functionality would already be offered by the
 security button, so there's no need for duplicate effort)
 > > >
 > >
 > > Well, we don't want to have the slider on the Top bar UI. The
 doorhanger is just showing the security setting description + a call to
 action in the case the user wants to change it. So if the user wants to
 change the security setting, they should go to `about:preferences` to
 upgrade or downgrade their setup.
 >
 > This makes it much more impractical, you have to go to a new tab with
 `about:preferences` just to change the security slider and it has the
 unintended side effect of making the user think that it's 'okay' to mess
 with stuff on `about:preferences`.


 Yes. The security slider settings apply globally. You can start to think
 this user flow making a question: When do users upgrade or downgrade their
 security? Then you will realize that the *trigger* usually comes from the
 current site/tab there are visiting, or they are willing to attend.

 The best part now is that we are planning to allow per-site permissions.
 So, if you are a user in the highest security mode and some site you are
 visiting have bad performance (gets broken), but you trust in that site,
 and you are okay with javascript running there, then you can allow it
 temporary. With this scenario, you don't need to change your global
 setting, but a temporary feature is enabled in the current tab.

 That is cool. We are avoiding this common user pattern when users
 downgrade their security because they want to visit an specific site and
 then they never go up again.

 There are no reasons for you as a non-technical user to mess stuff in
 about:preferences because you will have there the same three options
 without global granular settings. You can downgrade or upgrade your
 overall security, and your browser will restart to apply changes.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #25658 [Applications/Tor Browser]: Activity 2.1: Improve user understanding and user control by clarifying Tor Browser's security features

[Tor Bug Tracker & Wiki]

#25658: Activity 2.1: Improve user understanding and user control by clarifying 
Tor
Browser's security features
---+---
 Reporter:  isabela|  Owner:  antonela
 Type:  project| Status:  assigned
 Priority:  High   |  Milestone:
Component:  Applications/Tor Browser   |Version:
 Severity:  Normal | Resolution:
 Keywords:  ux-team, TorBrowserTeam201810  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:  Sponsor17
---+---

Comment (by cypherpunks3):

 Replying to [comment:9 antonela]:
 > Replying to [comment:8 cypherpunks]:
 > > (Also a note on the `about:preferences` changes: I think they're
 unnecessary since the functionality would already be offered by the
 security button, so there's no need for duplicate effort)
 > >
 >
 > Well, we don't want to have the slider on the Top bar UI. The doorhanger
 is just showing the security setting description + a call to action in the
 case the user wants to change it. So if the user wants to change the
 security setting, they should go to `about:preferences` to upgrade or
 downgrade their setup.

 This makes it much more impractical, you have to go to a new tab with
 `about:preferences` just to change the security slider and it has the
 unintended side effect of making the user think that it's 'okay' to mess
 with stuff on `about:preferences`.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #25658 [Applications/Tor Browser]: Activity 2.1: Improve user understanding and user control by clarifying Tor Browser's security features

[Tor Bug Tracker & Wiki]

#25658: Activity 2.1: Improve user understanding and user control by clarifying 
Tor
Browser's security features
---+---
 Reporter:  isabela|  Owner:  antonela
 Type:  project| Status:  assigned
 Priority:  High   |  Milestone:
Component:  Applications/Tor Browser   |Version:
 Severity:  Normal | Resolution:
 Keywords:  ux-team, TorBrowserTeam201810  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:  Sponsor17
---+---

Comment (by antonela):

 **2.1.1 Removing HTTPS Everywhere and NoScript from the Toolbar** - Done

 **2.1.2 Showing Security Slider State**

 Since the shield icon is being used by Firefox for the Content Blocking
 feature, I made a new one for the Tor Security Settings.
 I think is better if when users click to the icon, they go directly to
 `about:preferences#security` page.

 Both Safer and Safest levels will have the firefox violet active color
 once active.
 Both Safer and Safest levels will have permissions per-site.

 **2.1.2.X Change Security Level and Reload to Apply Changes**

 As we discussed, once a user changes the security level Tor Browser needs
 to reload to apply changes. The safest way to do it is loading a new
 identity.

 **2.1.3 Reorganizing the Toolbar - Done**

 **2.2 Dealing with Per-Site Security Settings**

 Safer level will allow enabling javascript per session.
 Safest level will allow enabling javascript and active content per
 session.

 **3.x Restore Default Security Settings**

 When a user wants to have the global Security Settings back to default, it
 will click at "Restore to defaults" in about:preferences#security and a
 prompt will appear to confirm the Restart with a new identity.

 When a user wants to have their current per-site Preference back to
 default (nothing allowed), it can use the [x] at the control center, and a
 message will appear, as current firefox, "You may need to reload to apply
 changes."

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #25658 [Applications/Tor Browser]: Activity 2.1: Improve user understanding and user control by clarifying Tor Browser's security features

[Tor Bug Tracker & Wiki]

#25658: Activity 2.1: Improve user understanding and user control by clarifying 
Tor
Browser's security features
---+---
 Reporter:  isabela|  Owner:  antonela
 Type:  project| Status:  assigned
 Priority:  High   |  Milestone:
Component:  Applications/Tor Browser   |Version:
 Severity:  Normal | Resolution:
 Keywords:  ux-team, TorBrowserTeam201810  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:  Sponsor17
---+---
Changes (by antonela):

 * Attachment "25658 - 8.png" added.


--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #25658 [Applications/Tor Browser]: Activity 2.1: Improve user understanding and user control by clarifying Tor Browser's security features

[Tor Bug Tracker & Wiki]

#25658: Activity 2.1: Improve user understanding and user control by clarifying 
Tor
Browser's security features
---+---
 Reporter:  isabela|  Owner:  antonela
 Type:  project| Status:  assigned
 Priority:  High   |  Milestone:
Component:  Applications/Tor Browser   |Version:
 Severity:  Normal | Resolution:
 Keywords:  ux-team, TorBrowserTeam201810  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:  Sponsor17
---+---

Comment (by antonela):

 Replying to gk:

 > Well, New Identity means that tabs won't reload: the browser will close
 and reopen as a blank slate. But, yes, we should provide that option with
 a similar wording.

 I that case "Restart to apply changes" is the safest suggestion we can do.

 > Well, as I said I am not clinging to the slider element, if we think we
 can transport our ideas better with, say, bullets as outlined in your
 prototype that's fine with me. One thing we should think about, though, is
 the amount of space our redesign should occupy. It seems to me the
 (horizontal) slider has some benefits here but I am sure we could come up
 with a similar "small" proposal if bullets are used instead (e.g. by
 collapsing text of security levels not being used currently).

 Cool. I think the radio button options will work better at the preferences
 section. Yes, we can collapse the details in the future.

 > Works for me. We could think about as well showing little icons directly
 in the URL bar but I am not sure how much energy and time we should spend
 on the per-site security settings anyway. My feeling is not so much,
 especially compared to making the overall experience better.[...] Yes,
 that would be one place. But as I said above, maybe URL bar icons would be
 smart as well? Or maybe we should not spend time optimizing for that
 corner case?

 Ok. I made a mockup for it. If we want to have the same userflow the Block
 Content feature have, then we will need an icon for "Javascript" and
 "Active Content." I'm using the permissions icon at the URL bar now to
 show that some permission have been granted. Two icons are not too much.
 Firefox has this scenario when you block the microphone and the camera at
 the same time, for example.

 > We still need to work on informing users that NoScript and
 HTTSEverywhere icons are available to be placed at the Top Nav via
 Menu/Customize. We could include a step/card explaining it at the new
 onboarding.

 Yep. Once the previous items are ready and approved, I'll move to the
 onboarding card.

 > Also, current about:preferences at FF60 doesn't have a [SAVE] button to
 confirm the action. Do you think we need to add an intermediate step for
 users to verify their radio option pick? May we need it for anything else?

 Yes, we need users to confirm the Restart to apply changes.

 > There is actually another item brought up in comment:29 to rename what
 we have to "Feature filter" while we are at it.

 I agree with roger about the behavior of the tool. But, I don't think this
 renaming improves user comprehension on what is happening.

 > One final thought: What do we do in the new design once a user flips a
 preference that is governed by our security controls essentially kicking
 themselves off that security level to something custom? Right now our UI
 gives the hint with the option to restore the default state. It seems to
 me we should keep that in the new UI as well.

 Yes, the next comment includes a 3.X section that contemplates that user
 story. Both, global and per-site settings.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #25658 [Applications/Tor Browser]: Activity 2.1: Improve user understanding and user control by clarifying Tor Browser's security features

[Tor Bug Tracker & Wiki]

#25658: Activity 2.1: Improve user understanding and user control by clarifying 
Tor
Browser's security features
---+---
 Reporter:  isabela|  Owner:  antonela
 Type:  project| Status:  assigned
 Priority:  High   |  Milestone:
Component:  Applications/Tor Browser   |Version:
 Severity:  Normal | Resolution:
 Keywords:  ux-team, TorBrowserTeam201810  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:  Sponsor17
---+---

Comment (by arthuredelstein):

 Replying to [comment:44 gk]:

 > 1) UI design like general design and development is an iterative
 process. It's not finished. So, yes, we might need to redesign the UI
 again but that's part of the process and not necessarily something which
 is a bad thing per se.

 I completely agree. But I think it makes sense to fully analyze the
 problem and proposed solution as much as we can, as early as possible. In
 particular I think the per-site security UI may depend on the semantics we
 choose.

 > 2) I am not convinced the concept of a user trusting a site should play
 a role in defining our security slider settings.

 I can say, personally, my security slider setting choice depends in part
 on my perception of the overall trustworthiness of the kinds of sites I
 tend to visit, but it's possible I may be an exception. What is your model
 for how the user will interpret the security levels and make this
 security/usability tradeoff?

 More broadly, I think we should explicitly answer: what problem are we
 trying to solve with the security levels? Are we trying to defend against
 Threat (A) or (B) or both? How is our design intended to solve that
 problem? If users are not equipped to make security assessments, then why
 are we giving them a choice of different security levels? I feel these
 first-principle questions haven't been concretely addressed to guide our
 design.

 > I think we as experts should take the burden off of users to decide "Is
 foo.com trustworthy right now" providing security settings based on hard
 data and a threat model.

 I agree, that would be ideal. To me it suggests a sort of "Google Safe
 Browsing"-style blocklist rather than a security slider. Now, it may be
 such a blocklist is impractical for us, but we should decide what the
 security slider is offering instead.

 > Thirdly, the recent security release made by Firefox is still vivid in
 my mind. It fixed two RCEs in JIT code. There would be no protections
 against those on the new "medium" level for HTTPS users. I think that's
 the wrong trade-off given our list of adversaries and their capabilities
 (e.g. compromising ad servers to serve malware which happened in the past)
 and the high amount of exploitability in that component and that not
 allowing JIT is to a very large extent not something that comes with
 functionality loss.

 Good point. Maybe we could even disable the JIT always (for every security
 level), if it isn't a usability concern.

 > 3) It's not clear to me that we actually need the compromise you are
 envisioning in comment:37. Maybe we can fix up the vast majority of the
 medium level shortcomings, as said in section 3.3 in the proposal we
 discussed, and that would already be enough to make the medium level
 usable?

 Maybe! But to me an important part of usability for Medium is to allow
 HTML5 videos to work without hassle on HTTPS. Our existing poor usability
 in that area means, I think, that some users will downgrade to Standard
 security. I don't think getting click-to-play video to work smoothly is
 going to be easy, though I might be wrong. In any case at least we should
 try to make this design decision explicit.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #25658 [Applications/Tor Browser]: Activity 2.1: Improve user understanding and user control by clarifying Tor Browser's security features

[Tor Bug Tracker & Wiki]

#25658: Activity 2.1: Improve user understanding and user control by clarifying 
Tor
Browser's security features
---+---
 Reporter:  isabela|  Owner:  antonela
 Type:  project| Status:  assigned
 Priority:  High   |  Milestone:
Component:  Applications/Tor Browser   |Version:
 Severity:  Normal | Resolution:
 Keywords:  ux-team, TorBrowserTeam201810  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:  Sponsor17
---+---

Comment (by gk):

 Replying to [comment:35 antonela]:
 > Hi geko, thanks for the heads-up; already read the diff. Seems like you
 have a strong opinion for keeping the slider.
 >
 > Let's do it again:
 >
 > **2.1.1 Removing HTTPS Everywhere and NoScript from the Toolbar**
 >
 > OK
 >
 > **2.1.2 Showing Security Slider State**
 >
 > We tried this before and this is the latest prototype I have: ​
 >
 > https://marvelapp.com/383eaa9/screen/44007368
 >
 > Should we iterate over it again? Are we happy with the icon? Do we want
 a different icon?

 Works for me.

 > > To mitigate that problem we could at least warn users about the
 possible danger and provide the option to acquire a New Identity right
 after changing the security slider level.
 >
 > Suggest a New Identity after the global setting change, seems smart. We
 can do that right after the user change about:preferences#security. A
 message that says "You may need a New Identity to apply changes safely.
 Your tabs will reload, and some information could be missed" will help.

 Well, New Identity means that tabs won't reload: the browser will close
 and reopen as a blank slate. But, yes, we should provide that option with
 a similar wording.

 > > We'll add a security settings button to the toolbar which shows the
 current slider state but, once clicked on, opens an about:preferences
 panel in a new tab which contains the security slider.
 >
 > Something like this?

 Well, as I said I am not clinging to the slider element, if we think we
 can transport our ideas better with, say, bullets as outlined in your
 prototype that's fine with me. One thing we should think about, though, is
 the amount of space our redesign should occupy. It seems to me the
 (horizontal) slider has some benefits here but I am sure we could come up
 with a similar "small" proposal if bullets are used instead (e.g. by
 collapsing text of security levels not being used currently).

 > **2.1.3 Reorganizing the Toolbar**
 >
 > OK
 >
 > ** 2.2 Dealing with Per-Site Security Settings**
 >
 > > One way to do that would be to use the Permissions section which opens
 after clicking on the "i" icon in the URL bar.
 >
 > Ok. It should look similar to
 >

 Works for me. We could think about as well showing little icons directly
 in the URL bar but I am not sure how much energy and time we should spend
 on the per-site security settings anyway. My feeling is not so much,
 especially compared to making the overall experience better.

 >
 > > We should refrain from exposing icons for every single "active
 content" in the URL bar, though. Rather, besides the button for
 temporarily allowing JavaScript we would only add one additional, which is
 responsible for manipulating and showing the state of "active content"
 (like WebGL, SVG, fonts etc.).
 >
 > Where do you think it should have place? At the Control Center
 doorhanger?

 Yes, that would be one place. But as I said above, maybe URL bar icons
 would be smart as well? Or maybe we should not spend time optimizing for
 that corner case?

 Open things we still need to solve/discuss from comment:26:
 {{{
  We still need to work on informing users that NoScript and HTTSEverywhere
 icons are available to be placed at the Top Nav via Menu/Customize. We
 could include a step/card explaining it at the new onboarding.

 Also, current about:preferences at FF60 doesn't have a [SAVE] button to
 confirm the action. Do you think we need to add an intermediate step for
 users to verify their radio option pick? May we need it for anything else?
 }}}

 One final thought: What do we do in the new design once a user flips a
 preference that is governed by our security controls essentially kicking
 themselves off that security level to something custom? Right now our UI
 gives the hint with the option to restore the default state. It seems to
 me we should keep that in the new UI as well.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org

Re: [tor-bugs] #25658 [Applications/Tor Browser]: Activity 2.1: Improve user understanding and user control by clarifying Tor Browser's security features

[Tor Bug Tracker & Wiki]

#25658: Activity 2.1: Improve user understanding and user control by clarifying 
Tor
Browser's security features
---+---
 Reporter:  isabela|  Owner:  antonela
 Type:  project| Status:  assigned
 Priority:  High   |  Milestone:
Component:  Applications/Tor Browser   |Version:
 Severity:  Normal | Resolution:
 Keywords:  ux-team, TorBrowserTeam201810  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:  Sponsor17
---+---

Comment (by gk):

 Replying to [comment:43 arthuredelstein]:
 > Replying to [comment:41 gk]:
 > It seemed to me this was a good time to discuss the issue because the
 user interface design is closely connected to the behavior of the global
 and per-site safety levels. If we redesign the behavior of the security
 levels after a UI redesign, then it will mean we have to redesign the UI
 yet once more.

 Well, maybe. I guess it depends on what new behavior we come up with. E.g.
 if the medium settings just change their semantics and all things stay
 equal then it's not that much of a change (maybe some labels would need to
 get adjusted) as the medium level is just a small part of the slider. But,
 yes, maybe there is more to change. Regardless, a bunch of things come to
 mind here:

 1) UI design like general design and development is an iterative process.
 It's not finished. So, yes, we might need to redesign the UI again but
 that's part of the process and not necessarily something which is a bad
 thing per se.

 2) I am not convinced the concept of a user trusting a site should play a
 role in defining our security slider settings. First of all, how is a user
 making an informed decision here and what does it mean at all "that a user
 expects a website will not sending malicious code" to a normal user?
 Secondly, we hardly want to redesign our slider every time our user live
 through a big change in trustworthiness, say, because of recent events in
 news. Rather, I think we as experts should take the burden off of users to
 decide "Is foo.com trustworthy right now" providing security settings
 based on hard data and a threat model. Thirdly, the recent security
 release made by Firefox is still vivid in my mind. It fixed two RCEs in
 JIT code. There would be no protections against those on the new "medium"
 level for HTTPS users. I think that's the wrong trade-off given our list
 of adversaries and their capabilities (e.g. compromising ad servers to
 serve malware which happened in the past) and the high amount of
 exploitability in that component and that not allowing JIT is to a very
 large extent not something that comes with functionality loss. (There is
 more to say to your proposal, of course. A good place for that would be on
 our mailing list, once we discuss a concrete proposal for redesigning the
 semantics of our slider settings, which brings me to my third point)

 3) It's not clear to me that we actually need the compromise you are
 envisioning in comment:37. Maybe we can fix up the vast majority of the
 medium level shortcomings, as said in section 3.3 in the proposal we
 discussed, and that would already be enough to make the medium level
 usable? Maybe we could even set it as the default mode then given the Tor
 Browser context? Or even just ship two possible settings which would
 correspond to "safer" and "safest" as we have them today? So, it seems
 smart to me to revisit the semantics of the slider once we solved the low-
 hanging fruits.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #25658 [Applications/Tor Browser]: Activity 2.1: Improve user understanding and user control by clarifying Tor Browser's security features

[Tor Bug Tracker & Wiki]

#25658: Activity 2.1: Improve user understanding and user control by clarifying 
Tor
Browser's security features
---+---
 Reporter:  isabela|  Owner:  antonela
 Type:  project| Status:  assigned
 Priority:  High   |  Milestone:
Component:  Applications/Tor Browser   |Version:
 Severity:  Normal | Resolution:
 Keywords:  ux-team, TorBrowserTeam201810  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:  Sponsor17
---+---

Comment (by arthuredelstein):

 Replying to [comment:41 gk]:

 > I don't understand that. That dialog is only talking about *where* our
 so-called protections are applied (on all sites/only on unsecure
 sites/never), not *which* kind of protections. And we have two sets of
 protections ("safest" and "safer" however we want to structure the
 latter). Thus, this does not map to an on/off option: It does not say
 which protections apply to all sites ("safer" or "safest") and it does not
 say which protections apply to only unsecure ones. The dialog is only
 talking about "Security Protection" indicating the same group of
 restrictions applies to all three options given (in the first case to all
 sites, in the second one to unsecure ones and in the third case to none)

 What I'm saying is, if we change the "Safer" (Medium) level to Design (2),
 then we have the same 3 levels that are in Antonela's dialog:

  * "All"
  * "Only in 'insecure' sites"
  * "None"

 The "All" and "None" levels are identical to "Standard" and "Safest" in
 our existing 3-level security slider. So that dialog would *replace* the
 security slider, not supplement it.

 Replying to [comment:42 gk]:
 > As a more generic comment: it seems those new proposals that showed up
 in the previous comments are concerned with a different bug (maybe
 #21034?). This bug is about implementing the proposal the description of
 this ticket linked to. In particular, it is concerned with the
 *clarification* and simplification of what we currently *have* not with a
 next step of how we could redesign particular slider levels or security
 protections we provide. While this is important it seems it requires more
 thinking and some data helping us decide what to do.

 It seemed to me this was a good time to discuss the issue because the user
 interface design is closely connected to the behavior of the global and
 per-site safety levels. If we redesign the behavior of the security levels
 after a UI redesign, then it will mean we have to redesign the UI yet once
 more.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #25658 [Applications/Tor Browser]: Activity 2.1: Improve user understanding and user control by clarifying Tor Browser's security features

[Tor Bug Tracker & Wiki]

#25658: Activity 2.1: Improve user understanding and user control by clarifying 
Tor
Browser's security features
---+---
 Reporter:  isabela|  Owner:  antonela
 Type:  project| Status:  assigned
 Priority:  High   |  Milestone:
Component:  Applications/Tor Browser   |Version:
 Severity:  Normal | Resolution:
 Keywords:  ux-team, TorBrowserTeam201810  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:  Sponsor17
---+---

Comment (by gk):

 As a more generic comment: it seems those new proposals that showed up in
 the previous comments are concerned with a different bug (maybe #21034?).
 This bug is about implementing the proposal the description of this ticket
 linked to. In particular, it is concerned with the *clarification* and
 simplification of what we currently *have* not with a next step of how we
 could redesign particular slider levels or security protections we
 provide. While this is important it seems it requires more thinking and
 some data helping us decide what to do.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #25658 [Applications/Tor Browser]: Activity 2.1: Improve user understanding and user control by clarifying Tor Browser's security features

[Tor Bug Tracker & Wiki]

#25658: Activity 2.1: Improve user understanding and user control by clarifying 
Tor
Browser's security features
---+---
 Reporter:  isabela|  Owner:  antonela
 Type:  project| Status:  assigned
 Priority:  High   |  Milestone:
Component:  Applications/Tor Browser   |Version:
 Severity:  Normal | Resolution:
 Keywords:  ux-team, TorBrowserTeam201810  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:  Sponsor17
---+---

Comment (by gk):

 Replying to [comment:39 arthuredelstein]:
 > Replying to [comment:38 gk]:
 >
 > > Just to reply to this item: That's not proposed in comment:33. Here is
 what antonela wrote:
 > > {{{
 > >  Again: I think that the best way to improve the security slider is
 removing the slider component. As mentioned before, the slider is a UI
 artifact that doesn't add any value to this settings. Instead, it confuses
 users about their benefits on upgrade or downgrade.
 > >
 > > If we could simplify the security settings into a boolean option, we
 will follow the current Firefox approach on settings both in desktop and
 in mobile, and we will help users by making it easier to understand the
 trade-off: "Do I trust in this site?"
 > > }}}
 > > So, comment:33 proposes to reduce the slider from three options to two
 *in general* and bind all the security features to the transport. But you
 want to keep "safest", "safer", and "standard" but redo the "safer"
 option. So, these are different things.
 >
 > My interpretation of antonela's proposal in comment:33 is that there are
 three global levels. See
 
[https://trac.torproject.org/projects/tor/attachment/ticket/25658/25658%20-%206.4.png
 the image] under "General Settings - about:preferences#security". The
 three radio buttons correspond to "safest", "safer" and "standard". Then
 each site would have two possible states: protected or unprotected.

 I don't understand that. That dialog is only talking about *where* our so-
 called protections are applied (on all sites/only on unsecure
 sites/never), not *which* kind of protections. And we have two sets of
 protections ("safest" and "safer" however we want to structure the
 latter). Thus, this does not map to an on/off option: It does not say
 which protections apply to all sites ("safer" or "safest") and it does not
 say which protections apply to only unsecure ones. The dialog is only
 talking about "Security Protection" indicating the same group of
 restrictions applies to all three options given (in the first case to all
 sites, in the second one to unsecure ones and in the third case to none)

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #25658 [Applications/Tor Browser]: Activity 2.1: Improve user understanding and user control by clarifying Tor Browser's security features

[Tor Bug Tracker & Wiki]

#25658: Activity 2.1: Improve user understanding and user control by clarifying 
Tor
Browser's security features
---+---
 Reporter:  isabela|  Owner:  antonela
 Type:  project| Status:  assigned
 Priority:  High   |  Milestone:
Component:  Applications/Tor Browser   |Version:
 Severity:  Normal | Resolution:
 Keywords:  ux-team, TorBrowserTeam201810  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:  Sponsor17
---+---

Comment (by antonela):

 > So, comment:33 proposes to reduce the slider from three options to two
 *in general* and bind all the security features to the transport.

 Not really. I think that having an ON/OFF option is more natural for users
 to understand that having three options and we also can improve websites
 performance by suggesting allow or not specific permissions. I also
 believe that Tor Browser could be proactive on raising the security shield
 if the user is visiting an untrustworthy site, which could or not be an
 HTTP site but could be a site which has dangerous content. With this
 scenario, Arthur's heuristics showed that seems like Design (2) will have
 a better experience for users.

 This feature should aim to protect users from trustworthy and
 untrustworthy sites while having better performance with sites breakage.
 If we don't improve site breakage on top security mode, then nobody uses
 it.

 That said, my idea about having our security protection feature at the
 control center allows users to have a better understanding of how the
 security tool behavior is. It is related to one of the problems we want to
 solve with this ticket: users need visual feedback on which level of the
 slider they are.

 In my proposal, we still have three options at
 `about:preferences#security` as detailed
 
[https://trac.torproject.org/projects/tor/attachment/ticket/25658/25658%20-%206.4.png/
 here]. But the label/name of the options now is not more related to which
 kind of security users think they need.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #25658 [Applications/Tor Browser]: Activity 2.1: Improve user understanding and user control by clarifying Tor Browser's security features

[Tor Bug Tracker & Wiki]

#25658: Activity 2.1: Improve user understanding and user control by clarifying 
Tor
Browser's security features
---+---
 Reporter:  isabela|  Owner:  antonela
 Type:  project| Status:  assigned
 Priority:  High   |  Milestone:
Component:  Applications/Tor Browser   |Version:
 Severity:  Normal | Resolution:
 Keywords:  ux-team, TorBrowserTeam201810  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:  Sponsor17
---+---

Comment (by arthuredelstein):

 Replying to [comment:38 gk]:

 > Just to reply to this item: That's not proposed in comment:33. Here is
 what antonela wrote:
 > {{{
 >  Again: I think that the best way to improve the security slider is
 removing the slider component. As mentioned before, the slider is a UI
 artifact that doesn't add any value to this settings. Instead, it confuses
 users about their benefits on upgrade or downgrade.
 >
 > If we could simplify the security settings into a boolean option, we
 will follow the current Firefox approach on settings both in desktop and
 in mobile, and we will help users by making it easier to understand the
 trade-off: "Do I trust in this site?"
 > }}}
 > So, comment:33 proposes to reduce the slider from three options to two
 *in general* and bind all the security features to the transport. But you
 want to keep "safest", "safer", and "standard" but redo the "safer"
 option. So, these are different things.

 My interpretation of antonela's proposal in comment:33 is that there are
 three global levels. See
 
[https://trac.torproject.org/projects/tor/attachment/ticket/25658/25658%20-%206.4.png
 the image] under "General Settings - about:preferences#security". The
 three radio buttons correspond to "safest", "safer" and "standard". Then
 each site would have two possible states: protected or unprotected.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #25658 [Applications/Tor Browser]: Activity 2.1: Improve user understanding and user control by clarifying Tor Browser's security features

[Tor Bug Tracker & Wiki]

#25658: Activity 2.1: Improve user understanding and user control by clarifying 
Tor
Browser's security features
---+---
 Reporter:  isabela|  Owner:  antonela
 Type:  project| Status:  assigned
 Priority:  High   |  Milestone:
Component:  Applications/Tor Browser   |Version:
 Severity:  Normal | Resolution:
 Keywords:  ux-team, TorBrowserTeam201810  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:  Sponsor17
---+---

Comment (by gk):

 Replying to [comment:37 arthuredelstein]:
 > Replying to [comment:34 gk]:
 > > The security risks don't map the the underlying transport ot its
 security being used. The security risks we try to tackle are to a large
 part due to the *content* that gets transferred. Someone injecting this
 content on the path from server to user is an important risk but just one
 of those we need to defend against. This binding the security state to
 HTTP/HTTPS is not sufficient. Moreover, the strongest security we want to
 provide is something like the current "safest" option we have. We won't be
 able to enable this by default probably forever as the breakage is too
 high, irrespective of the transport being used.
 >
 > We have discussed this issue previously, but I wanted to try laying it
 out in more detail and see if that helps to clarify the different
 approaches. :)

 > Design (2), proposed in comment:33:
 > || || Unblocked || Blocked ||
 > || HTTP || || WebFont, blob, SVG, scripts, WebGL, Video, Audio,
 WebAudio, MathML, JIT ||
 > || HTTPS || WebFont, blob, SVG, scripts, WebGL, Video, Audio, WebAudio,
 MathML, JIT || ||

 Just reply to this item: That's not proposed in comment:33. Here is what
 antonela wrote:
 {{{
  Again: I think that the best way to improve the security slider is
 removing the slider component. As mentioned before, the slider is a UI
 artifact that doesn't add any value to this settings. Instead, it confuses
 users about their benefits on upgrade or downgrade.

 If we could simplify the security settings into a boolean option, we will
 follow the current Firefox approach on settings both in desktop and in
 mobile, and we will help users by making it easier to understand the
 trade-off: "Do I trust in this site?"
 }}}
 So, comment:33 proposes to reduce the slider from three options to two *in
 general* and bind all the security features to the transport. But you want
 to keep "safest", "safer", and "standard" but redo the "safer" option. So,
 these are different things.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #25658 [Applications/Tor Browser]: Activity 2.1: Improve user understanding and user control by clarifying Tor Browser's security features

[Tor Bug Tracker & Wiki]

#25658: Activity 2.1: Improve user understanding and user control by clarifying 
Tor
Browser's security features
---+---
 Reporter:  isabela|  Owner:  antonela
 Type:  project| Status:  assigned
 Priority:  High   |  Milestone:
Component:  Applications/Tor Browser   |Version:
 Severity:  Normal | Resolution:
 Keywords:  ux-team, TorBrowserTeam201810  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:  Sponsor17
---+---

Comment (by arthuredelstein):

 Replying to [comment:34 gk]:
 > The security risks don't map the the underlying transport ot its
 security being used. The security risks we try to tackle are to a large
 part due to the *content* that gets transferred. Someone injecting this
 content on the path from server to user is an important risk but just one
 of those we need to defend against. This binding the security state to
 HTTP/HTTPS is not sufficient. Moreover, the strongest security we want to
 provide is something like the current "safest" option we have. We won't be
 able to enable this by default probably forever as the breakage is too
 high, irrespective of the transport being used.

 We have discussed this issue previously, but I wanted to try laying it out
 in more detail and see if that helps to clarify the different approaches.
 :)

 We already have a "Safest" setting that maximizes security guarantees. I
 agree we shouldn't lower those guarantees. We also have a "Safe" (Low)
 setting which maximizes usability and already has the lowest possible
 security guarantees. That probably shouldn't change for now.

 So the question is: what should the "Safer" (Medium) level be? Given that
 the three levels are implementing a tradeoff between security and website
 usability, I think we should be willing to consider any Pareto-optimal
 choice, even if it reduces security somewhat. What is important is that
 the "Safer" level is sufficiently distinct from both "Safest" and "Safe"
 so that it is worthwhile to make it available.

 Let's compare two possible "Safer" (Medium) Security designs:

 Design (1), the status quo (Tor Browser 8.0.x):

 || || Unblocked || Blocked ||
 || HTTP || WebFont, blob, SVG || scripts, WebGL, Video, Audio, WebAudio,
 MathML, JIT ||
 || HTTPS || WebFont, blob, SVG, scripts, WebGL || Video, Audio, WebAudio,
 MathML, JIT ||

 Design (2), proposed in comment:33:
 || || Unblocked || Blocked ||
 || HTTP || || WebFont, blob, SVG, scripts, WebGL, Video, Audio, WebAudio,
 MathML, JIT ||
 || HTTPS || WebFont, blob, SVG, scripts, WebGL, Video, Audio, WebAudio,
 MathML, JIT || ||

 So, which of these two options is more secure? (1) has better security for
 HTTPS and (2) has better security for HTTP. Overall security depends on
 one's threat model.

 Consider the two main potential threats:
 (A) '''Hostile content injected at exit nodes, or between server and exit
 node.''' To combat this threat, it seems that Design (2) is somewhat
 better because it blocks the most content in HTTP.
 (B) '''Hostile content from the website itself, or subresources.''' Which
 design is safer depends on whether the hostile site is HTTP or HTTPS. If
 an HTTP site is hostile, Design (2) is preferred. If an HTTPS site is
 hostile, Design (1) is preferred.

 The next question: which of the two threats are dominant in a real user's
 threat model? I think there are different categories of users:

 (I) '''Users who are unconcerned about threats or unable to handle broken
 websites.''' For these users, "Safe" (Low) security is the (default)
 choice.
 (II) '''Users who only visit "trustworthy" sites.''' (I define
 "trustworthy" as websites the user expects will not send malicious code.)
 For these users, Threat (A) is the dominant threat and in this case,
 "Safer" security seems appropriate, and Design (2) is better.
 (III) '''Users who visit "untrustworthy" sites.''' For these users, Threat
 (B) can be the dominant threat. (But Threat (A) still exists for these
 users to the same extent as for Category (II) users. The total risk of
 being exploited is higher.) Assuming they are using the "Safer" level,
 these users may prefer Design (1), at least for HTTPS.

 Perhaps, up to this point, my description is fairly uncontroversial. ;) I
 hope this kind of analysis is useful regardless of our final decision for
 the "Safer" level.

 

 But now I want to think further about Category (III) users. These users
 are visiting untrustworthy websites; they are high-risk users. Why would
 the user want to leave SVG, WebFonts, or scripts unblocked if they think a
 site is untrustworthy? While it's true that some websites will work
 better, it seems dangerous to assume we 

Re: [tor-bugs] #25658 [Applications/Tor Browser]: Activity 2.1: Improve user understanding and user control by clarifying Tor Browser's security features

[Tor Bug Tracker & Wiki]

#25658: Activity 2.1: Improve user understanding and user control by clarifying 
Tor
Browser's security features
---+---
 Reporter:  isabela|  Owner:  antonela
 Type:  project| Status:  assigned
 Priority:  High   |  Milestone:
Component:  Applications/Tor Browser   |Version:
 Severity:  Normal | Resolution:
 Keywords:  ux-team, TorBrowserTeam201810  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:  Sponsor17
---+---

Comment (by gk):

 Replying to [comment:35 antonela]:
 > Hi geko, thanks for the heads-up; already read the diff. Seems like you
 have a strong opinion for keeping the slider.

 Not at all. I do want, though, not lower the security guarantees AND the
 usability we currently offer. So, the redesign we currently have in mind
 should provide the same guarantees + better usability. If we get to that
 then that's a good result for this iteration with hopefully other
 iterations to come.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #25658 [Applications/Tor Browser]: Activity 2.1: Improve user understanding and user control by clarifying Tor Browser's security features

[Tor Bug Tracker & Wiki]

#25658: Activity 2.1: Improve user understanding and user control by clarifying 
Tor
Browser's security features
---+---
 Reporter:  isabela|  Owner:  antonela
 Type:  project| Status:  assigned
 Priority:  High   |  Milestone:
Component:  Applications/Tor Browser   |Version:
 Severity:  Normal | Resolution:
 Keywords:  ux-team, TorBrowserTeam201810  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:  Sponsor17
---+---

Comment (by antonela):

 Hi geko, thanks for the heads-up; already read the diff. Seems like you
 have a strong opinion for keeping the slider.

 Let's do it again:

 **2.1.1 Removing HTTPS Everywhere and NoScript from the Toolbar**

 OK

 **2.1.2 Showing Security Slider State**

 We tried this before and this is the latest prototype I have: ​

 https://marvelapp.com/383eaa9/screen/44007368

 Should we iterate over it again? Are we happy with the icon? Do we want a
 different icon?

 >
 >To mitigate that problem we could at least warn users about the possible
 danger and provide the option to acquire a New Identity right after
 changing the security slider level.

 Suggest a New Identity after the global setting change, seems smart. We
 can do that right after the user change about:preferences#security. A
 message that says "You may need a New Identity to apply changes safely.
 Your tabs will reload, and some information could be missed" will help.

 >
 >We'll add a security settings button to the toolbar which shows the
 current slider state but, once clicked on, opens an about:preferences
 panel in a new tab which contains the security slider.

 Something like this?
 [[Image(https://trac.torproject.org/projects/tor/raw-
 attachment/ticket/25658/25658-preferences.png, 700px)]]

 **2.1.3 Reorganizing the Toolbar**

 OK

 ** 2.2 Dealing with Per-Site Security Settings**

 > One way to do that would be to use the Permissions section which opens
 after clicking on the "i" icon in the URL bar.

 Ok. It should look similar to

 [[Image(https://trac.torproject.org/projects/tor/raw-
 attachment/ticket/25658/25658%20-%207.png, 700px)]]

 >
 > We should refrain from exposing icons for every single "active content"
 in the URL bar, though. Rather, besides the button for temporarily
 allowing JavaScript we would only add one additional, which is responsible
 for manipulating and showing the state of "active content" (like WebGL,
 SVG, fonts etc.).

 Where do you think it should have place? At the Control Center doorhanger?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #25658 [Applications/Tor Browser]: Activity 2.1: Improve user understanding and user control by clarifying Tor Browser's security features

[Tor Bug Tracker & Wiki]

#25658: Activity 2.1: Improve user understanding and user control by clarifying 
Tor
Browser's security features
---+---
 Reporter:  isabela|  Owner:  antonela
 Type:  project| Status:  assigned
 Priority:  High   |  Milestone:
Component:  Applications/Tor Browser   |Version:
 Severity:  Normal | Resolution:
 Keywords:  ux-team, TorBrowserTeam201810  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:  Sponsor17
---+---
Changes (by antonela):

 * Attachment "25658 - 7.png" added.


--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #25658 [Applications/Tor Browser]: Activity 2.1: Improve user understanding and user control by clarifying Tor Browser's security features

[Tor Bug Tracker & Wiki]

#25658: Activity 2.1: Improve user understanding and user control by clarifying 
Tor
Browser's security features
---+---
 Reporter:  isabela|  Owner:  antonela
 Type:  project| Status:  assigned
 Priority:  High   |  Milestone:
Component:  Applications/Tor Browser   |Version:
 Severity:  Normal | Resolution:
 Keywords:  ux-team, TorBrowserTeam201810  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:  Sponsor17
---+---
Changes (by antonela):

 * Attachment "25658-preferences.png" added.


--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs