[tor-dev] Proposal: Optimistic Data for Tor: Client Side
iang at cs.uwaterloo.ca
Wed Jun 8 22:10:37 UTC 2011
On Wed, Jun 08, 2011 at 05:51:41PM -0400, Nick Mathewson wrote:
> >> I'm a little worried about the robustness issue: currently, if an exit
> >> node refuses a BEGIN request (because of its exit policy typically)
> >> the Tor client will retry at another exit node. But if optimistic
> >> data is in use, it seems that the client's initial data will be lost,
> >> unless the client keeps a copy around to send to other exits as
> >> required.
> > That's a good point. Perhaps the latter is the right thing to do? That
> > would be sort of a combination of what we do now and the above proposal:
> > buffer the data (as we do now), but also send it (as the proposal).
> > When you eventually receive the CONNECTED, flush anything in the buffer
> > you've already sent. If you eventually receive END instead of
> > CONNECTED, try another circuit, using the buffered data?
> Maybe! It seems plausible to me, though we should definitely ponder
> the security/performance implications.
Indeed. They don't seem bad at first glance, at least.
> All I'm saying here, though, is that I'm wondering how hard the change
> will be to actually make. Most socks client code tends to get
> isolated in an application's network layer as a replacement for
> "connect", so unless the application is already set up to do "connect,
> send send send" rather than "connect, wait for connect, send send
> send", the application modifications will be tricky.
Right. So it turns out this is a case where using an HTTP proxy makes
things easier. Hasn't some Tor person been fiddling with Firefox code?
Maybe even Firefox SOCKS code?
> As an alternative, the socks proxy (Tor) could be told to say
> "connected" immediately, so that the app starts sending. I don't know
> how badly this would break browsers, though. Probably not a good
You also lose the ability to tell the SOCKS client if the connection
ended up failing.
More information about the tor-dev