Re: [tor-dev] Rethinking Bad Exit Defences: Highlighting insecure and sensitive content in Tor Browser

[Tom Ritter <tom@xxxxxxxxx>]

It seems reasonable but my first question is the UI. Do you have a
proposal?  The password field UI works, in my opinion, because it
shows up when the password field is focused on. Assuming one uses the
mouse to click on it (and doesn't tab to it from the username) - they
see it.

How would you communicate this for .onion links or bitcoin text? These
fields are static text and would not be interacted with in the same
way as a password field.

A link could indeed be clicked - so that's a hook for UX... A bitcoin
address would probably be highlighted for copying so that's another
hook... But what should it do?

-tom


On 28 March 2017 at 10:31, Donncha O'Cearbhaill <donncha@xxxxxxxxxx> wrote:
> Hi all,
>
> The Tor bad-relay team regularly detects malicious exit relays which are
> actively manipulating Tor traffic. These attackers appear financial
> motivated and have primarily been observed modifying Bitcoin and onion
> address which are displayed on non-HTTPS web pages.
>
> Increasingly these attackers are becoming more selective in their
> targeting. Some attackers are only targeting a handful of pre-configured
> pages. As a result, we often rely on Tor users to report bad exits and
> the URLs which are being targeted.
>
> In Firefox 51, Mozilla started to highlight HTTP pages containing
> password form fields as insecure [1]. This UI clearly and directly
> highlights the risk involved in communicating sensitive data over HTTP.
>
> I'd like to investigate ways that we can extend a similar UI to Tor
> Browser which highlight Bitcoin and onion addressed served over HTTP. I
> understand that implementing this type of Bitcoin and onion address
> detection would be less reliable than Firefox's password field
> detection. However even if unreliable it could increase safety and
> increase user awareness about the risks of non-secure transports.
>
> There is certainly significant design work that needs to be done to
> implement this feature. For example, .onion origins need be treated as
> secure, but only if they don't included resources from non-secure
> origins. We would also need to make the onion/bitcoin address detection
> reliable against active obfuscation attempts by malicious exits.
>
> I'd like to hear any and all feedback, suggestions or criticism of this
> proposal.
>
> Kind Regards,
> Donncha
>
>
> [1]
> https://blog.mozilla.org/security/2017/01/20/communicating-the-dangers-of-non-secure-http/
>
>
>
> _______________________________________________
> tor-dev mailing list
> tor-dev@xxxxxxxxxxxxxxxxxxxx
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
>
_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev