[whatwg] AppCache-related e-mails

[Michael Nordman]

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