[tor-dev] Rethinking Bad Exit Defences: Highlighting insecure and sensitive content in Tor Browser
dgoulet at ev0ke.net
Mon Apr 3 13:05:51 UTC 2017
On 28 Mar (11:19:45), Tom Ritter wrote:
> 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?
I do believe this could be an important safety improvement even if not
perfect. I'm unsure how Tor Browser team operates for this kind of features
but Tom's request here is a logical start that is try to come up with a
proposal of what the UI would look like and then we can go in ticket land I
I'm no UI expert nor even good at judging them but I have a feeling we should
go towards something "intrusive" in order to make SURE users notice the
potential danger and actually gets annoyed by it to the point they want to
*avoid* HTTP sites in order to not deal with that.
nusenu idea of going like NoScript does is appealing to me. Covering the
.onion/bitcoin address on HTTP clearnet site and then you have to click on it
to see it with a big ass warning saying "Make sure you understand that this
address could have been changed in transit" kind of thing (with very low
technical terms ofc).
That way, users will clearly see that getting an address on an HTTP site is
_harmful_ over Tor and that should be what we convey to the users using that
Might sound kind of radical here but safety first! I really don't see a
compromise nor an argument for "usability" here if we believe that it's
> On 28 March 2017 at 10:31, Donncha O'Cearbhaill <donncha at donncha.is> 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 . 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
> > 
> > https://blog.mozilla.org/security/2017/01/20/communicating-the-dangers-of-non-secure-http/
> > _______________________________________________
> > tor-dev mailing list
> > tor-dev at lists.torproject.org
> > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
> tor-dev mailing list
> tor-dev at lists.torproject.org
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 585 bytes
Desc: not available
More information about the tor-dev