[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #21952 [Applications/Tor Browser]: Onion-location: increasing the use of onion services through automatic redirects and aliasing
#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
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs