[whatwg] AppCache feature request: An https manifest should be able to list resources from other https origins.

[Jonas Sicking]

On Mon, Jan 31, 2011 at 2:57 PM, Michael Nordman <michaeln at google.com> wrote:
> I don't  fully understand your emphasis on the implied semantics of a
> CORS request. You say it *only* means a site can read the response. I
> don't see that in the draft spec. Cross-origin XHR may have been the
> big motivation behind CORS, but the mechanisms described in the spec
> appear agnostic with regard to use cases and the abstract section
> seems to invite additional use cases.

The spec does say what the meaning of the Access-Contol-Allow-Origin
header means. You're trying to modify that meaning.

Consider things from a web authors point of view. The author develops
a website, bunnies.com, which contains a HTML page which performs
same-site, and thus trusted, XHR requests. The HTML page additionally
exposes an API based on postMessage to allow parent frames to
communicate with it.

Since the site exposes various useful HTTP APIs it further has adds
Access-Control-Allow-Origin: <origin>
Access-Control-Allow-Credentials: true

to a set of the URLs on the site. Including the url of the static HTML
page. This is per CORS safe since the HTML page is static there is no
information leakage that doesn't happen through a normal
server-to-server request anyway.

However, with the modification you are proposing, an attacker site
could forever pin this page the users app-cache. This means that if
there is a security bug in the page, the attacker site could exploit
that security problem forever since any javascript in the page will
continue to run in the security context of bunnies.com. So all of a
sudden the CORS headers that the site added has now had a severe
security impact.

That's why I'm hampering on the semantics.

Another issue is that if a site *is* willing to allow resources to be
pinned in the app-cache of another site, it might still not be willing
to share the contents of those resources with everyone. If we reuse
the existing CORS headers to express "is allowed to be app-cache
pinned", then we can't satisfy that use case.

For example a website could create a HTML page which embeds a
user-specific key and exposes a postMessage based API for third party
sites to encrypt/decrypt content using that users key. To allow this
to happen for off-line apps it wants to allow the HTML page to be
pinned in a third party app-cache. But it doesn't want to expose the
actual key to the third party sites. If CORS was used to allow
cache-pinning, this wouldn't be possible.

> I do appreciate the using CORS for this feels like blurring the lines
> between two different things.  I wonder if there should be additional
> request/response headers in CORS to convey the intended "use" of the
> resource and whether that particular "use" is allowed?
>
> If not CORS, what mechanism would you suggest to allow HTTPS resources
> from another origin to be including in a cache manifest file? Any
> means for the 'other' origin to opt in will suite my needs.

I don't really care if this is part of CORS spec or not, but it needs
to be different headers than Access-Control-Allow-Origin to avoid
overloading the meaning of that header, and thus the effect of adding
it.

The header-value should probably include some sort of limit on how
long the resource is allowed to be cached, and maybe there should be
ways that the site can signal that a given url should be used as
fallback.

/ Jonas