Re: [integrity]: latency tradeoffs

I'd really like to hear more about the risks of Content Addressable Storage
in the context of the browser.

I think there are some interesting scenarios out there for this.  One that
I have in mind is if apps and the browser could share a CAS cache on a
mobile device.  The app could side-load the cache for the browser with a
set of resources to enable a rich experience to be rapidly available in the
browser without incurring a app context-switch.  We could even be quite
strict about requiring Access-Control-* headers in this case, because it
would be cooperative caching.  And if the integrity check is optimistic,
simply to see if data is available without hitting the network, I think the
incremental latency issue is also addressed without needing a
stream-friendly integrity mechanism. (though that is still a good idea for
future work)

Maybe this is actually a different use-case than "integrity",  but I see it
as being useful in markets where networks are slow and expensive, and as
creating a nice synergy between the app and web ecosystems that benefits
both.  It both encourages app developers to favor web technologies, and
makes experiences in the web browser better, too.

-Brad


On Wed, Jan 15, 2014 at 7:21 AM, Adam Langley <agl@google.com> wrote:

> On Wed, Jan 15, 2014 at 4:16 AM, Mike West <mkwst@google.com> wrote:
> > 1. Performance isn't the goal. Integrity is the goal.
>
> Not quite, right? If integrity were the only goal then HTTPS provides
> that. I'm assuming that the desires motivating this are things like
> minimising backbone traffic (i.e. ISP caching), improving response
> times (i.e. using CDNs without fully trusting them).
>
> > 2. I think the performance benefits of integrity would be focused on
> cache.
> > That is, the second load of a resource, regardless of its URL, could
> avoid
> > hitting the network entirely if we already have a matching resource
> locally.
> > For this case, we have the whole resource already, by definition.
>
> HTTPS resource can be cached equally well. If you're talking about
> using the cache as a content-addressable storage then I think that's
> too dangerous to allow. (As explored a little in "Origin confusion
> attacks". Also, talk to abarth about this.)
>
> Even if we do assume CAS behaviour, I don't believe that the metrics
> support this optimism. You should check with willchan and rvargas
> about observed disk cache behaviours.
>
> > I think this is problematic in most (all?) cases, given the nature of the
> > threat we're attempting to address. Trusting the resource to authenticate
> > itself doesn't provide much benefit if we're not sure we can trust the
> > resource in the first place.
>
> We're not trusting the resource to authenticate itself, but rather we
> are spreading the authentication data throughout the download itself
> in order to minimise processing latency. It's still the case that
> everything is authenticated by the single hash in the (trusted) HTML
> document.
>
> It's unclear whether the administrative overhead of doing this
> outweighs the latency advantages at this point.
>
>
> Cheers
>
> AGL
>
>