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