[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:
                                                 |  assigned
 Priority:  Medium                               |      Milestone:
Component:  Applications/Tor Browser             |        Version:
 Severity:  Normal                               |     Resolution:
 Keywords:  ux-team, tor-hs, network-team-       |  Actual Points:  2.5
  roadmap-november, TorBrowserTeam201911,        |
  tbb-9.5                                        |
Parent ID:  #30024                               |         Points:  6
 Reviewer:                                       |        Sponsor:
                                                 |  Sponsor27-must
-------------------------------------------------+-------------------------

Comment (by acat):

 Some update, see `21952+1.webm` attachment. This is based on branch
 https://github.com/acatarineu/tor-browser/commits/21952+1. Will do some
 alpha builds and add them later.

 Now automatic `Onion-Location` redirects are working, and should behave
 similarly as 30X + Location ones (history not modified, etc.). These are
 controlled via a pref in `about:preferences`, which by default is set as
 `Ask everytime`. I reused the same `.onion available` badge to show some
 visual feedback when redirect has happened (`.onion redirected`), and a
 popup that shows the original URL where the redirect started. I did not
 style this popup, as I assume it's just a temporal thing and the final
 redirect visual feedback (if there is) will probably be different.

 Some technical points that will have to address in a subsequent iteration.
 First, I'm using `originalURI` of the `nsIHttpChannel` to detect whether
 there was a redirect. This has two problems: first, if there is a redirect
 chain like `http -> https -> .onion` the originalURI will be the first
 one, and we probably want to display just the previous one to the
 `.onion`. The second problem is that we cannot distinguish redirects with
 `30X` code + `Location` header from redirects done because of `Onion-
 Location`. So if a website did a regular redirect to `.onion`, we would be
 showing the same visual feedback as with `Onion-Location`. I'm not sure if
 the latter is that big of a problem (depends on what we want to do in this
 case), but the first problem will probably need to be solved.

 I also need to check if there is a simpler (or safer) implementation than
 the one I did for the redirects. I modified `nsHttpChannel.cpp` to do a
 redirect to `Onion-Location` if the pref is `true` (for automatic
 redirects) or the channel has a flag set (for manual/temp redirects). I
 wonder if it would be better/possible to move the redirect logic to `JS`
 service, listening for `http-on-examine-response` and using the
 `channel.redirectTo` JS API if needed. I think if possible it would be
 better to avoid doing too many changes in internal http C++ code.

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