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

Comment (by sysrqb):

 Replying to [comment:99 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.

 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 prefer we explicitly define which conditions cause a redirect verses
 cause the badge UI. A response with code `308` and `Onion-Location` is
 saying "This resource is not at the URL you requested anymore, please load
 it from this onion location, but only if the user chooses to use the new
 location (onion address). Meanwhile, please enjoy the page I just was
 permanently moved", right?

 >
 > The problem I see is when there would be no need to redirect
 [snip]
 >
 > 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.

 Yeah, I think we are experiencing some scope-creep here :) But maybe this
 is okay. We should resolve any confusion or ambiguity for how this should
 be used and the expected behavior before we merge this.

 > Replying to [ticket:21952 linda]:
 >>  ilf is experimenting with automatically redirecting Tor users to
 .onion versions of websites that they visit (because they want more people
 to visit onion sites and they will do so if it is painless to them). But
 when users were redirected automatically to an onion site, they freaked
 out about it because they didn't know what happened, didn't know what
 onion sites were, and the "https" was dropped.

 The original idea was only intended as an alternative for simply and
 forcefully redirecting all users to an onion address (based on exit node
 IP address). Making this opt-in may make this less scary and an
 "educational experience". My understanding is this directly changes the
 behavior of `307`and `308`, but I am concerned this is not the best
 behavior.

 >
 > 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.

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