W3C home > Mailing lists > Public > public-webappsec@w3.org > January 2016

Request for input on Foreign Fetch

From: Anne van Kesteren <annevk@annevk.nl>
Date: Fri, 22 Jan 2016 08:43:43 +0100
Message-ID: <CADnb78iPYYdF2RTnwHYNyuJqn8Mq1BQUORJgsvYLoSTgwuFL3g@mail.gmail.com>
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:


Thank you,

Received on Friday, 22 January 2016 07:44:10 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:54:54 UTC