OpaqueResponse object

[annevk]

First of all, this should probably not expose anything.

Having said that, what is method? Responses don't have a method.

[jakearchibald]

Yeah, they shouldn't have a method.

You mentioned in IRC the possibility of exposing status on OpaqueResponses, or something to indicate "not 200". Had any more thoughts on that?

This would be used by the cache to reject .add based on 404s etc.

[annevk]

We need to ask @abarth et al whether they think we can expose the HTTP status code of tainted cross-origin resources. It seems somewhat scary to expose more, but as you said appcache already did without alarming people.

[jakearchibald]

@abarth some background:

In ServiceWorker we have caches:

var cache = new Cache();
var cachePromise = cache.add(url1, request2, url3...);

.add is an atomic operation, cachePromise will reject if those items cannot be added to the cache. I think it should reject if the requests succeed, but one or more has a status that indicates failure. This is how AppCache works:

If the [updating an item from the manifest] step fails (e.g. the server returns a 4xx or 5xx response or equivalent, or there is a DNS error, or the connection times out, or the user cancels the download), or if the server returned a redirect, or if the resource is labeled with the "no-store" cache directive, then … abort these steps for those other URLs. Run the cache failure steps.

This means you can use AppCache to determine if a response from another origin, without CORS, looks like a 200 or a 4xx/5xx. If that isn't a security risk, we'd like ServiceWorker caches to behave in a similar way.

fetch(request).then(function(response) {
  // ...
});

When the response is to another origin and doesn't have CORS headers, we consider that an OpaqueResponse. Can we safely expose information on here such as status code? Or failing that, something vaguer to indicate 4xx/5xx?

I'm less sure what to do about the cross-origin redirects.

[abarth]

You're definitely pushing the boundaries. Currently the way people learn this sort of information across origin boundaries is using elements, which fire either load or error events depending on what they see. That's useful in a number of attack scenarios, for example to determine whether someone is logged into a target site.

What you've outlined above sounds more powerful than what you can do with elements today because you can learn about non-image resources. My guess is the exposure of this information in AppCache is under-researched from a security point of view.

[annevk]

@abarth, correct. With elements you only learn about actual connection vs network error. With certain elements you can learn a bit more about whether the response can be decoded in some fashion.

This would expose actual response data, accurately.

[annevk]

We're not doing this for now.

[jakearchibald]

In Chrome, applicationCache.onerror tells you which item resulted in cache failure. If the resource is same-origin, you get a detailed error message including status code. If it's cross-origin, you only get the url.

[jakearchibald]

I can never find this thread when I want to, so here are some keywords I usually use to find it: detect 404 crossorigin addAll