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" <blackhole@xxxxxxxxxxxxxx>]

#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: <https://trac.torproject.org/projects/tor/ticket/25658#comment:46>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online

_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs