[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:
| 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
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs