[tor-bugs] #21952 [User Experience]: Increasing the use of onion services through automatic redirects and aliasing

[Tor Bug Tracker & Wiki]

#21952: Increasing the use of onion services through automatic redirects and
aliasing
-----------------------------+-----------------------
 Reporter:  linda            |          Owner:  linda
     Type:  enhancement      |         Status:  new
 Priority:  Medium           |      Milestone:
Component:  User Experience  |        Version:
 Severity:  Normal           |     Resolution:
 Keywords:                   |  Actual Points:
Parent ID:                   |         Points:
 Reviewer:                   |        Sponsor:
-----------------------------+-----------------------

Comment (by arma):

 Three thoughts:

 A) If I'm using onion *and* https, I want some visual way to learn that.
 That's because an https cert for an onion site, especially if it's an EV
 cert, probably means that I can be more assured that I'm really on the
 site I meant to be on. In particular, if you replace the https lock icon
 with the onion one, then it could be harder for me to know whether I have
 the https layer too.

 B) I think the UX part might need to depend on how exactly we're choosing
 to do the redirects. Do we have a local database, a la httpseverywhere,
 that has a mapping for us? And when we type in foo.com, it auto rewrites
 it to foo.onion? In that case, I think it is a really compelling idea to
 have the browser tab display "foo.com" for us when we're at the site that
 it "knows" is foo.onion. We could even do that swap if the user went
 directly to foo.onion, since we can look it up to see that we should
 display foo.com. But in this case, we should also have a good plan for how
 to handle the case where the user is on an onion address that isn't in our
 rewrite table. I guess we put the cool blue onion label in the url tab,
 but leave the address alone (as xyz.onion)? Does that create a world where
 we have first tier onions and second tier onions, and users learn to
 mistrust second tier onions? Is that a feature or a bug?

 Shipping such a table with Tor Browser means more centralization of the
 naming system. Especially if users trust sites in the table more than
 sites not in the table, we're going to see pressure from various folks to
 get their onion address added to the list. Do we add the particular
 sketchy sites, or do we opt not to, effectively censoring them? How about
 when some government agency comes to us asking us to remove one of the
 entries?

 Maybe there are other approaches to helping users do the rewrite that
 don't suffer from the centralization / central point of intervention
 issues above. See e.g. the proposals for having CAs include both foo.com
 and an altname of foo.onion in the same https cert, to effectively bind
 the names together.

 C) The browser has a bunch of built-in defenses, under the broad term
 "cross site something", which aim to provide isolation of cookies,
 javascript, etc between domains. These defenses are often keyed off of
 what's written in the url bar. So we should have some smart browser people
 think through whether we would be undermining these defenses with this
 change. (Alternatively, maybe we can get away with not changing what the
 browser thinks is in the url bar, but just changing how it's displayed to
 the user.)

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/21952#comment:4>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online