Re: more letters from the feds

[Seth David Schoen <schoen@xxxxxxx>]

Anthony DiPierro writes:

> Or what about a hidden service for reading web pages in general?
> Something which doesn't support POST (or maybe even GET), so is much
> less likely to be used abusively.  Is this feasible?

The current directory scheme does allow (in fact, requires) policies
to be specified in terms of IP addresses and TCP port numbers.  So
a "web browsing only" exit node is possible.  A "Google only" exit
node is possible if you knew the IP address of every Google server,
which is a fairly tricky proposition.

A "GET-only" exit node can't be specified with the current directory
system, which isn't capable of expressing any information about what
an node will do with connections to a particular TCP port other than
allow or deny them.  You could make an "HTTP GET only" exit node, but
you wouldn't have a way to tell clients that your node enforced that
policy, and users would probably get mad (and stop using your exit
node entirely) when some of their transactions failed mysteriously.

The fine-grainedness of exit policy languages is a difficult strategic
question akin to the problem of the fine-grainedness of DRM policy
languages.  It's possible that making an exit policy language more
specific would lead some existing exit node operators to forbid more
things -- things that they would actually like to forbid but currently
don't have a technical means of forbidding without getting effectively
kicked out of the Tor network.  On the other hand, it's possible that
making an exit policy language more specific would lead some existing
node operators to allow new things -- things that they wanted to allow
but didn't have a technical means of specifying that they wanted to
allow without also allowing other things that they didn't want to
allow.  It's also possible that some people who current don't run
exit nodes would start allowing extremely limited exit nodes that
they wouldn't have been willing to operate any other way.

The technical overhead of moving beyond ports to a more specific kind
of exit policy seems to me quite high, not because of the need to
develop a language to express it, but because of the need to find a
way of communicating it between the Tor client and client applications
(to prevent applications from making requests that exit nodes they're
using will block, or, conversely, to allow the Tor client to choose
exit nodes that will not forbid any of the things that an application
intends to do, or might possibly do).  I'm not aware of any existing
protocol that allows this information to be conveyed or any applications
that support this kind of feature right now.  To take a concrete
example, how would Firefox tell Tor "I need to be able to HTTP POST"
or how would an old version of lynx tell Tor "I only support HTTP/1.0"?
How would ssh tell Tor that it was ssh?

See section 2.1 of

http://tor.eff.org/cvs/tor/doc/dir-spec.txt

for the (extremely simple) status quo.

-- 
Seth Schoen
Staff Technologist                                schoen@xxxxxxx
Electronic Frontier Foundation                    http://www.eff.org/
454 Shotwell Street, San Francisco, CA  94110     1 415 436 9333 x107