[tbb-dev] Proposal for redesigning the security controls

[Georg Koppen]

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]

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.torproject.org/pipermail/tbb-dev/attachments/20180207/7bc63108/attachment.sig>