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 [EMAIL PROTECTED] Electronic Frontier Foundation http://www.eff.org/ 454 Shotwell Street, San Francisco, CA 94110 1 415 436 9333 x107
