[tor-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):

 Replying to [comment:98 pospeselr]:
 > acat: Ah, I missed the final 'are we already on an onion' check in that
 if. Though that does lead to another question. What is the correct
 behavior if foo.onion sends Onion-Location: bar.onion?

 Sorry for the late reply, I had missed this question. If a .onion site
 wants to redirect to a different .onion it can always use a regular
 `Location` redirect instead of `Onion-Location`, so I think it should be
 fine to ignore `Onion-Location` headers if we are already in a .onion
 site.

 ----

 Replying to [comment:101 sysrqb]:
 > Maybe we should specify that `Onion-Location` should only be used with
 `300 Multiple Choices`? If a server sends `301 Moved Permanently`, `307
 Temporary Redirect`, or `308 Permanent Redirect`, then that seems like it
 implies the user-agent should redirect to the provided location without
 user intervention.

 I was not aware of the `300 Multiple Choices`, I think that's probably the
 option that would respect the standards most, if we are going to use 30X
 redirects. However, I still think that serving different response codes
 for Tor Browser users can be problematic from the server point of view. If
 I'm not wrong, (for all detected Tor Browsers users) the server would need
 to either:

 * Serve the full site (all subpages) with `300` response code + `Onion-
 Location` header (I mean with the actual page body and without `Location`
 header).

 * Offer three distinct URLs for each resource in the site:
   1. One non-onion URL which we would **never** respond to with a `Onion-
 Location` redirect (e.g. https://www.facebook.com/?noonionlocation=1)
   2. The .onion one. (e.g. https://www.facebookcorewwwi.onion/)
   3. The well-known non-onion one, for which we would return `300 Multiple
 Choices` with `Location` equal to URL number 1, and `Onion-Location` equal
 to URL number 2 (e.g. https://www.facebook.com/)

 Otherwise, I don't see a way how the server is able to know when it has to
 send a `300 Onion-Location` redirect and when it doesn't. For either
 solution, the server could always limit it to the just top-level page,
 which would make it less costly, I guess.
 \\
 >Thinking about adoption, also note that the current implementation
 (ignoring response code) could allow achieving the same via a <meta http-
 equiv="onion-location" content="http://some.onion"> HTML tag, in case
 adding headers is more difficult for website owners than adding meta tags
 in the page content.
 >
 >>This is a neat idea.

 Perhaps this would make it closer to the semantics of "Refresh" header
 instead of "Location" (see https://www.w3.org/TR/WCAG20-TECHS/H76.html).
 More specifically a Refresh with a 0 timeout:
 `Refresh="0;URL='http://some.onion/whatever'"`. If we would follow this,
 with onion auto-redirects enabled we could internally treat "Onion-
 Location" (or "Onion-Refresh"?) as a "Refresh=0;URL=..." which takes
 precedence over regular Refresh headers, and if auto-redirects are off we
 would just not treat it as a Refresh and display the .onion available UI
 instead.

 For us, we could argue that we follow the semantics of a "Refresh=0;URL"
 header (when auto-redirect is enabled), and this might be easier than
 trying to get the "right" behaviour with 30X redirects. For the servers
 implementing this, I think it would be simpler not having to care about
 redirect response codes: they would be able to serve the regular page
 alongside the header (or <meta> attribute), which would be displayed
 normally if onion auto-redirects were off. Another advantage I already
 mentioned: it would give more freedom for the implementer, as it would be
 possible to choose between serving a header or a <meta http-equiv>
 depending on what's easier. And this one is out of scope, but maybe using
 a <meta> attribute might be more friendly for some search engine
 crawlers/robot able to add the .onion alternative to their index?

 In any case, I'll (finally) contact will shackleton for some feedback on
 this, and what could be implemented in Facebook, what not, and possibly
 some alternatives.

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