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

Trac:

Ok, once again implemented as a fixup commit on 7d3475febd37ae2b35432105f5e4c0da30852bc6. We needed to add the Onion+Slash icon for Onion firstparty and HTTP active content (javascript). I also simplified things a bit as there is no reason to have special logic or css rules for self-signed onion sites.

---

This patch alone is not sufficient for all scenarios.

We need to rework when the user-override screen comes up, as currently self-signed HTTPS onionsites and HTTPS onionsites with unknown certificate authorities will pop a warning page that the user has to manually click through (basically the behaviour on the clearnet for these pages: https://self-signed.badssl.com/ and https://untrusted-root.badssl.com/ ). I'm intending to fix this problem in a separate patch for #13410 (moved).

HTTP Onion sites with clearnet HTTP forms do not currently trigger a popup warning on form submission (see clearnet version here: https://mixed-form.badssl.com/ ). It seems firefox only does this on HTTPS pages so we need to make it so it does this on HTTP onionsites as well. I'll file a new bug ( #33298 (moved) ) for this issue and parent it to #30005 (moved).

I'm currently testing this patch with the following onionsite scenarios and all is working as expected apart from the previously mentioned issues:

• HTTP Onion
• HTTPS Onion Self-Signed
• HTTPS Onion Unknown CA
• HTTPS Onion EV
• HTTPS Onion Wrong Domain
• HTTP(S) Onion + HTTP Script
• HTTP(S) Onion + HTTP Content
• HTTP(S) Onion + HTTPS Content
• HTTP(S) Onion + HTTP Form

If you can think of any weird scenarios I nee to think about do let me know!

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

Trac:
Status: assigned to needs_review

Trac:
Actualpoints: N/A to 3

Trac:
Reviewer: N/A to mcs

r=brade,r=mcs The patch looks good, although we did not take time to set up and test all of the scenarios. It would be great to have a permanent test bed / set of servers for this stuff. It looks like someone already registered badonion.com though :)

Sorry, had to update this. Had a typo in a refactor I missed (was overwriting the entire _identityBox, rather than _identityBox.className). Pushed over the old branch (still a fixup commit).

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

It would be great to have a permanent test bed / set of servers for this stuff

+1. What do we need?

Trac:
Cc: N/A to tbb-team

Replying to antonela:

It would be great to have a permanent test bed / set of servers for this stuff

+1. What do we need?

That is a good question. I guess we need .onion servers and regular http/https servers and some test pages that cover the scenarios mentioned in comment:14. But it might be a lot of work to migrate what Richard set up for his own testing into something that all of us can use.

Replying to pospeselr:

Sorry, had to update this. Had a typo in a refactor I missed (was overwriting the entire _identityBox, rather than _identityBox.className). Pushed over the old branch (still a fixup commit).

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

r=brade,r=mcs I guess we should have caught that error. Also, life is easier for reviewers when you create a new branch rather than force-pushing over an older one ;)

Sorry about that mcs, will keep that in mind.

Unfortunatley looks like there will be another revision on this. Gave antonela a test build and she spotted some problems.

fixup! commit over my bug_32645_v2 branch with tweaked icons

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

antonela: working on a test build for you with #13410 (moved) and this patch together hopefully will have it to you later today

Trac:
Actualpoints: 3 to 3.25

We are no longer in February moving reviews

Trac:
Keywords: TorBrowserTeam202002R deleted, TorBrowserTeam202003R added

Replying to pospeselr:

fixup! commit over my bug_32645_v2 branch with tweaked icons

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

r=brade,r=mcs Looks good to us.

Replying to mcs:

Replying to pospeselr:

fixup! commit over my bug_32645_v2 branch with tweaked icons

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

r=brade,r=mcs Looks good to us.

I squashed the two commits, and pushed that to branch tor-browser-68.5.0esr-9.5-1 as commit 03101bba2cf4a694deec0b7b040d8141f8c7cf20.

Trac:
Resolution: N/A to fixed
Status: needs_review to closed

Trac:

Trac:

Trac:

Each of the following scenario assumes we're talking about an onion domain. Vanilla internet HTTP/HTTPS icons are the same as in vanilla Firefox.

I have a test onion service that exercises all these scenarios.

= Scenario =	= Icon =	= Vanilla Example =	= Notes =
HTTP		http://http.badssl.com/
HTTPS Self-Signed		https://self-signed.badssl.com/
HTTPS		https://sha256.badssl.com/
HTTPS Unknown CA		https://untrusted-root.badssl.com/
HTTPS EV		https://extended-validation.badssl.com/
HTTPS Wrong Domain		https://wrong.host.badssl.com/
Mixed Script		https://mixed-script.badssl.com/	Must enable the mixed script from url bar
Mixed Content		https://very.badssl.com/
Mixed HTTPS Content		n/a
HTTP Form		https://mixed-form.badssl.com/	Warning popup in form
Onion HTTP Form		n/a
HTTPS Expired		https://expired.badssl.com/

Thanks, pospeselr!

closed

added 26h of time spent

mentioned in issue #33517 (moved)

mentioned in issue #30025 (moved)

mentioned in issue tpo/web/trac#33517 (moved)

moved to tpo/applications/tor-browser#32645 (closed)

mentioned in issue tpo/web/manual#76 (closed)