#21034: Per site security settings? --------------------------------------+-------------------------- Reporter: arthuredelstein | Owner: tbb-team Type: defect | Status: new Priority: Medium | Milestone: Component: Applications/Tor Browser | Version: Severity: Normal | Resolution: Keywords: | Actual Points: Parent ID: #20843 | Points: Reviewer: | Sponsor: --------------------------------------+--------------------------
Comment (by arthuredelstein): Replying to [comment:15 gk]: > Replying to [comment:14 arthuredelstein]: > > When I opened this ticket, I was envisioning the former (sorry this wasn't clearly stated). So maybe, strictly speaking, the proposed feature should be called "per-first-party security settings" instead of "per-site security settings". > > But the user in my example clearly indicated they want to have foo.com in "high" mode. Like clearly, clearly, because they are scared about that particular domain. That wish is not dependent on any other site embedding foo.com nor on any other site doing so on any security level. What I am trying to say is: making security decisions based on the URL bar domain does not work. The malware from foo.com you are afraid of does not care if there is first-party isolation on or off. It just needs *one way* to get to you. I believe users are aware of that and expecting that a security slider that defends them against that takes this into account. TLDR: I think there are serious problems with the current security slider behavior, but I tend to agree that the proposed behavior (per-first-party settings) is perhaps too difficult to make clear to the user. --- I now realize that, implicit in my model is that the user should start in default "high" mode and then use "medium" or "low" security on specific sites when more usability is needed. With my proposed of a simple drop- down attached to the URL bar, it's impossible for the user to raise the security of a site before they have already visited! Very similar to NoScript's popup menu. So let's take your example, but starting in default "high" security (call it Example A): In general, users don't know, unless they inspect network requests or source code, that bar.com sources an evil iframe from foo.com. All they can see is "bar.com" in the URL bar. In the current Tor Browser, with a global security setting, here's what the user does: * Set security to High and visit https://foo.com/ --> protected * Visit https://bar.com/ and then set security to Medium --> exploited If we add a patch that allows per-first-party security setting, the user does this: * Set default security to high * Visit https://foo.com --> protected * Visit https://bar.com, and then set bar.com's security to Medium --> exploited So in Example A, the status quo is just as bad as a per-first-party security setting patch. Regardless, bar.com has an undeserved "safe" reputation and the user was unfortunately exploited. Let me now propose Example B. Suppose another site, baz.com, has a well deserved safe reputation. The user wants to visit baz.com and the same dangerous foo.com. In the current Tor Browser: * Set global security to High and visit https://foo.com/ --> protected * Visit https://baz.com/ in the same tab, and then lower global security to Medium --> safe * Click the Back button to return to https://foo.com --> oops! exploited In a browser with proposed patch: * Set default security to high * Visit https://foo.com --> protected * Now visit https://baz.com in the same tab, and then lower baz.com's security to Medium --> safe * Click the Back button to return to https://foo.com --> still protected So in Example B, in current Tor Browser it's too easy for the user to forget they need to set the default setting to "High" before clicking the back button. And I think the potential for user opsec mistakes could get even worse if we implement #21153. But despite this argument I am inclined to agree that the semantic problems associated with the proposed change are pretty serious. Will the user really understand the distinction between per-domain and per-first- party-domain security settings? Perhaps not. So I'm not sure how to solve this problem. -- Ticket URL: <https://trac.torproject.org/projects/tor/ticket/21034#comment:17> 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