- From: Anne van Kesteren <annevk@annevk.nl>
- Date: Fri, 22 Jan 2016 08:43:43 +0100
- To: WebAppSec WG <public-webappsec@w3.org>
- Cc: Marijn Kruisselbrink <mek@google.com>
A new feature is being developed for service workers, called foreign fetch. When a service worker is associated with a document, all fetches from a document, same-origin or not, go through that service worker. They show up as fetch events. This remains unchanged with foreign fetch. However, if the service worker goes to the network for a cross-origin URL and that corss-origin URL has an associated "foreign" service worker that opted into foreign fetch, we'll ask that foreign service worker for a response. (And yes, this can result in loops and such. We have not found anything that can restrict this well, other than that user agents will have to have limits.) Now, since this is cross-origin and the foreign service worker opted in, that's kinda like CORS. And we plan on using a distinct event for these fetches so you don't accidentally share the wrong thing. Now, when you hear CORS, you might think, but what about the credentials? And that is where things get complicated. If A wants to fetch something from B without credentials, B's foreign service worker will act as ambient authority since it was fetched with credentials way back when. However, only allowing foreign fetches that include credentials, and making everything else go the network, seems even more dangerous. Anyone here have any idea what to do? If you want to read more about foreign fetch: https://github.com/mkruisselbrink/ServiceWorker/blob/foreign-fetch/foreign_fetch_explainer.md https://github.com/slightlyoff/ServiceWorker/pull/751 Thank you, -- https://annevankesteren.nl/
Received on Friday, 22 January 2016 07:44:10 UTC