- From: Michael Nordman <michaeln@google.com>
- Date: Thu, 16 Jun 2011 17:47:07 -0700
> On Tue, 8 Feb 2011, Michael Nordman wrote: > > > > Just had an offline discussion about this and I think the answer can be > > much simpler than what's been proposed so far. All we have to do for > > cross-origin HTTPS resources is respect the cache-control no-store > > header. > > > > Let me explain the rationale... first let's back up to the motivation > > for the restrictions on HTTPS. They're there to defeat attacks that > > involve physical access the the client system, so the attacker cannot > > look at the cross-origin HTTS data stored in the appcache on disk. But > > the regular disk cache stores HTTPS data provided the cache-control > > header doesn't say no-store, so excluding this data from appcaching does > > nothing to defeat that attack. > > > > Maybe the spec changes to make are... > > > > 1) Examine the cache-control header for all cross-origin resources (not > > just HTTPS), and only allow them if they don't contain the "no-store" > > directive. > > > > 2) Remove the special-case restriction that is currently in place only > > for HTTPS cross-origin resources. > > On Wed, 30 Mar 2011, Michael Nordman wrote: > > > > Fyi: This change has been made in chrome. > > * respect "no-store" headers for cross-origin resources (only for HTTPS) > > * allow HTTPS cross-origin resources to be listed in manifest hosted on > > HTTPS > > This seems reasonable. Done. > But... I just looked at the current draft of the spec and i think it reflects a greater change than the one i had proposed. I had proposed respecting the "no-store" directive only for cross-origin resources. The current draft is examining the "no-store" directive for all resources without regard for their origin. The intent behind the proposed change was to allow authors to continue to override the "no-store" header for resources in their origin, and to disallow that override only for cross-origin resources. The proposed change is less likely to break existing apps, and I think there are valid use cases for the existing behavior where "no-store" can be overriden by explicit inclusion in an appcache.
Received on Thursday, 16 June 2011 17:47:07 UTC