#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, network-team- | roadmap-2020Q1, TorBrowserTeam202002R | Parent ID: #30024 | Points: 6 Reviewer: pospeselr, mcs, brade | Sponsor: | Sponsor27-must -------------------------------------------------+-------------------------
Comment (by acat): Replying to [comment:98 pospeselr]: > acat: Ah, I missed the final 'are we already on an onion' check in that if. Though that does lead to another question. What is the correct behavior if foo.onion sends Onion-Location: bar.onion? Sorry for the late reply, I had missed this question. If a .onion site wants to redirect to a different .onion it can always use a regular `Location` redirect instead of `Onion-Location`, so I think it should be fine to ignore `Onion-Location` headers if we are already in a .onion site. ---- Replying to [comment:101 sysrqb]: > 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 was not aware of the `300 Multiple Choices`, I think that's probably the option that would respect the standards most, if we are going to use 30X redirects. However, I still think that serving different response codes for Tor Browser users can be problematic from the server point of view. If I'm not wrong, (for all detected Tor Browsers users) the server would need to either: * Serve the full site (all subpages) with `300` response code + `Onion- Location` header (I mean with the actual page body and without `Location` header). * Offer three distinct URLs for each resource in the site: 1. One non-onion URL which we would **never** respond to with a `Onion- Location` redirect (e.g. https://www.facebook.com/?noonionlocation=1) 2. The .onion one. (e.g. https://www.facebookcorewwwi.onion/) 3. The well-known non-onion one, for which we would return `300 Multiple Choices` with `Location` equal to URL number 1, and `Onion-Location` equal to URL number 2 (e.g. https://www.facebook.com/) Otherwise, I don't see a way how the server is able to know when it has to send a `300 Onion-Location` redirect and when it doesn't. For either solution, the server could always limit it to the just top-level page, which would make it less costly, I guess. \\ >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. Perhaps this would make it closer to the semantics of "Refresh" header instead of "Location" (see https://www.w3.org/TR/WCAG20-TECHS/H76.html). More specifically a Refresh with a 0 timeout: `Refresh="0;URL='http://some.onion/whatever'"`. If we would follow this, with onion auto-redirects enabled we could internally treat "Onion- Location" (or "Onion-Refresh"?) as a "Refresh=0;URL=..." which takes precedence over regular Refresh headers, and if auto-redirects are off we would just not treat it as a Refresh and display the .onion available UI instead. For us, we could argue that we follow the semantics of a "Refresh=0;URL" header (when auto-redirect is enabled), and this might be easier than trying to get the "right" behaviour with 30X redirects. For the servers implementing this, I think it would be simpler not having to care about redirect response codes: they would be able to serve the regular page alongside the header (or <meta> attribute), which would be displayed normally if onion auto-redirects were off. Another advantage I already mentioned: it would give more freedom for the implementer, as it would be possible to choose between serving a header or a <meta http-equiv> depending on what's easier. And this one is out of scope, but maybe using a <meta> attribute might be more friendly for some search engine crawlers/robot able to add the .onion alternative to their index? In any case, I'll (finally) contact will shackleton for some feedback on this, and what could be implemented in Facebook, what not, and possibly some alternatives. -- Ticket URL: <https://trac.torproject.org/projects/tor/ticket/21952#comment:103> Tor Bug Tracker & Wiki <https://trac.torproject.org/> The Tor Project: anonymity online
_______________________________________________ tor-bugs mailing list tor-bugs@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs