Display .onion alt-svc route in the circuit display

Now that #24553 (moved) has re-enabled alt-svc, the Circuit Display should probably indicate when the connection was made via an .onion alt-svc. Currently it doesn't.

Feel free to use this for testing: https://perfectoid.space/test.php When the page turns green, click on the green https lock to see the circuit.

Trac:
Username: mahrud

added TorBrowserTeam202008 component::applications/tor browser owner::tbb-team priority::medium reporter::mahrud severity::normal sponsor::27-must status::assigned tbb-circuit-display type::defect ux-team labels

Trac:
Username: mahrud

Current behavior

Trac:
Username: mahrud

Trac:
Keywords: N/A deleted, tbb-circuit-display added

I'm not sure if that should be a separate ticket but I would find it important to see that the page has been fetched via .onions directly from the URL bar without having to expand anything.

What do you think about using the onion-behind-a-lock icon for pages that are fetched via .onion (due to Alt-Svc)?

The trouble is that the connection is not consistently via .onion, only opportunistically. And besides, displaying one of the 10 .onions that, say, Cloudflare owns is kinda pointless.

Trac:
Username: mahrud

Replying to gk: Hey, gk! This ticket is primarily not about circuit display, but

What do you think about using the onion-behind-a-lock icon for pages that are fetched via .onion (due to Alt-Svc)? and even more correct: Why the hell doesn't it inform about using plain text .onion connections on https sites?!!! (No questions for https .onion alternate routes.) Example of cf alt-svc: cflarexljc3rw355ysrkrzwapozws6nre6xsy3n4yrj7taye3uiby3ad.onion:443 (plain text (http)!!!)

Trac:
Username: fuckingcf

So, here is an interesting issue: If you load the website the first time the circuit display actually shows part of the onion circuit (the one the client controls) but the website still says that the content got loaded over the regular Tor circuit. This is true. What happens is that a second request is issued for the favicon which uses the onion in the alt-svc header which then updates the circuit display even though the content did not get loaded over the .onion. What should the display show here?

#27949 (moved) is a duplicate.

Trac:
Cc: arthuredelstein to arthuredelstein, nicoo

#28033 (moved) is a duplicate.

Trac:
Cc: arthuredelstein, nicoo to arthuredelstein, nicoo, notifier

Trac:
Keywords: N/A deleted, ux-team added

Trac:
Sponsor: N/A to Sponsor27

Add Sponsor27-must items for Objective 2

Trac:
Sponsor: Sponsor27 to Sponsor27-must

Leaving https://www.deepdotweb.com/ as an interesting example here. To make things more complicated: there are different Cf alt-svc involved it seems while it is not clear how much traffic they actually carry (in addition to the non-.onion one).

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

Replying to gk:

So, here is an interesting issue: If you load the website the first time the circuit display actually shows part of the onion circuit (the one the client controls) but the website still says that the content got loaded over the regular Tor circuit. This is true. What happens is that a second request is issued for the favicon which uses the onion in the alt-svc header which then updates the circuit display even though the content did not get loaded over the .onion. What should the display show here?

The favicon explanation/idea was actually a red herring. What we see is actually a circuit display issue (which we should deal with, though) in the sense that it does not show any alt-svc routing requests at all using the Cloudflare .onion service but rather an orthogonal one. This happens because once the Alt-Svc response header is processed the mapping is created and part of that is validating it (see: AltSvcCache::UpdateAltServiceMapping) which means in the https:// case just establishing a connection to the alt-svc host. And the circuit display gets in turn updated with the client side rend circuit caused by that validation request. There is no actual content sent back and forth here as it takes the non-alt-svc route.

Is #32777 (moved) a duplicate?

Same with #33525 (moved), is this one also related?

We will follow the same logic as we are using for the https-e .tor.onion naming UI:

1. user types the regular domain
2. user is "transparently" redirected to the alt-svc .onion
3. the onion icon appears in the url bar
4. the circuit display gets updated to show .onion address

In this case the circuit display will show the .onion address and the url bar will show the human memorable/meaningful name.

Trac:
Keywords: N/A deleted, TorBrowserTeam202004 added
Owner: tbb-team to acat
Cc: arthuredelstein, nicoo, notifier to arthuredelstein, nicoo, notifier, antonela
Status: new to assigned

Unparenting for now. We will no longer work on this as part of S27 O2A3

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

Trac:
Keywords: TorBrowserTeam202004 deleted, TorBrowserTeam202008 added

Trac:
Owner: acat to tbb-team

mentioned in issue #27820 (moved)

mentioned in issue #27949 (moved)

mentioned in issue #28033 (moved)

mentioned in issue #30024 (moved)

mentioned in issue #30599 (moved)

mentioned in issue #32777 (moved)

mentioned in issue #33525 (moved)

mentioned in issue tpo/web/trac#27820 (closed)

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