[tbb-bugs] #21952 [Applications/Tor Browser]: Onion-location: increasing the use of onion services through automatic redirects and aliasing

[Tor Bug Tracker & Wiki]

#21952: Onion-location: increasing the use of onion services through automatic
redirects and aliasing
-------------------------------------------------+-------------------------
 Reporter:  linda                                |          Owner:  acat
     Type:  project                              |         Status:
                                                 |  needs_review
 Priority:  Medium                               |      Milestone:
Component:  Applications/Tor Browser             |        Version:
 Severity:  Normal                               |     Resolution:
 Keywords:  ux-team, tor-hs, network-team-       |  Actual Points:  9
  roadmap-november, tbb-9.5, network-team-       |
  roadmap-2020Q1, TorBrowserTeam202002R          |
Parent ID:  #30024                               |         Points:  6
 Reviewer:  pospeselr, mcs, brade                |        Sponsor:
                                                 |  Sponsor27-must
-------------------------------------------------+-------------------------

Comment (by acat):

 I sent an e-mail about this to Will Shackleton from Facebook, explaining
 the problem we're trying to solve and suggesting three alternatives:

 1. A Onion-Location header which must be sent with a 30X response code.

 2. A Onion-Location header (or similarly named) which can be added
 independently of the response code (and body).

 3. A <meta http-equiv="onion-location" HTML tag.

 Here is the answer:

 ----

 I think 3 is preferable, with some caveats I mention below.

 For 1. I'm not entirely sure how a new 3XX code would be used. If I load
 https://www.facebook.com should the server return 3XX with onion-location
 and then return the full web-page response for FB? How will non-Tor-
 browsers know what to do with this? I think the purpose of 3XX codes is
 "go somewhere else and do nothing but that", so using a 3XX to represent
 an optional redirect seems odd. Is the goal to let the server say "regular
 browsers go to X, onion browsers go to Y"?

 For 2 and 3, I think a meta tag makes more sense for a few reasons:
 a. complex web apps like FB serve a lot of resources. Only a small
 percentage of returned assets are actually web pages, and web pages are
 precisely the things that users sit and look at (ie. are full page loads),
 which are the places where you would want to prompt the user to maybe
 learn about onion services.
 b. there's already a whole load of meta tags like `rel="canonical"` and
 alternative-language versions for saying "here's other URLs for this
 thing" that are scraped by search engines in well-defined ways. Putting
 this in a meta tag I think makes sense if a search engine were to scrape
 this information. It certainly seems more like an optional suggestion to
 the browser compared to an HTTP header, which I think makes a meta tag
 more suitable here.
 c. (this is not how FB does things, but:) lots of websites serve their
 HTTP headers in their load-balancers. The product logic in the web servers
 deals only with HTML, which is likely where the onion equivalent would be
 served.

 In summary, I think the meta tag is much less intrusive and breaks fewer
 layer boundaries in my mind. To me, "here's the onion for this thing" is a
 property of a web-page, not an arbitrary HTTP request which could be a
 POST request, API call, JS file load, video stream, websocket, etc, given
 that this would redirect the whole user experience across to an onion.

 This brings me on to another point: FB currently do not advertise
 facebookcorewwwi to facebook.com users. The reason for this is that our
 general security communication says "if it doesn't say facebook.com,
 you're being hacked!". We tacitly acknowledge that people who know what an
 onion is are smart enough to understand that facebookcorewwwi is the one
 exception to this otherwise global rule.

 If we were to advertise our onion to facebook.com Tor users (we don't have
 plans to do this), we would likely take users through a flow on
 facebook.com where we educate people about the differences and benefits of
 an onion before presenting them with the redirect. Today, we would
 implement this using our existing Tor exit IP detection. Even with the
 presence of things like onion-location we would likely want to still
 present the user with our own information about onions before we redirect
 them, and we would then issue a regular 302 redirect to the onion.

 Given that we suspect that the majority of Tor users don't know what an
 onion is, it would be great if Tor Browser could tell servers (a) "this
 user is using a browser that supports onion services", and also possibly
 (b) "Tor Browser confirms that this user understands onion services and
 understands what they do and don't do". This could be perhaps sent in the
 user-agent header. (a) allows websites like ours to stop scraping Tor exit
 IPs which is unreliable, and (b) would allow a website to show such a flow
 for moving to an onion service only to users who know what one is.
 Finally, this allows us to save some bytes on the wire for our non-Tor
 users by not serving this new header / meta tag to everyone.

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