#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@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs