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

[Nick Mathewson]

On Sun, Jun 5, 2011 at 8:29 AM, Ian Goldberg <iang at cs.uwaterloo.ca> wrote:
> 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?

Maybe!  It seems plausible to me, though we should definitely ponder
the security/performance implications.

>> 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?

Yeah.  Actually, handling application-level privacy leaks *can't* be
done with a regular proxy, unless the proxy gets to MITM ssl
connections, which probably isn't a good idea.

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.

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.

yrs,
-- 
Nick