On Tue, Jul 28, 2015 at 7:24 PM, Brian Smith <brian@briansmith.org> wrote: > On Mon, Jul 20, 2015 at 9:39 AM, Mike West <mkwst@google.com> wrote: > >> Brian, note that this means we really do need the response checking bits >> that you were concerned about earlier. >> > > Is this because the fetch could return an http:// response that was > stored using the cache API by a service worker that forwarded a fetch for > an <img>, <video>, or <audio>? > Yes. > Is there some other reason why response checking is needed due to allowing > fetch to forward mixed content requests for those types of fetches? > No (though I'd of course note that the `deprecated` concept requires response checking as well). The thing that people working on service workers are most concerned about > is that adding a no-op service worker to a page should not break the page > even if it has mixed content. Allowing service workers to use the cache API > for non-secure documents goes beyond that and IMO adds unnecessary > complexity. it would be simpler and thus better to just not allow a service > worker to cache http:// responses. > What's the threat model that that would satisfy? Basically, it seems like the fetch is the hard thing to allow; once we've allowed the insecure fetch, caching the (opaque) result locally seems like a no-op. In the worst case, the same data is used later to satisfy a later (also insecure) request. In the best case, we avoid touching the network again in an insecure manner. Fewer plaintext requests seems like a security win that we should allow if we agree that allowing passthrough requests is reasonable. > In particular, it is unclear to me what prevents a service worker from > returning a response retrieved over http:// in response to an https:// > request. Is that specified in the service workers spec, the fetch spec, or > this spec? Where in which spec? > That's in the service worker spec, specifically https://w3c.github.io/webappsec/specs/mixedcontent/#should-block-response. Anne: I'm not sure what you meant by "I suppose it won't always disallow that". When would we want to allow insecure responses to secure requests? I don't think that's something we've discussed, nor is it something I think is terribly appealing. -mike -- Mike West <mkwst@google.com>, @mikewest Google Germany GmbH, Dienerstrasse 12, 80331 München, Germany, Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: Hamburg, Geschäftsführer: Graham Law, Christine Elizabeth Flores (Sorry; I'm legally required to add this exciting detail to emails. Bleh.)
Received on Thursday, 30 July 2015 08:00:13 UTC