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

[Alec Muffett]

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

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?

7) Story: when I was implementing the Facebook onion, I built infra to
support such (eventual) redirection and/or exit-node-usage tracking. Hit "
facebook.com/si/proxy/" from Tor/NonTor to see it in action. The most
challenging thing for me was to get a reliable and cheap way to look-up,
locally, quickly, cheaply and reliably, whether a given IP address
corresponded to an exit node. The closest that I could get to that idea was
to scrape Onionoo every so often and to cache the results into a
distributed, almost-memcache-like table for the entire site. ie: squillions
of machines. This mechanism suffers from all the obvious flaws, notably
Onionoo crashes and/or "lag" behind the state of the consensus.

8) So, to pass concrete advice on the basis of experience: rather than
pursue novel headers and reinvent a bunch of established, widely-understood
web redirection technologies, I would ask that Tor focus its efforts
instead upon providing a service - perhaps a listener service embedded in
little-t tor as an enable-able service akin to SOCKSListener - which can
accept a request from <cidr-subnetmask>, receive an newline-terminated IP
address, and return a set of flags associated with that IP (exit node,
relay, whatever) - or "none" where the IP is not part of the tor network.
Riff on this protocol as you see fit.

This would mean more people running more tor daemons in more datacentres
(and possibly configuring some of them as relays) - using this lookup
service to establish quickly whether $CLIENT_ADDR is an exit node or not,
and whether it should be issued "308 Permanent Redirect With Same Method"

I think this is a better goal for Tor to be pursuing.  What do you think?

    - alec
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20171115/cf621413/attachment.html>