Re: [tor-dev] UX improvement proposal: Onion auto-redirects using Alt-Svc HTTP header

[Tom Ritter <tom@xxxxxxxxx>]

On 15 November 2017 at 05:35, Alec Muffett <alec.muffett@xxxxxxxxx> wrote:
> Apologies, I am waiting for a train and don't have much bandwidth, so I will
> be brief:
>
> 1) There is no point in issuing <any header of any kind> to anyone unless
> they are accessing <website> via an exit node.
>
> 2) It's inefficient to issue the header upon every web access by every
> person in the world; when the header is only relevant to 1-in-a-few-thousand
> users, you will be imposing extra bandwidth cost upon the remaining
> 99.99...% -- which is unfair to them

Agreed (mostly). I could see use cases where users not accessing a
website via Tor may wish to know an onionsite is available, but they
are also the vast minority.


> 3) Therefore: the header should only be issued to people arriving via an
> exit node.  The means of achieving this are
>
> a) Location
>
> b) Bending Alt-Svc to fit and breaking web standards
>
> c) Creating an entirely new header
>
> 4) Location already works and does the right thing.  Privacy International
> already use this and issue it to people who connect to their .ORG site from
> an Exit Node.
>
> 5) Bending Alt-Svc to fit, is pointless, because Location already works
>
> 6) Creating a new header? Given (4) and (5) above, the only potential
> material benefit of it that I can see would be to "promote Tor branding" -
> and (subjective opinion) this would actually harm the cause of Tor at all
> because it is *special*.
>
> 6 Rationale) The majority the "Dark Net" shade which had been thrown at Tor
> over the past 10 years has pivoted upon "needing special software to
> access", and creating (pardon me) a "special" header to onionify a fetch
> seems to be promoting the weirdness of Tor, again.
>
> The required goal of redirection to the corresponding Onion site does not
> require anything more than a redirect, and - pardon me - but there are
> already 4x different kinds of redirects that are supported by the Location
> header (301, 302, 307, 308) with useful semantics. Why reinvent 4 wheels
> specially for Tor?


I think there are some additional things to gain by using a new header:

Software that understands the header can handle it differently than
Location. I think the notification bar and the 'Don't redirect me to
the onionsite' options are pretty good UI things we should consider.
They're actually not great UX, but it might be 'doing our part' to try
and not confuse users about trusted browser chrome.[0]

Users who _appear_ to be coming from an exit node but are not using
Tor are not blackholed. How common is this? I've seen reports from
users who do this. If I were in a position to, I would consider having
exit node traffic 'blend into' more general non-exit traffic (like a
university connection) just to make the political statement that "Tor
traffic is internet traffic".

Detecting exit nodes is error prone, as you point out. Some exit nodes
have their traffic exit a different address than their listening
port.[1]


Location is really close to what we need, but it is limited in some
ways. I'm still on the fence.


[0] Except of course that notification bars are themselves spoofable
chrome but lets ignore that for now...
[1] Hey does Exonerator handle these?



On 15 November 2017 at 07:38, Alec Muffett <alec.muffett@xxxxxxxxx> wrote:
> I can see how you would think that, and I would kind-of agree, but at least
> this would be local and cheap.  Perhaps instead of a magic protocol, it
> should be a REST API that's embedded in the local Tor daemon?  That would be
> a really, REALLY common pattern for an enterprise to query.

This information should already be exposed via the Control Port,
although there would be more work on behalf of the implementer to
parse more information than desired and pare it down to what is
needed.

-tom
_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev