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.
- 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.
- 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.
- 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]