Proposal for redesigning the security controls
Hi! I managed to come up with a proposal for redesigning the security controls (see below). As always feedback and discussion is very welcome. Filename: XXX-redesign-security-controls.txt Title: Redesign of Tor Browser's Security Controls Author: Georg Koppen Created: 1-February-2018 Status: Open 1 Introduction Tor Browser is well-known for its defenses against web tracking and fingerprinting. However, providing Tor users just a privacy-enhanced browser is often not enough to safeguard against deanonymization attacks as those protections might simply get bypassed by exploiting browser vulnerabilities. Tor Bowser therefore offers several security enhancements as well to reduce that risk. Most of those features are provided by extensions which Tor Browser includes, namely Torbutton, NoScript, and HTTPS Everywhere. 1.1 Motivation By default Torbutton, NoScript, and HTTPS Everywhere are visible on the toolbar in Tor Browser and there is no hint about possible security enhancements, with the exception of a notification bar shown on first start and pointing to our security slider. This has a number of suboptimal outcomes which this proposal seeks to address: a) Security controls are scattered over and within different extensions. That makes it hard to understand which knobs a user could turn to improve their security settings while not being exposed to additional fingerprinting risks. b) The toolbar gets cluttered with three additional icons that provide access to both per-site and global security settings. This is confusing to users. Part of the confusion stems from mixing non-global with global security controls on the toolbar not indicating which of them just affect a particular website while others affect the whole browser session. Another part is that users feel the need to navigate through different levels of extension menus to make basic adjustments to their security level. c) There is the security vs. usability trade-off and little incentives to change the default which comes with Tor Browser. That results in users just staying on the lowest security level while at least some of them could get convinced to raise that level if we managed to provide an improved experience around our security controls, both functionality- and UX-wise. 1.2 The State of the Security Controls That is how the toolbar in Tor Browser looks like currently: ---------------------------------------------------------------------- | --- --- ------------------------- --------------- --- --- | | |N| |T| | URL bar | | Search bar | |H| |M| | | --- --- ------------------------- --------------- --- --- | ---------------------------------------------------------------------- N = NoScript button T = Torbutton button H = HTTPS Everywhere button M = (Hamburger) Menu button We include HTTPS Everywhere to help against potential Tor Exit node eavesdroppers and active attackers. To provide users with optional defense-in-depth against JavaScript and other potential exploit vectors, we use NoScript modifying some of its defaults[1]. Torbutton includes the security slider which is meant to give users an easy way to adjust their security level from Standard to Safest, depending on their perceived needs. 2 Proposal Generally, items on the toolbar serve two important purposes: they are shortcuts to features often used and they inform about current state. With that in mind we can think about redoing our toolbar helping that way with issues outlined in 1.1 a) and b). The remaining problems (part of 1.1 b) and 1.1 c)) will be addressed in section 2.2 and 3.3. 2.1 Restructuring the Toolbar 2.1.1 Removing HTTPS Everywhere and NoScript from the Toolbar I'd propose we remove both NoScript and HTTPS Everywhere from the toolbar and leave Torbutton on it for now: Torbutton serves a number of purposes and access to security settings is just one of them. Moreover, we are in the process of restructuring at least part of its functionality right now[2] and more will likely happen in the future in this area. We can think about whether Torbutton should remain on the toolbar after that transition is done. HTTPS Everywhere has the option to block all unencrypted requests and apart from that is just enforcing HTTPS connections according to the rulesets it ships, which is our default. There is not much gain security-wise leaving it on the toolbar and users might just be confused by the "Block all unencrypted requests" option. I'd argue as well that the status indicator is not important enough to justify precious space on the toolbar either. NoScript comes with a myriad of configuration options. We try to abstract that away by shipping a list of defaults for Tor Browser[1]. But still having NoScript easily accessible makes it dangerous to choose the wrong option, especially as the majority of its functionality does not need to be exposed for Tor Browser users. Moreover, the scary warning icon which is visible when NoScript allows JavaScript is highly confusing to users as we ship this configuration as our default. Removing the icon from the toolbar should solve those two problems. We might want to think about exposing the small amount of functionality which especially users with the security slider set to "Safest" might need: managing finer-grained script control. See section 2.2 for that. 2.1.2 Adding a Security Settings Button to the Toolbar I'd like to propose a new button on the toolbar giving easy access to what is essentially the tool that we want to promote: the security slider. We could use an icon similar to the one suggested by ninavizz[3] or come up with a different solution. The button would open the security slider menu with a right-click. With a left-click, keyboard shortcuts, and mouse-wheel scrolling one can adjust the security level directly. The new toolbar would look like: ---------------------------------------------------------------------- | --- --- ------------------------------- --------------- --- | | |T| |S| | URL bar | | Search bar | |M| | | --- --- ------------------------------- --------------- --- | ---------------------------------------------------------------------- T = Torbutton button S = Security Settings button M = (Hamburger) Menu button Note: The reorganized toolbar has the additional benefit that no per-site state is shown anymore on it, which should lead to less confusion about whether the settings visible there apply globally or not. 2.2 Dealing with Per-Site Security Settings There are a number of features disabled on higher security settings as they are potentially dangerous, yet sometimes users need or want to allow them anyway. So far, these options were exposed by click-to-play buttons or directly in the NoScript user interface accessible over the toolbar button. With NoScript gone from the toolbar the click-to-play options remain, but easily allowing JavaScript per site and making the status of NoScript related settings visible is not available anymore. To solve this I'd propose to follow the path we are currently taking with our circuit display redesign[2]: we are moving site specific settings into the URL bar. One way to do that would be to use the Permissions section which opens after clicking on the "i" icon in the URL bar. However, while showing the security permissions the user has granted there (too) is a good idea, it does not solve the problem of easily allowing e.g. JavaScript on a website, and seeing its status without the need to click on any button. We could have small icons on the right side of the URL bar accomplishing that, though. That way, users could easily see if they had JavaScript, or WebGL, or ... enabled on that particular website in case they are on higher security levels. Moreover, they would be able to adjust those permissions quickly without the need to deal with any NoScript user interface or additional menus just by toggling those icons. By default only the option to temporarily allow JavaScript would be visible. All the click-to-play features could be made visible once there is a respective object embedded in a website or, even better, once the user actually chose to unblock any of them. 3 Additional Considerations 3.1 Where Are My Extensions Gone? Some users might be confused and think NoScript and HTTPS Everywhere are gone now, plus they want to have their "old" way of setting their per-site settings back. That's okay and they can easily add NoScript and HTTPS Everywhere back to their toolbar if they wish. It would be good to point this out in the transition phase to the new interface at least. 3.2 How Do We Inform Users about the New Interface? I don't know yet how we ideally inform users about the new interface. That is not part of this proposal but might merit an own one. 3.3 Should We Change the Default Security Level? As much as I wished to change the default security level, to e.g. "Safer", right now I think we are not there yet. Part of the security control redesign should be fixing bugs that make the current and new interface less effective and painful to use[4][5][6][7]. We could revisit that discussion, though, once we have solved the low hanging bugs. [1] https://gitweb.torproject.org/builders/tor-browser-build.git/tree/projects/t... [2] https://trac.torproject.org/projects/tor/ticket/24309 [3] https://trac.torproject.org/projects/tor/ticket/21183 [4] https://trac.torproject.org/projects/tor/ticket/22981 [5] https://trac.torproject.org/projects/tor/ticket/22985 [6] https://trac.torproject.org/projects/tor/ticket/20314 [7] https://trac.torproject.org/projects/tor/ticket/21805
On Thu, Feb 01, 2018 at 08:27:00AM +0000, Georg Koppen wrote:
I managed to come up with a proposal for redesigning the security controls (see below). As always feedback and discussion is very welcome.
During the 2015 UX sprint, one of the things we asked was for people to explain what they thought every item in the toolbar was for. It's kind of old now (Tor Browser 4.0), but anyway here are the parts of the transcripts that had to do with the toolbar. https://people.torproject.org/~dcf/uxsprint2015/#p1 Toolbar starts at 0:19:40. OK. So now, you saw the onion one. I want you to go through the toolbar, and you can explore them a little bit. Explain to me what each of these things means to you, what you think they control. Like from here to here? Yeah. Oh, OK. "Forbid Scripts Globally (advised)". I have no idea. "Forbid scripts". Should I click, can I click on it? Yeah, you can click on it. You can explore it. OK. I'm going to click on it. OK. Now I have a... OK. So maybe to be super secure you are forbidding, like, automatic scripts to run. I don't actually know what "scripts" means. But, there's a little... What's that thing called? I don't know what it's called either. Circle with a cross through it, which means that's not happening. OK. "Permanent 'Allow' commands in private windows". I don't know what that means either. "Options...". OK, this looks like advanced things. Oh, look, it's under "Advanced". [Laughter.] OK, so there's like general stuff, "Top-level sites by default". I just have no idea what any of this means. "Whitelist". OK, maybe like blacklist, but opposite? But I don't know what that means. "You can specify which web sites are allowed to execute scripts." OK, so maybe scripts are something that web sites automatically do. And you don't want them to. OK, so you could put... Oh, I get it. So these are the ones you would put in if you're like, OK, it's OK if these websites do whatever they want to do. "Embeddings". OK, these are just advanced ways of restricting untrusted sites, I believe. Like, that's what it says. "Appearance". "Status bar label", "Contextual menu"... OK. Lots of appearance things. I don't, I actually have no idea what most of these, I don't know really what this means at all. "Notifications". "Show messages about blocked scripts". OK, that makes sense. "Place messages at the bottom". I don't know what "XSS, question mark" means. "Show message about blocked M-E-T-A redirections". I don't know. OK, "Advanced". Other stuff I have no idea what it means. I'll just say... OK. If you could, what, if you could summarize your understanding of everything that's behind that button, what would it be? Advanced security settings. OK. Yeah. And then, should I go to this? Yeah, do the next one. Yeah. The onion... OK, so these also look like different settings. First one says "New Identity" and I already clicked on that so I sort of think I know what it means. "Cookie Protections". I sort of know what that means, too. I'll click on it to see what they then say. Oh, I... OK. "Remove all but protected..." "Protect New Cookies." "Do Not Protect New Cookies." That confuses me, because... "Prot—" Because I think I would want to... "Prot—" What? Protect new cookies from what? "Do Not Protect New Cook—". I don't know. I'm getting confused. Like, OK. "Do Not Protect New Cookies". I don't know. OK. I'm going to click OK. OK. "Preferences". OK. So, if I want to use proxy settings, and more security settings. "Don't record browsing history or website..." "Disable browser plugins...", "Restrict third-party cookies...", OK. "Change details that distinguish you from other Tor...", OK. Do you know of any reason, from reading those options, why you would go to this screen? Would you have a reason to? Um, if you don't want your browser history to be... "Don't record browser history..." Wait. Now I'm also getting... I was going to say, if you don't want your browser history to be recorded, but this says "Don't record browser history". Oh, OK, yeah. So if you click it then... "Don't record browser history". Oh, OK, so then, oh I get it. So yeah, you're in the private browsing mode. So if you don't want, if you're researching Iran, and you are searching a bunch of things, you don't want the government, or whoever, to be skeptical of your purposes for researching Iran, then you can just search through private browsing mode. I don't really know about the other ones. "Restrict third-party cookies", "Change details that distinguish you from other Tor Browser users"... Oh, if you want to remain anonymous within your searching, I guess. OK. OK. So if you could summarize, what do you think that onion button is for, in general? Oh, the onion as a whole. Like, maintaining anonym—, anon— [Laughter.] Yeah, anony— Anonymity. That word! Yeah, wow. Oh my gosh. Yeah, and like the settings of your Tor Browser, I guess. OK. And the rest of the things in the top here, what, some of them may be more familiar, but what do you, what does each of them do? I would think that you can like type in a web address here. OK. And refresh, "Reload current page", and then search for something with this little magnifying glass, or the Startpage. Or, search, I guess, using the Startpage. And the, one more here, do you know what this one does? I don't know. Oh, OK. Yeah. "Print", "Save", "New Window", "Bookmarks", "History", "Find", "Developer", "Add-ons", "Preferences", "Downloads"... Yeah. Like all the general... Sure, right right. https://people.torproject.org/~dcf/uxsprint2015/#p2 Toolbar starts at 0:12:50 All right, so now the top of the window here. I want you to find all these little icons and explain what you think each one of them means. Okay, okay. I'm going to start with the first one. Okay, you can go ahead and explore them if you need to. Okay. "Forbid Scripts Globally (advised)". I am not sure what it means. Mmhmm. I click, nothing happens. And uh, oh, here's the, under the onion I think it is all settings and information about the Tor webpage. Uh. I will click on "Preference". "Use the recommended proxy settings for my version of Firefox". I am on Firefox? I thought I am on Safar— Wait. what? Okay, so if that's surprising, just... Okay. So it says "Use the recommended proxy settings for my version of Firefox". So, I guess when I click "New Identity" it opens Firefox? No. Wait—Sorry, I am a little bit confused now. [Laughter.] That's fine. I can explain some things afterward. But just now, just explain that you are confused. Okay, I am confused now. The "Proxy Settings", so I am going to the security settings. Oh, it says "Don't record browsing history or website data". "Disable browser plugins, (such as Flash)". "Restrict third-party cookies and other tracking"... Okay, good to know. Um, and on the right of the onion tab it's the search engine. And so what is this? Okay. So it's the default webpage set on the browser. How about the bar here? Oh, okay. Here is the history, "Save Page", "Bookmarks", like normal web browser has. Okay. Uh, "Sign in to Sync". Oh, okay. So I can use this on one laptop and I will see my history and bookmarks on the other. Mmhmm. Okay, good to know. Um. Is it? Great. That's it. Great, fantastic. https://people.torproject.org/~dcf/uxsprint2015/#p3 Toolbar starts at 0:27:26 "Explain your best understanding of all the items in the toolbar." And by "the toolbar", we mean this. Not all of this. That would be atrocious. Just... This. Yeah. And you can say as much or as little as you want to. Like "I would never use this" or just like "I don't care" or like "What do you do there", something like that. So, I tried before to type in in that small, in that search engine directly what I'm looking for, which is what Google does, but here it doesn't work, so I guess unless I type in a direct web site, I would only use it for that. And then I'm guessing that this Startpage is kind of the same thing as what's inside the page, which is, you type in what you're looking for. Would I use it? I guess so. I don't know, maybe I'd rather use the big one because it's bigger, so it's easier to click on it. But I don't even know if that's what it does. I'd have to check. And type in "onion" and see if that's what I'm getting. Yeah. So yeah. I think I would use the big one, just because this is small. I think, same thing happened to me with Safari, is that, I find it really small, all the icons and everything so that it's harder to click on or navigate. Then there's a little plus here to open a new file. I tend to use Command-T for new tab instead of the little plus. Same reason, just because, it's less, you need to be less precise to just type Command-T rather than look with your mouse for the small plus. Then there's that onion. So yeah, none of those two things on the left I would take a look at. OK. That's fair. I'm also a little confused as to... I guess "Sp" means "Startpage" but I don't know if I'm on Tor Browser, or what is Startpage, I don't know what that is, I guess it's, I don't really know. But yeah. So if I take a look at the onion, I guess it's about preferences and network settings, "New Identity". So that's cool. I think if it's in the toolbar up above, it's good enough. But, I don't know. And this is about... "Forbid scripts globally". "Permanent 'Allow' commands". So I don't know what that means. But I guess may it could be an ad block or something like that. If I'm guessing. All right. Do you have anything else to say? Um... Oh no, this isn't like a trick question. Like, I'm supposed to let you talk as much as you want to talk and not cut you off, but I don't necessarily want to you like talk more if you're done talking. Just, I guess, generally, because when you're used to one specific browser, it's kind of hard to switch. Also, I feel like I've seen just like Startpage, other things, pages like this, where it's blue here, and then it's just a list of things. It's kind of small, it's not really easy. Kind of like Craigslist or Yahoo.com. Yeah, Craigslist, it looks so bad. It's kind of, it's kind of hard to navigate when it's small. All right. https://people.torproject.org/~dcf/uxsprint2015/#p4 Toolbar starts at 0:31:01 Good, and so finally, just go along the toolbar and give a summary of what you think each UI element does, in the top part of the browser here. Okay, so this is the good old NoScript, and it is set to block all JavaScript right now. Which is cool. It appears to be just like the NoScript I run in my browser, so no surprises there. Now that I finally recognize the little green onion, I see that's the Tor menu and that tells me, or that gives me control over the Tor module itself. I can tear down circuits, I can tell what I want it to do with cookies, configure all the other details. I didn't click on the "About", but I guess that tells me what version I am running if I have to file a bug report. It also lets me change the network settings. I've got the usual sort of tabbed browsing experience and I can click the little plus to open up all kinds of new tabs. I've got the usual sort of omnibox where I can either type in any URL that I want to browse to or I can type in a search string. And if I type in "search string", it sends me to startpage.com which seems to be the browser's default search provider, as is shown in the little search tool, and I have a selection of other search engines I could use... Startpage is the default for some reason, there is also DuckDuckGo, Google, Amazon, Bing, I guess they get progressively worse as you go down the list. [Laughter.] And then the typical Firefox settings menu. I didn't play with HTTPS Everywhere. But it seems to be set up to force HTTPS wherever possible. Great, that is the end! https://people.torproject.org/~dcf/uxsprint2015/#p5 Toolbar starts at 0:18:17 Okay. Alright, so the last one, just go through the toolbar at the top part here, and explain what you think each part of it means. Okay. This... oh. So I haven't really messed with this before. But I'm... "Forbid Scripts Globally". I mean, I am guessing that this is just another like layer of protection for, like, not revealing your IP address? But there might be some situations where you'd have to like allow, to like make something work on certain pages. But I don't know. I'd probably just leave that on its default settings. Which I guess... It's saying, the one that is advised isn't the default? Which is a bit confusing. And now, I am on the one that is advised. And the one that it was defaulted on, it is telling me is dangerous! Which... I don't know... that's kind of weird to me. [Laughter.] But. Okay. I think I don't understand enough. I mean, I am guessing, is this maybe, like my thought process, are these scripts, does that mean like, allowing webpages to run scripts like on your computer, or something? I don't really understand that. But this whole "dangerous"/"recommended" thing and the dangerous one is the one that defaults is weird to me. Okay. This I know is New Identity. But then I have toyed around before with like preferences and looking around and usually it's out of my understanding. Yeah. So I will just close that. I get the back button. The search bar is intuitive, I mean, it just looks like Firefox. Um, this is familiar. I can choose which search engine I want. And then this is also familiar. And I see HTTPS Always is running, so that's cool. Alright, great.
Thanks for sharing this proposal, Georg. I think it's a really good approach for simplifying the UI. I definitely agree it would be good to hide the NoScript toolbar button, and of course we would need to re-surface some of its functionality so it's easier to understand. I want to mention a couple of issues I think we discussed in Montreal but I think might be useful in the discussion here. 1. A current problem we have with NoScript is that it does not respect first-party isolation (FPI), which is both a security and privacy issue. For example, if I set the Security Settings to Medium, and visit youtube.com, and click on the NoScript button to unblock media from YouTube.com, then embedded YouTube videos are now unblocked on all other websites. The same goes for more subtle things like Google Analytics scripts. So I'd propose we try to get FPI working for NoScript unblocking, similar to our enforcement of FPI for Permissions from #21569. That's especially important if we emphasize that controls in the URL bar or the Permissions door-hanger are intended for per-site use. 2. The Security Slider is also quite dangerous if used for per-site purposes. If a user decides they want to visit A.com at "Low" Security and B.com at "High" Security, they have to be very careful not to accidentally expose B.com to "Low" Security. A simple click of the back button could result in a mistake. Or, if the user has multiple tabs or windows open, and they switch the Security Slider, because of the current tab, they apply the new security setting to all open tabs, which could result in accidental unwanted exposure to dangerous content in background tabs. Therefore, I'm wondering if putting the Security Slider on the toolbar might actually increase the danger for some users by encouraging its frequent use. A possibly safer approach could be to display the global Security Slider either embedded in the about:tor page, or in a prompt at startup. That way we can force users to make a one-time decision for the global setting and discourage them from changing it repeatedly while they browse. Yet another approach could be to invoke "New Identity" whenever Security Settings are changed, such that all tabs are closed and a new empty window is opened before the new global setting takes effect. (Of course users would need to be warned and given the option to cancel.) 3. I don't think it's feasible to make scripts, Fonts, MathML, some audio, etc., click-to-play. And while it's true that video, SVG and WebGL can be click-to-play, in practice it may be challenging to make the click-to-play behavior work smoothly given the interactions with scripts. So one issue we'll have to consider is how many different per-site options we expose to users in the Permissions doorhanger. I think it would be confusing to ask users to decide which content features (scripts vs. fonts vs videos vs ...) are safe to enable; rather, they should be answering the question: do I consider this website to be dangerous or not? So, my suggestion would be to expose a single toggle option: namely, [all-features-disabled | all-features-enabled]. On Thu, Feb 1, 2018 at 12:27 AM, Georg Koppen <gk@torproject.org> wrote:
Hi!
I managed to come up with a proposal for redesigning the security controls (see below). As always feedback and discussion is very welcome.
Filename: XXX-redesign-security-controls.txt Title: Redesign of Tor Browser's Security Controls Author: Georg Koppen Created: 1-February-2018 Status: Open
1 Introduction
Tor Browser is well-known for its defenses against web tracking and fingerprinting. However, providing Tor users just a privacy-enhanced browser is often not enough to safeguard against deanonymization attacks as those protections might simply get bypassed by exploiting browser vulnerabilities. Tor Bowser therefore offers several security enhancements as well to reduce that risk. Most of those features are provided by extensions which Tor Browser includes, namely Torbutton, NoScript, and HTTPS Everywhere.
1.1 Motivation
By default Torbutton, NoScript, and HTTPS Everywhere are visible on the toolbar in Tor Browser and there is no hint about possible security enhancements, with the exception of a notification bar shown on first start and pointing to our security slider. This has a number of suboptimal outcomes which this proposal seeks to address:
a) Security controls are scattered over and within different extensions. That makes it hard to understand which knobs a user could turn to improve their security settings while not being exposed to additional fingerprinting risks. b) The toolbar gets cluttered with three additional icons that provide access to both per-site and global security settings. This is confusing to users. Part of the confusion stems from mixing non-global with global security controls on the toolbar not indicating which of them just affect a particular website while others affect the whole browser session. Another part is that users feel the need to navigate through different levels of extension menus to make basic adjustments to their security level. c) There is the security vs. usability trade-off and little incentives to change the default which comes with Tor Browser. That results in users just staying on the lowest security level while at least some of them could get convinced to raise that level if we managed to provide an improved experience around our security controls, both functionality- and UX-wise.
1.2 The State of the Security Controls
That is how the toolbar in Tor Browser looks like currently:
---------------------------------------------------------------------- | --- --- ------------------------- --------------- --- --- | | |N| |T| | URL bar | | Search bar | |H| |M| | | --- --- ------------------------- --------------- --- --- | ----------------------------------------------------------------------
N = NoScript button T = Torbutton button H = HTTPS Everywhere button M = (Hamburger) Menu button
We include HTTPS Everywhere to help against potential Tor Exit node eavesdroppers and active attackers. To provide users with optional defense-in-depth against JavaScript and other potential exploit vectors, we use NoScript modifying some of its defaults[1]. Torbutton includes the security slider which is meant to give users an easy way to adjust their security level from Standard to Safest, depending on their perceived needs.
2 Proposal
Generally, items on the toolbar serve two important purposes: they are shortcuts to features often used and they inform about current state. With that in mind we can think about redoing our toolbar helping that way with issues outlined in 1.1 a) and b). The remaining problems (part of 1.1 b) and 1.1 c)) will be addressed in section 2.2 and 3.3.
2.1 Restructuring the Toolbar
2.1.1 Removing HTTPS Everywhere and NoScript from the Toolbar
I'd propose we remove both NoScript and HTTPS Everywhere from the toolbar and leave Torbutton on it for now:
Torbutton serves a number of purposes and access to security settings is just one of them. Moreover, we are in the process of restructuring at least part of its functionality right now[2] and more will likely happen in the future in this area. We can think about whether Torbutton should remain on the toolbar after that transition is done.
HTTPS Everywhere has the option to block all unencrypted requests and apart from that is just enforcing HTTPS connections according to the rulesets it ships, which is our default. There is not much gain security-wise leaving it on the toolbar and users might just be confused by the "Block all unencrypted requests" option. I'd argue as well that the status indicator is not important enough to justify precious space on the toolbar either.
NoScript comes with a myriad of configuration options. We try to abstract that away by shipping a list of defaults for Tor Browser[1]. But still having NoScript easily accessible makes it dangerous to choose the wrong option, especially as the majority of its functionality does not need to be exposed for Tor Browser users. Moreover, the scary warning icon which is visible when NoScript allows JavaScript is highly confusing to users as we ship this configuration as our default. Removing the icon from the toolbar should solve those two problems. We might want to think about exposing the small amount of functionality which especially users with the security slider set to "Safest" might need: managing finer-grained script control. See section 2.2 for that.
2.1.2 Adding a Security Settings Button to the Toolbar
I'd like to propose a new button on the toolbar giving easy access to what is essentially the tool that we want to promote: the security slider. We could use an icon similar to the one suggested by ninavizz[3] or come up with a different solution. The button would open the security slider menu with a right-click. With a left-click, keyboard shortcuts, and mouse-wheel scrolling one can adjust the security level directly.
The new toolbar would look like:
---------------------------------------------------------------------- | --- --- ------------------------------- --------------- --- | | |T| |S| | URL bar | | Search bar | |M| | | --- --- ------------------------------- --------------- --- | ----------------------------------------------------------------------
T = Torbutton button S = Security Settings button M = (Hamburger) Menu button
Note: The reorganized toolbar has the additional benefit that no per-site state is shown anymore on it, which should lead to less confusion about whether the settings visible there apply globally or not.
2.2 Dealing with Per-Site Security Settings
There are a number of features disabled on higher security settings as they are potentially dangerous, yet sometimes users need or want to allow them anyway. So far, these options were exposed by click-to-play buttons or directly in the NoScript user interface accessible over the toolbar button.
With NoScript gone from the toolbar the click-to-play options remain, but easily allowing JavaScript per site and making the status of NoScript related settings visible is not available anymore. To solve this I'd propose to follow the path we are currently taking with our circuit display redesign[2]: we are moving site specific settings into the URL bar. One way to do that would be to use the Permissions section which opens after clicking on the "i" icon in the URL bar. However, while showing the security permissions the user has granted there (too) is a good idea, it does not solve the problem of easily allowing e.g. JavaScript on a website, and seeing its status without the need to click on any button. We could have small icons on the right side of the URL bar accomplishing that, though. That way, users could easily see if they had JavaScript, or WebGL, or ... enabled on that particular website in case they are on higher security levels. Moreover, they would be able to adjust those permissions quickly without the need to deal with any NoScript user interface or additional menus just by toggling those icons. By default only the option to temporarily allow JavaScript would be visible. All the click-to-play features could be made visible once there is a respective object embedded in a website or, even better, once the user actually chose to unblock any of them.
3 Additional Considerations
3.1 Where Are My Extensions Gone?
Some users might be confused and think NoScript and HTTPS Everywhere are gone now, plus they want to have their "old" way of setting their per-site settings back. That's okay and they can easily add NoScript and HTTPS Everywhere back to their toolbar if they wish. It would be good to point this out in the transition phase to the new interface at least.
3.2 How Do We Inform Users about the New Interface?
I don't know yet how we ideally inform users about the new interface. That is not part of this proposal but might merit an own one.
3.3 Should We Change the Default Security Level?
As much as I wished to change the default security level, to e.g. "Safer", right now I think we are not there yet. Part of the security control redesign should be fixing bugs that make the current and new interface less effective and painful to use[4][5][6][7]. We could revisit that discussion, though, once we have solved the low hanging bugs.
[1] https://gitweb.torproject.org/builders/tor-browser-build.git/tree/projects/t... [2] https://trac.torproject.org/projects/tor/ticket/24309 [3] https://trac.torproject.org/projects/tor/ticket/21183 [4] https://trac.torproject.org/projects/tor/ticket/22981 [5] https://trac.torproject.org/projects/tor/ticket/22985 [6] https://trac.torproject.org/projects/tor/ticket/20314 [7] https://trac.torproject.org/projects/tor/ticket/21805
_______________________________________________ tbb-dev mailing list tbb-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tbb-dev
On 1 February 2018 at 19:33, Arthur D. Edelstein <arthuredelstein@gmail.com> wrote:
1. A current problem we have with NoScript is that it does not respect first-party isolation (FPI), which is both a security and privacy issue. For example, if I set the Security Settings to Medium, and visit youtube.com, and click on the NoScript button to unblock media from YouTube.com, then embedded YouTube videos are now unblocked on all other websites. The same goes for more subtle things like Google Analytics scripts. So I'd propose we try to get FPI working for NoScript unblocking, similar to our enforcement of FPI for Permissions from #21569. That's especially important if we emphasize that controls in the URL bar or the Permissions door-hanger are intended for per-site use.
Oof, yea NoScript should get FPI treatment.
2. The Security Slider is also quite dangerous if used for per-site purposes. If a user decides they want to visit A.com at "Low" Security and B.com at "High" Security, they have to be very careful not to accidentally expose B.com to "Low" Security. A simple click of the back button could result in a mistake. Or, if the user has multiple tabs or windows open, and they switch the Security Slider, because of the current tab, they apply the new security setting to all open tabs, which could result in accidental unwanted exposure to dangerous content in background tabs.
Therefore, I'm wondering if putting the Security Slider on the toolbar might actually increase the danger for some users by encouraging its frequent use. A possibly safer approach could be to display the global Security Slider either embedded in the about:tor page, or in a prompt at startup. That way we can force users to make a one-time decision for the global setting and discourage them from changing it repeatedly while they browse.
Yet another approach could be to invoke "New Identity" whenever Security Settings are changed, such that all tabs are closed and a new empty window is opened before the new global setting takes effect. (Of course users would need to be warned and given the option to cancel.)
Why not make the security slider per-site? Have a default slider setting, and a per-first-party override. Glancing things over, engineering-wise it looks like it'd mostly be not-that-difficult plumbing. I mean you probably couldn't bang it out in a week, but maybe a couple? The hardest part is trying to do it in such a way that it becomes upliftable.... I'm pretty sure this has been discussed before, but I guess I forget where the discussion went... -tom
Tom Ritter:
On 1 February 2018 at 19:33, Arthur D. Edelstein <arthuredelstein@gmail.com> wrote:
1. A current problem we have with NoScript is that it does not respect first-party isolation (FPI), which is both a security and privacy issue. For example, if I set the Security Settings to Medium, and visit youtube.com, and click on the NoScript button to unblock media from YouTube.com, then embedded YouTube videos are now unblocked on all other websites. The same goes for more subtle things like Google Analytics scripts. So I'd propose we try to get FPI working for NoScript unblocking, similar to our enforcement of FPI for Permissions from #21569. That's especially important if we emphasize that controls in the URL bar or the Permissions door-hanger are intended for per-site use.
Oof, yea NoScript should get FPI treatment.
2. The Security Slider is also quite dangerous if used for per-site purposes. If a user decides they want to visit A.com at "Low" Security and B.com at "High" Security, they have to be very careful not to accidentally expose B.com to "Low" Security. A simple click of the back button could result in a mistake. Or, if the user has multiple tabs or windows open, and they switch the Security Slider, because of the current tab, they apply the new security setting to all open tabs, which could result in accidental unwanted exposure to dangerous content in background tabs.
Therefore, I'm wondering if putting the Security Slider on the toolbar might actually increase the danger for some users by encouraging its frequent use. A possibly safer approach could be to display the global Security Slider either embedded in the about:tor page, or in a prompt at startup. That way we can force users to make a one-time decision for the global setting and discourage them from changing it repeatedly while they browse.
Yet another approach could be to invoke "New Identity" whenever Security Settings are changed, such that all tabs are closed and a new empty window is opened before the new global setting takes effect. (Of course users would need to be warned and given the option to cancel.)
Why not make the security slider per-site? Have a default slider setting, and a per-first-party override.
Glancing things over, engineering-wise it looks like it'd mostly be not-that-difficult plumbing. I mean you probably couldn't bang it out in a week, but maybe a couple? The hardest part is trying to do it in such a way that it becomes upliftable....
I'm pretty sure this has been discussed before, but I guess I forget where the discussion went...
I guess https://trac.torproject.org/projects/tor/ticket/21034 has the discussion you were looking for. Georg
Arthur D. Edelstein:
Thanks for sharing this proposal, Georg. I think it's a really good approach for simplifying the UI. I definitely agree it would be good to hide the NoScript toolbar button, and of course we would need to re-surface some of its functionality so it's easier to understand. I want to mention a couple of issues I think we discussed in Montreal but I think might be useful in the discussion here.
1. A current problem we have with NoScript is that it does not respect first-party isolation (FPI), which is both a security and privacy issue. For example, if I set the Security Settings to Medium, and visit youtube.com, and click on the NoScript button to unblock media from YouTube.com, then embedded YouTube videos are now unblocked on all other websites. The same goes for more subtle things like Google Analytics scripts. So I'd propose we try to get FPI working for NoScript unblocking, similar to our enforcement of FPI for Permissions from #21569. That's especially important if we emphasize that controls in the URL bar or the Permissions door-hanger are intended for per-site use.
While preparing the proposal I tried to read up on all the older discussions we had about how to improve the design of our security controls. In particular, in your last comment on #21034 you seemed to be thinking that we could largely avoid doing what you are suggesting above by addressing the tickets you mentioned there (and probably more). That's actually part of the proposal as written (see section 3.3). So, I am a bit curious whether you changed your mind and if so to hear about new arguments. As it stands I still don't see a good path forward for what is essentially a per-site security exceptions idea. That's the only reason why I left that out for now. Once we've thought about this more it might merit an own proposal, but we should not optimize for the exception case right now or block improvements for a large part of our users based on that idea being ready. I think we can do at least as good as NoScript currently does when moving the exceptions into the URL bar without having the full FPI ready. E.g. showing in the URL bar that WebGL is enabled for an embedded third party domain does not strike me as unreasonable. After all you allowed it in the first place in any context and hence in this particular site context as well.
2. The Security Slider is also quite dangerous if used for per-site purposes. If a user decides they want to visit A.com at "Low" Security and B.com at "High" Security, they have to be very careful not to accidentally expose B.com to "Low" Security. A simple click of the back button could result in a mistake. Or, if the user has multiple tabs or windows open, and they switch the Security Slider, because of the current tab, they apply the new security setting to all open tabs, which could result in accidental unwanted exposure to dangerous content in background tabs.
I think we should fix as many issues as possible that drive users to "(ab)use" the security slider that way. It's debatable whether it is meant to be used for that scenario, though. Again, I listed a number of tickets in the proposal that could help with that and probably more remain. We should acknowledge, however, that we can't make all websites usable on all security slider levels by default. And we should think about possible improvements from that angle. Burying it deep, or better, burying the security control button deep, does not seem to be the right conclusion to me, as there is quite some value to show users the current state of their session-wide security settings and making those settings easily customizable in case they actually want to do that.
Therefore, I'm wondering if putting the Security Slider on the toolbar might actually increase the danger for some users by encouraging its frequent use. A possibly safer approach could be to display the global Security Slider either embedded in the about:tor page, or in a prompt at startup. That way we can force users to make a one-time decision for the global setting and discourage them from changing it repeatedly while they browse.
As indicated above that does not help with an easy answer to the important question about which security state I am actually in.
Yet another approach could be to invoke "New Identity" whenever Security Settings are changed, such that all tabs are closed and a new empty window is opened before the new global setting takes effect. (Of course users would need to be warned and given the option to cancel.)
Yes, that might be an option worth thinking about.
3. I don't think it's feasible to make scripts, Fonts, MathML, some audio, etc., click-to-play. And while it's true that video, SVG and WebGL can be click-to-play, in practice it may be challenging to make the click-to-play behavior work smoothly given the interactions with scripts. So one issue we'll have to consider is how many different per-site options we expose to users in the Permissions doorhanger. I think it would be confusing to ask users to decide which content features (scripts vs. fonts vs videos vs ...) are safe to enable; rather, they should be answering the question: do I consider this website to be dangerous or not? So, my suggestion would be to expose a single toggle option: namely, [all-features-disabled | all-features-enabled].
Hm. I am not sure yet. I am not convinced we need to expose users to the dangers of WebGL, SVG etc. just because they need scripts enabled on a website. Georg [snip]
On Wed, Feb 7, 2018 at 4:18 AM, Georg Koppen <gk@torproject.org> wrote:
While preparing the proposal I tried to read up on all the older discussions we had about how to improve the design of our security controls. In particular, in your last comment on #21034 you seemed to be thinking that we could largely avoid doing what you are suggesting above by addressing the tickets you mentioned there (and probably more). That's actually part of the proposal as written (see section 3.3). So, I am a bit curious whether you changed your mind and if so to hear about new arguments.
My original thinking for #21034 was to try to address two problems: (1) The set of options exposed by NoScript is complex. (2) Users may be trying to use the (global) security slider for individual sites. I have. :( As I sort of mentioned in that comment in #21034, I think #22981 (enabling video/audio on HTTPS sites for Medium security) will be particularly helpful for these two problems by making it rarely necessary for users at Medium Security to make adjustments via NoScript or the security slider. But, on the other hand, if we decide against #22981, then I think #21034 remains important. Also, since I wrote that comment, I have realized there is a another problem: (3) NoScript does not respect FPI. so I do lean more toward some kind of solution for #22981 again. Each of (1), (2), and (3) have different possible solutions. For me, a per-site security toggle seems to be the cleanest solution to all three issues. But of course there are many possible alternatives that would solve these issues to varying degrees.
[snip] After all you allowed it in the first place in any context and hence in this particular site context as well.
Can you explain what you mean by this? I'm not sure I understand it.
[snip] As indicated above that does not help with an easy answer to the important question about which security state I am actually in.
I agree it would be good to display an indicator about what global security state you're in.
[snip] So, my suggestion would be to expose a single toggle option: namely, [all-features-disabled | all-features-enabled].
Hm. I am not sure yet. I am not convinced we need to expose users to the dangers of WebGL, SVG etc. just because they need scripts enabled on a website.
Suppose you think there is a 10% chance that website X.com will be serving an exploit. Do you enable scripts, but not WebGL? I feel this question is too large a burden on users. It requires them to understand what scripts and WebGL are! :) And it presumes some level of risk analysis that is basically impossible (what's more dangerous, scripts, or WebGL?). So I think we should provide some sort of simplified set of options that guide users to reasonable decisions. Maybe we could make progress by considering a set of thought-experiment user stories (or even, user studies) visiting particular websites and describing what the decision making process should be. For example, if I visit YouTube (which has scripts, video and audio) under High Security or under Medium Security, what should my decision making process be? How many decisions/clicks should be required to get the website working, and at what stage do I decide to give up for security reasons? What security/privacy mistakes could I make and how can Tor Browser prevent those mistakes? Other important sites might be online games, social media, Google documents, etc. Arthur
On Wed, Feb 7, 2018 at 9:56 AM, Arthur D. Edelstein <arthuredelstein@gmail.com> wrote:
Also, since I wrote that comment, I have realized there is a another problem: (3) NoScript does not respect FPI. so I do lean more toward some kind of solution for #22981 again.
Oops. I meant to say, "I do lean more toward some kind of solution for #21034 again."
On 8 Feb 2018, at 04:56, Arthur D. Edelstein <arthuredelstein@gmail.com> wrote:
Maybe we could make progress by considering a set of thought-experiment user stories (or even, user studies) visiting particular websites and describing what the decision making process should be. For example, if I visit YouTube (which has scripts, video and audio) under High Security or under Medium Security, what should my decision making process be? How many decisions/clicks should be required to get the website working, and at what stage do I decide to give up for security reasons? What security/privacy mistakes could I make and how can Tor Browser prevent those mistakes? Other important sites might be online games, social media, Google documents, etc.
Let's make sure we include some torproject sites in this list: * Atlas (for relay operators, requires JS, and SVG for graphs) * Trac (for users reporting bugs, requires JS to reply to a comment) Personally, I run in High security mode, because I use Tor Browser to open links that people send me. But that means I have to use NoScript all the time on these TPO sites. Atlas and consensus-health graphs are the most common reason I accidentally end up in "medium" security mode on other sites. A visual indicator would really help me here. T -- Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n ------------------------------------------------------------------------
On 2/7/18 4:23 PM, teor wrote:
Let's make sure we include some torproject sites in this list: * Atlas (for relay operators, requires JS, and SVG for graphs) * Trac (for users reporting bugs, requires JS to reply to a comment)
Personally, I run in High security mode, because I use Tor Browser to open links that people send me.
But that means I have to use NoScript all the time on these TPO sites.
Atlas and consensus-health graphs are the most common reason I accidentally end up in "medium" security mode on other sites.
A visual indicator would really help me here.
I assume the reason you need to change the security slider from "Safest" (aka high) to "Safer" (aka medium) is to allow SVGs? Otherwise, you would just use the NoScript override to allow JS. But maybe there are other reasons, which definitely argues for working through some user stories as Arthur suggested. Here are some additional thoughts that Kathy and I had after reading and thinking about the proposal: - Some aspects of this design involve creating new UI for functionality that is handled under the covers by NoScript. We should think about how we will accomplish that integration. For example, should we contribute UI design assistance and patches to NoScript? - There is some danger that redesigning things piecemeal that Tor Browser adds to Firefox will cause us to end up with a final result that is not as good as it could be. Specifically related to the security controls proposal, we should take time now to think about how each function that is currently in the Torbutton menu will be exposed. We may only have three items left: New Identity Tor Network Settings Check for Tor Browser Update - We should think about how to best expose the current security slider level. If people change it often and then forget that they did so, we should consider making it very obvious what the active setting is, e.g., change the color and/or add a background pattern to the entire toolbar. We could also think about adding some kind of temporary mode for the security slider so it returns to the user's default level. It might be tricky to handle entering and leaving such a temporary setting though. -- Mark Smith Pearl Crescent http://pearlcrescent.com/
On Thu, Feb 08, 2018 at 11:04:38AM -0500, Mark Smith wrote:
Here are some additional thoughts that Kathy and I had after reading and thinking about the proposal:
- Some aspects of this design involve creating new UI for functionality that is handled under the covers by NoScript. We should think about how we will accomplish that integration. For example, should we contribute UI design assistance and patches to NoScript?
We don't use all the functionality NoScript provides, has anyone evaluated how much time it will take for reimplementing the features directly into tor-browser? In particular, if we're already thinking about burying the NoScript settings so it is out-of-sight from the user, can we easily patch Firefox (or torbutton) so content is blocked or click-to-play instead? On mobile, NoScript is debatably even less usable than on desktop, so I'd like to hide it (or drop it completely), if possible. I didn't see an obvious ticket with details on this. A quick search found a couple requests for this, but I didn't see a technical discussion: https://trac.torproject.org/projects/tor/query?status=accepted&status=assign... Thanks, Matt
On 9 Feb 2018, at 03:04, Mark Smith <mcs@pearlcrescent.com> wrote:
On 2/7/18 4:23 PM, teor wrote: Let's make sure we include some torproject sites in this list: * Atlas (for relay operators, requires JS, and SVG for graphs) * Trac (for users reporting bugs, requires JS to reply to a comment)
Personally, I run in High security mode, because I use Tor Browser to open links that people send me.
But that means I have to use NoScript all the time on these TPO sites.
Atlas and consensus-health graphs are the most common reason I accidentally end up in "medium" security mode on other sites.
A visual indicator would really help me here.
I assume the reason you need to change the security slider from "Safest" (aka high) to "Safer" (aka medium) is to allow SVGs?
Yes, consensus health and atlas need SVG for graphs.
Otherwise, you would just use the NoScript override to allow JS.
I use NoScript now. But after the proposal is implemented, I am not sure how I will allow JS for some sites.
But maybe there are other reasons, which definitely argues for working through some user stories as Arthur suggested.
Not that I can recall. But the slider makes it hard to identify fine-grained features needed by each website. T
Arthur D. Edelstein:
On Wed, Feb 7, 2018 at 4:18 AM, Georg Koppen <gk@torproject.org> wrote:
While preparing the proposal I tried to read up on all the older discussions we had about how to improve the design of our security controls. In particular, in your last comment on #21034 you seemed to be thinking that we could largely avoid doing what you are suggesting above by addressing the tickets you mentioned there (and probably more). That's actually part of the proposal as written (see section 3.3). So, I am a bit curious whether you changed your mind and if so to hear about new arguments.
My original thinking for #21034 was to try to address two problems: (1) The set of options exposed by NoScript is complex. (2) Users may be trying to use the (global) security slider for individual sites. I have. :( As I sort of mentioned in that comment in #21034, I think #22981 (enabling video/audio on HTTPS sites for Medium security) will be particularly helpful for these two problems by making it rarely necessary for users at Medium Security to make adjustments via NoScript or the security slider. But, on the other hand, if we decide against #22981, then I think #21034 remains important.
Also, since I wrote that comment, I have realized there is a another problem: (3) NoScript does not respect FPI. so I do lean more toward some kind of solution for #22981 again.
Each of (1), (2), and (3) have different possible solutions. For me, a per-site security toggle seems to be the cleanest solution to all three issues. But of course there are many possible alternatives that would solve these issues to varying degrees.
[snip] After all you allowed it in the first place in any context and hence in this particular site context as well.
Can you explain what you mean by this? I'm not sure I understand it.
That referred to the current way NoScript works: You are allowing, say WebGL, for domain foo.com in a first party context because you think, okay, WebGL on that domin is safe. But that automatically allows WebGL in other contexts, e.g. third-party iframes where foo.com gets loaded which are embedded in bar.com. And to be honest I think that model makes perfect sense, which is why I think the argument that we need FPI for NoScript from a *security* POV is not a good one. I had this in https://trac.torproject.org/projects/tor/ticket/21034#comment:15. Let me quote the relevant part: """ 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. """ So, FPI is a good means for dealing with cross-site tracking because there it matters whether you are in a third party context or not but if you want to defend yourself against getting exploited by content served from a particular domain first or third party context is not relevant. That leaves the argument of FPI for NoScript due to privacy reasons. I am not sure I understand that one yet. To recap: First of all the slider is a security tool and not a privacy tool. This is a deliberate decision: we want to give every Tor Browser user the same privacy guarantees and don't want to mix privacy with security functionality in the slider. Some users want to adjust their security mode according to their threat model which is why we have the slider to begin with. And in order to defend against fingerprinting due to different settings there are different slider levels with the idea that there are always enough folks on each of those levels to make this fingerprinting vector a non-issue. NoScript is helping us with that by normalizing the fingerprint you get when you are on different levels. But that's it privacy-wise what NoScript does. Now, a user making exceptions for particular domains and particular active content is already exposing themselves to tracking because they are leaving one of the slider levels. So, I guess you suggest to not stop the privacy problem but just to make it a bit less bad with FPI of NoScript as far as the privacy argument is concerned? Georg
On Thu, Feb 8, 2018 at 12:41 AM, Georg Koppen <gk@torproject.org> wrote:
""" 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. """
I hear what you're saying here, but I don't think this reasoning applies to NoScript as it is actually used in Tor Browser (or any similar implementation of per-domain blocking). Currently, if I have the global security slider set to Medium or High, then I use the NoScript menu to *unblock* resources that were blocked by default. I believe enforcing FPI on such *unblocking* decisions will not harm security. That is: if I decide to unblock thirdparty.com under A.com, then thirdparty.com will remain blocked under B.com, but there is no additional exploit exposure. Whereas, with the global security slider at Low Security, everything is already unblocked by default, so I don't have a use for the NoScript menu. There is no useful way to make per-site *blocking* decisions. (Deciding to block content that already ran doesn't protect me against exploits!) So, while enforcing FPI on the user's per-domain blocking decisions would harm security in principle, such per-domain security upgrades aren't practical. Therefore, it seems to me that FPI causes no harm to security for real use cases, at least for any model like the current one, where users choose a global default security level and then make per-site security downgrades only (no upgrades). Of course if that's the model we adopt going ahead, then the UI could enforce that model better.
Now, a user making exceptions for particular domains and particular active content is already exposing themselves to tracking because they are leaving one of the slider levels. So, I guess you suggest to not stop the privacy problem but just to make it a bit less bad with FPI of NoScript as far as the privacy argument is concerned?
I think the lack of FPI in NoScript can be a significant detriment to privacy. And it breaks our general FPI policy that users expect. With FPI, the harm from departing from a slider level will be very minimal because it doesn't permit cross-site tracking. What remains is only a very weak tracking of users by their behavior across return visits to the same site.
Arthur D. Edelstein:
On Thu, Feb 8, 2018 at 12:41 AM, Georg Koppen <gk@torproject.org> wrote:
""" 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. """
I hear what you're saying here, but I don't think this reasoning applies to NoScript as it is actually used in Tor Browser (or any similar implementation of per-domain blocking).
Currently, if I have the global security slider set to Medium or High, then I use the NoScript menu to *unblock* resources that were blocked by default. I believe enforcing FPI on such *unblocking* decisions will not harm security. That is: if I decide to unblock thirdparty.com under A.com, then thirdparty.com will remain blocked under B.com, but there is no additional exploit exposure.
Whereas, with the global security slider at Low Security, everything is already unblocked by default, so I don't have a use for the NoScript menu. There is no useful way to make per-site *blocking* decisions. (Deciding to block content that already ran doesn't protect me against exploits!) So, while enforcing FPI on the user's per-domain blocking decisions would harm security in principle, such per-domain security upgrades aren't practical.
Therefore, it seems to me that FPI causes no harm to security for real use cases, at least for any model like the current one, where users choose a global default security level and then make per-site security downgrades only (no upgrades). Of course if that's the model we adopt going ahead, then the UI could enforce that model better.
Wait, I've never said that FPI makes security *worse*. I was arguing against your point that we need FPI in NoScript because that *improves* security: """ A current problem we have with NoScript is that it does not respect first-party isolation (FPI), which is both a *security* and privacy issue. (emphasis mine) """ So, yes, I still think *security* decisions based on the URL bar domain do not give you the benefit you might intend. Or am I missing here a scenario where FPI indeed improves security as you claimed? Georg
On Thu, Feb 8, 2018 at 12:48 PM Georg Koppen <gk@torproject.org> wrote: Wait, I've never said that FPI makes security *worse*. I was arguing
against your point that we need FPI in NoScript because that *improves* security:
""" A current problem we have with NoScript is that it does not respect first-party isolation (FPI), which is both a *security* and privacy issue. (emphasis mine) """
Oh — I’m sorry — that’s my mistake to have mentioned security there. I’m not sure now why I said that. I actually think FPI is neutral with respect to security, but an important feature for privacy. Apologies. So, yes, I still think *security* decisions based on the URL bar domain
do not give you the benefit you might intend. Or am I missing here a scenario where FPI indeed improves security as you claimed?
No, I think you’re right that there’s no improvement. But FPI doesn’t necessarily imply security *decisions* based on URL bar domain. With NoScript, I can decide to unblock a video from thirdparty.com, which is a security decision based on my level of trust for that third-party domain, and introducing FPI would merely ensure that decision won’t leak to other first parties. (Personally, I would guess it’s too difficult for users to make decisions on specific third-party domains, and it’s more realistic for users to base their trust on the first party, which is visible in the URL bar and should be held responsible for third-party malware. But that is a UX/risk issue separate from the FPI question.)
On Thu, Feb 8, 2018 at 2:09 PM, Arthur D. Edelstein <arthuredelstein@gmail.com> wrote:
On Thu, Feb 8, 2018 at 12:48 PM Georg Koppen <gk@torproject.org> wrote:
Wait, I've never said that FPI makes security *worse*. I was arguing against your point that we need FPI in NoScript because that *improves* security:
Oh — I’m sorry — that’s my mistake to have mentioned security there. I’m not sure now why I said that. I actually think FPI is neutral with respect to security, but an important feature for privacy. Apologies.
On further pondering, I can think of one use case where FPI can help with security. Suppose I am using High Security, and I anonymously visit Stack Overflow. The pages on stackoverflow.com use a copy of jquery.min.js hosted by ajax.googleapis.com, so I decide to unblock that third-party script so the Stack Overflow site works smoothly. Now suppose, later, I want to log into gmail.com. I fear my government is targeting me, and will instruct Google to serve me an exploit as soon as I am identified by my username. So I decide to leave all scripts disabled on Gmail, as is the default for High Security. But because I previously unblocked ajax.googleapis.com under another first party, I am nonetheless currently exposed to a targeted exploit served by a third-party script from that domain. In general, login status can affect exploit risk significantly, so allowing blocking decisions to leak between login and non-login sites appears to be a security issue. If we modify NoScript to respect FPI, then that problem is averted.
On Thu, Feb 8, 2018 at 3:08 PM, Arthur D. Edelstein <arthuredelstein@gmail.com> wrote:
In general, login status can affect exploit risk significantly, so allowing blocking decisions to leak between login and non-login sites appears to be a security issue. If we modify NoScript to respect FPI, then that problem is averted.
Another variant might be: a government wants to deliver an exploit to everyone anonymously visiting a particular (first-party) site, say embarrassing-government-secrets.com. They again force a popular CDN provider, such as ajax.googleapis.com, to provide the exploit via a third-party script for that site specifically. Again, High Security users who have already unblocked that CDN under another, non-controversial first party such as stackoverflow.com are vulnerable in the absence of FPI. So that's an example where the risk of unblocking a third-party script depends on the trust a user has in the first-party domain.
On Thu, Feb 08, 2018 at 04:32:40PM -0800, Arthur D. Edelstein wrote:
On Thu, Feb 8, 2018 at 3:08 PM, Arthur D. Edelstein <arthuredelstein@gmail.com> wrote:
In general, login status can affect exploit risk significantly, so allowing blocking decisions to leak between login and non-login sites appears to be a security issue. If we modify NoScript to respect FPI, then that problem is averted.
Another variant might be: a government wants to deliver an exploit to everyone anonymously visiting a particular (first-party) site, say embarrassing-government-secrets.com. They again force a popular CDN provider, such as ajax.googleapis.com, to provide the exploit via a third-party script for that site specifically. Again, High Security users who have already unblocked that CDN under another, non-controversial first party such as stackoverflow.com are vulnerable in the absence of FPI. So that's an example where the risk of unblocking a third-party script depends on the trust a user has in the first-party domain.
Although this seems reasonable, I think the web is a lot more complicated than we like, and it is actually terribly difficult to reason about. There was some research conducted[0] in this area recently, here's a quote[1]: Most of the ad tech / analytics industry is premised on keeping not just users but also website operators in the dark about privacy violations. The effort required by website operators to fully audit third parties would negate much of the benefit of offloading tasks to them. [0] https://freedom-to-tinker.com/2018/01/12/website-operators-are-in-the-dark-a... [1] https://twitter.com/random_walker/status/951832450468057088 That followed a short anecdote[2] related to sites including a third-party script that provided "session replay" records of a users activity when they visit a webpage. So the premise that third-parties are trusted differently in different contexts is not easily measurable. I do find the argument you made more persuasive when a user identifies themself (through login or some other method), but it seems like Tor Browser will not always fully protect its user, no matter what isolation is implemented because the web of third-party-includes is such a tangled mess. Most likely the only safe way to use sites at different security levels is through separating the connections by using New Identity, as you mentioned earlier. [2] Worse, in many cases the publisher has no direct relationship with the offending third-party script. In Part 2 of our study we examined two third-party scripts which exploit a vulnerability in browsers’ built-in password managers to exfiltrate user identities. One web developer was unable to determine how the script was loaded and asked us for help. We pointed out that their site loaded an ad network (media-clic.com), which in turn loaded “themoneytizer.com”, which finally loaded the offending script from Audience Insights. These chains of redirects are ubiquitous on the web, and might involve half a dozen third parties. On some websites the majority of third parties have no direct relationship with the publisher.
participants (7)
-
Arthur D. Edelstein -
David Fifield -
Georg Koppen -
Mark Smith -
Matthew Finkel -
teor -
Tom Ritter