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

[Ian Goldberg]

On Sat, Jun 04, 2011 at 11:15:53PM -0400, Nick Mathewson wrote:
> On Thu, Jun 2, 2011 at 8:45 PM, Ian Goldberg <iang at cs.uwaterloo.ca> wrote:
> > Sorry this took so long.  As usual, things got inserted ahead of it in
> > the priority queue.  :-p
> >
> > Anyway, here's the client-side sibling proposal to the
> > already-implemented 174.  It cuts down time-to-first-byte for HTTP
> > requests by 25 to 50 percent, so long as your SOCKS client (e.g.
> > webfetch, polipo, etc.) is patched to support it.  (With that kind of
> > speedup, I think it's worth it.)
> >
> 
> Added as proposal 181.
> 
> 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?

> As for the application support matter, I wonder how hard it will be to
> actually get support.  We're trying to phase out HTTP proxies in our
> bundles, so it seems we'd need to tweak browsers to send
> optimistically.

Don't we already modify the browser in the bundle?  You need _something_
(either modifications to the browser or a privacy-aware proxy) to remove
any application-level privacy leaks that might exist, right?

   - Ian