Georg Koppen <g...@torproject.org> writes: > [ text/plain ] > George Kadianakis: >> As discussed in this mailing list and in IRC, I'm posting a subsequent >> version of this proposal. Basic improvements: >> - Uses a new custom HTTP header, instead of Alt-Svc or Location. >> - Does not do auto-redirect; it instead suggests the onion based on >> antonella's mockup: >> https://trac.torproject.org/projects/tor/attachment/ticket/21952/21952.png > > I don't see that or any particular idea of informing the user in the > proposal itself, though. I think more about those browser side plans > should be specified in it (probably in section 2). Right now you are > quite specific about the redirection part and its pro and cons but > rather vague on the actual UX improvements (having the header is just > half of what you need). >
Hello, pushed another commit to the onion-location branch in my repo for addressing the concerns in GeKo's email: https://gitweb.torproject.org/user/asn/torspec.git/commit/?h=onion-location&id=14fc750e3afcd759f4235ab955535a07eed24286 I was not sure what other stuff to put in section 2 but please let me know if you don't feel fullfiled with the current ones!!! Also, I wiped out the improvements section because i was not sure what to put there. As a side thing, I found this extension which does the bottombar part of this proposal, but it gets the redirection list from a local file instead of an HTTP header: https://github.com/Someguy123/HiddenEverywhere Cheers! >> >> >> ======================================================================== >> UX improvement proposal: Onion redirects using Onion-Location HTTP header >> ======================================================================== >> >> 1. Motivation: >> >> Lots of high-profile websites have onion addresses these days (e.g. Tor , > > Tor, > >> NYT, blockchain, ProPublica). All those websites seem confused on what's >> the right way to inform their users about their onion addresses. Here are >> some confusion examples: >> a) torproject.org does not even advertise their onion address to Tor >> users (!!!) >> b) blockchain.info throws an ugly ASCII page to Tor users mentioning >> their onion >> address and completely wrecking the UX (loses URL params, etc.) >> c) ProPublica has a "Browse via Tor" section which redirects to the >> onion site. >> >> Ideally there would be a consistent way for websites to inform their users >> about their onion counterpart. This would provide the following positives: >> + Tor users would use onions more often. That's important for user >> education and user perception, and also to partially dispell the >> darkweb myth. >> + Website operators wouldn't have to come up with ad-hoc ways to >> advertise >> their onion services, which sometimes results in complete breakage of >> the user experience (particularly with blockchain) >> >> This proposal specifies a simple way forward here that's far from perfect, >> but can still provide benefits and also improve user-education around >> onions >> so that in the future we could employ more advanced techniques. >> >> Also see Tor ticket #21952 for more discussion on this: >> https://trac.torproject.org/projects/tor/ticket/21952 >> >> 2. Proposal >> >> We introduce a new HTTP header called "Onion-Location" with the exact same >> restrictions and semantics as the Location HTTP header. Websites can use >> the >> Onion-Location HTTP header to specify their onion counterpart, in the same >> way that they would use the Location header. >> >> The Tor Browser intercepts the Onion-Location header (if any) and informs >> the user of the existense of the onion site, giving them the option to >> visit > > s/existense/existence/ > >> it. Tor Browser only does so if the header is served over HTTPS. >> >> Browsers that don't support Tor SHOULD ignore the Onion-Location header. >> >> 3. Improvements > > Did you plan to write anything here? I guess there are at least UX > improvements to the ad-hoc things you mentioned at the beginning of the > proposal. > >> 4. Drawbacks >> >> 4.1. No security/performance benefits >> >> While we could come up with onion redirection proposals that provide >> security and performance benefits, this proposal does not actually provide >> any of those. >> >> As a matter of fact, the security remains the same as connecting to normal >> websites (since we trust its HTTP headers), and the performance gets worse > > s/its/their/ > >> since we first need to connect to the website, get its headers, and then >> also connect to the onion. >> >> Still _all_ the website approaches mentioned in the "Motivation" section >> suffer from the above drawbacks, and sysadmins still come up with ad-hoc >> ways to inform users abou their onions. So this simple proposal will still > > s/abou/about/ > >> help those websites and also pave the way forward for future auto-redirect >> techniques. >> >> 4.2. Defining new HTTP headers is not the best idea >> >> This proposal defines a new non-standard HTTP header. This is not great >> because it makes Tor into a "special" thing that needs to be supported >> with >> special headers. However, the fact that it's a new HTTP header that only >> works for Tor is a positive thing since it means that non-Tor browsers >> will >> just ignore it. >> >> Furthermore, another drawback is that this HTTP header will increase the >> bandwidth needlessly if it's also served to non-Tor clients. Hence >> websites >> with lots of client traffic are encouraged to use tools that detect Tor >> users and only serve the header to them (e.g. tordnsel). >> >> 5. The future >> >> As previously discussed, this is just a simple proposal to introduce the >> redirection concept to people, and also to help some sysadmins who are >> currently coming up with weird ways to inform people about their >> onions. It's not the best way to do this, but it's definitely one of the >> simplest ways. >> >> In the future we could implement with more advanced auto-redirect >> proposals like: > > s/with// maybe? > > [snip] > > Georg > > [ signature.asc: application/pgp-signature ] > [ text/plain ] > _______________________________________________ > tor-dev mailing list > tor-dev@lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev _______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev