[tor-dev] Proposal: Optimistic Data for Tor: Client Side

[Ian Goldberg]

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
> idea.

You also lose the ability to tell the SOCKS client if the connection
ended up failing.

   - Ian