[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,                     |
  TorBrowserTeam202001R                          |
Parent ID:  #30024                               |         Points:  6
 Reviewer:  pospeselr, mcs, brade                |        Sponsor:
                                                 |  Sponsor27-must
-------------------------------------------------+-------------------------

Comment (by acat):

 Replying to [comment:98 pospeselr]:
 > Regarding servers sending 3XX responses with {{{Onion-Location}}} sans
 {{{Location}}}: I think that the browser should only transparently treat
 {{{Onion-Location}}} as if it were {{{Location}}} if the user has the auto
 onion redirect pref on. If that pref is on, I think we should look for
 {{{Onion-Location}}} first in the case of 3XX redirects and then fallback
 to {{{Location}}}.

 For the cases where there needs to be a redirect in any case, having both
 `Onion-Location` and `Location` in a 30X works fine I think. And the
 priority you suggest looks like the right one.

 The problem I see is when there would be no need to redirect, e.g. the
 request is ok, yet we still want to have the `Onion-Location` header in
 the response to give Tor Browsers the possibility of doing so if the
 conditions are met. For those cases, if we enforce 30X for Onion-Location,
 we could send the `Onion-Location` header without the `Location` one and
 include the page body in the response, as the redirection would be
 optional (usually in 30X responses there is no body). This feels very non-
 standard. An alternative would be to force 30X responses with both `Onion-
 Location` and `Location` headers, even if the redirection was unnecessary.
 I think that would make adoption more difficult, as the server would need
 to have some logic to decide whether to return the 30X redirect, or the
 "real" response. Note that this also has implications on the `.onion
 available` UI, e.g. in the current implementation the button would not be
 shown if the `Onion-Location` header was only present in the redirect
 response.

 So I think making `Onion-Location` (or an equivalent header with a
 different name) behaviour independent of the status code of the response
 is preferable, but I might be missing something.

 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. In principle, `meta http-equiv` should be equivalent
 to setting a http response header, but there is some kind of whitelist of
 allowed headers for this, so it would need to be explicitly
 enabled/implemented in https://searchfox.org/mozilla-
 esr68/rev/1eba6d228a3903f04ea99124343db445c202e4b9/dom/base/Document.cpp#3759.

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