W3C home > Mailing lists > Public > public-webappsec@w3.org > January 2014

Re: [integrity]: latency tradeoffs

From: Brad Hill <hillbrad@gmail.com>
Date: Wed, 22 Jan 2014 08:57:43 -0800
Message-ID: <CAEeYn8j65ik8FwZGfcW-Z6GWnXx+3QAv-Cv9E90g0RTXpwwA-g@mail.gmail.com>
To: Adam Langley <agl@google.com>
Cc: Mike West <mkwst@google.com>, "public-webappsec@w3.org" <public-webappsec@w3.org>
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.


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
Received on Wednesday, 22 January 2014 16:58:12 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 11 February 2015 13:26:35 UTC