Update URL bar onion indicators

Since FF70, the green locks at the URL bar are gone. The current Firefox approach to security indicators is detailed here[1]. Chrome is leading towards this intention, too[2].

As part of S27, I'm working on unifying (and simplifying) the brand presence of onions in Tor Browser, either for referring to the network or to the onion services.

I'm opening this ticket to discuss the following:

• are we ok following the Firefox approach and removing green icons from the URL bar?
• are we ok unifying the visual anchor for onions and onion routing at the URL bar and also at the circuit display?
• are we ok removing EV label from the URL bar and leave it at the identity doorhanger?

[1]FF70 https://blog.mozilla.org/security/2019/10/15/improved-security-and-privacy-indicators-in-firefox-70/ [2]CH69 https://blog.chromium.org/2018/05/evolving-chromes-security-indicators.html [*]TB8 https://trac.torproject.org/projects/tor/wiki/org/teams/UxTeam/Misc/OnionSecurityIndicator

Trac:
Parent Ticket: #30025 (moved)

added TorBrowserTeam202003R actualpoints::3.25 component::applications/tor browser owner::pospeselr parent::30025 priority::medium resolution::fixed reviewer::mcs severity::normal sponsor::27-must status::closed type::defect ux-team labels

I'm going to parent this ticket with O2A4 because is the closest one.

Trac:
Parent: N/A to #30025 (moved)

First approach 

are we ok removing EV label from the URL bar and leave it at the identity doorhanger?

EV certificates on .onion's are reasonably rare and a good indication one has got to the 'right' .onion (especially as we find more people embracing v3 .onions).

Would we be open to retaining the EV label for .onion but following the mainstream browsers and removing it for all other TLDs?

Trac:
Username: AblativeHosting

So having read the above documents and playing around with what browsers are doing these days, I have some thoughts.

With Firefox and Chrome not giving a visual indication of DV/EV certs I think we should follow suit. As such, I think the Onion + CA Issued DV/EV Cert should just drop the lock icon, and just show the Onion icon.

For mixed content Firefox uses the HTTPS lock icon with a red slash through it, while chromium based browsers don't have an icon but instead red 'Not Secure' text in the address bar. By default it looks like Firefox blocks HTTP content from HTTPS pages and has to be explicitly loaded by the user via the (I) icon drop-down so most users wouldn't even see this.

If we're going to have a separate Onion icon for onion URLs, perhaps we should follow Firefox here and do a Onion with a red slash.

---

Though that said, what is the purpose of communicating to the user that they are using an onion service? Firefox is using the lock there to indicate that your connection is secure, while Chromium et al are going further and using the space to explicitly indicate when a connection is not secure.

I'm kind of inclined to agree with the idea behind this trend being that the more information we try to cram up there, the less useful it is and the more probable it is that important info is ignored. I'd actually really like to see Firefox go the route Chromium is and explicitly put in a flashing red Not secure label on unencrypted HTTP sites.

---

Ok, on to the hanger. I think the Onion service should probably keep the lock icon for 'Connection Secure with Tor'. Using the same icon in two separate sections is a bit weird.

teor and arma mention in #23875 (moved) that there isn't a way to determine how many relays there are after your half of the circuit to a hidden service, so rather than hard-coding 3 'Relay' we need something else. I'm partial to arma's suggestion of having a nebulous 'cloudy' thing there.

We should also try and pick a themed color for the 'New Circuit for this Site' button, rather than the hard-coded blue we currently use. With the built-in Dark theme it doesn't look the best.

Trac:
Sponsor: Sponsor27 to Sponsor27-must

Replying to pospeselr:

For mixed content Firefox uses the HTTPS lock icon with a red slash through it, while chromium based browsers don't have an icon but instead red 'Not Secure' text in the address bar.

I'm not seeing that. The grey padlock with a red slash is for insecure (1st party) pages - e.g http://example.com

Mixed content: Firefox only blocks insecure active content, not passive (by default)

• security.mixed_content.block_active_content = true
• security.mixed_content.block_display_content = false

For example, using https://www.bennish.net/mixed-content.html - FF default (insecure active mixed content) displays a grey padlock with a yellow warning (triangle) overlay

If passive content is also blocked, then

• FF70+ just a grey padlock is displayed, also the info icon is gone, merged into the padlock
• ESR68, FF69 - a green padlock

Note: the blocking of subresources has a bug, and the padlock could be misleading: but we're only discussing the UX, so it's immaterial

Replying to pospeselr:

So having read the above documents and playing around with what browsers are doing these days, I have some thoughts.

With Firefox and Chrome not giving a visual indication of DV/EV certs I think we should follow suit. As such, I think the Onion + CA Issued DV/EV Cert should just drop the lock icon, and just show the Onion icon.

Agreed.

For mixed content Firefox uses the HTTPS lock icon with a red slash through it, while chromium based browsers don't have an icon but instead red 'Not Secure' text in the address bar. By default it looks like Firefox blocks HTTP content from HTTPS pages and has to be explicitly loaded by the user via the (I) icon drop-down so most users wouldn't even see this. If we're going to have a separate Onion icon for onion URLs, perhaps we should follow Firefox here and do a Onion with a red slash.

Yes, that is exactly what we have on stable nowadays. I'm attaching here the slashed onion icon and also the Mixed Content scenario; I named it Onion Security Broken.

Though that said, what is the purpose of communicating to the user that they are using an onion service? Firefox is using the lock there to indicate that your connection is secure, while Chromium et al are going further and using the space to explicitly indicate when a connection is not secure.

The entire experience here is to communicate with users when they are using an onion service. It is relevant because it allows us to set up an expectation about how to implement Tor's user-facing features for other vendors.

I'm kind of inclined to agree with the idea behind this trend being that the more information we try to cram up there, the less useful it is and the more probable it is that important info is ignored. I'd actually really like to see Firefox go the route Chromium is and explicitly put in a flashing red Not secure label on unencrypted HTTP sites.

I tend to agree. We can pursue Firefox to have more intense flashing red Not secure. Should we have better overall security warnings in Tor Browser? Do you think this is a feature we might want to upstream? The Firefox team worked with security warnings recently.

Ok, on to the hanger. I think the Onion service should probably keep the lock icon for 'Connection Secure with Tor'. Using the same icon in two separate sections is a bit weird.

Agreed. Having a different icon from the URL bar is weird too. We can solve this same-double-icon situation moving the circuit display to the second level navigation. It will carry other issues (for instance, we may want to inform users about this change). I think that the circuit display is a nice feature for any kind of user in the Tor Browser and maybe it is nice to have it on the first seek.

teor and arma mention in #23875 (moved) that there isn't a way to determine how many relays there are after your half of the circuit to a hidden service, so rather than hard-coding 3 'Relay' we need something else. I'm partial to arma's suggestion of having a nebulous 'cloudy' thing there.

I'd like to explore this idea. We can show the same graph to all kinds of circuits and we could allow users to expand the specific circuit data at a different information level. I filled #### for it.

We should also try and pick a themed color for the 'New Circuit for this Site' button, rather than the hard-coded blue we currently use. With the built-in Dark theme it doesn't look the best.

I'd love to iterate the main circuit display button within this iteration too. I'd follow Firefox approach here and I'd use a wording that reflects better what Tor Browser is doing. What do you think about this? Flush Circuit, Clear Cookies and Site Data... Also, we can offer more info about Guards linking guards to a support.torproject.org/tbb/guard entry.

---

If we are OK, the next step for me is exporting the assets we need for the implementation.

Trac:


Trac:


Trac:

this version is better actually

Trac:

Implemented this as a fixup! commit to the original onion icon ticket ( #23247 (moved) ).

tor-browser: https://gitweb.torproject.org/user/richard/tor-browser.git/commit/?h=bug_32645_v1

edit: I'm building out a debian VM now to test all the various onion site configuration scenarios now.

Trac:
Keywords: N/A deleted, TorBrowserTeam20200131 added
Status: new to needs_review

Trac:
Keywords: TorBrowserTeam20200131 deleted, TorBrowserTeam202001R added

Moving reviews to February

Trac:
Keywords: TorBrowserTeam202001R deleted, TorBrowserTeam202002R added

Trac:
Owner: tbb-team to pospeselr
Status: needs_review to assigned