[w3c/ServiceWorker] consider allowing static routing only for "foreign fetch" for anonymous requests (#1024)

One of the lingering concerns with foreign fetch service workers is the potential for tracking.  For example, I believe web font loads are requested without cookie credentials.  This is to prevent the font serving origin from tracking a particular user across sites.  Foreign fetch, however, would allow the font serving origin to run script and store any manner of data in IDB, etc.  In many ways it makes the tracking issue worse.

It would be nice if we could just disable foreign fetch for requests that do not allow cookie credentials.  This would break one of our main use cases, though; web fonts.

As a compromise, I was wondering if could restrict the ForeignFetchEvent to only credentialed requests, but still allow non-credentialed requests to be handled by a static route configured by the foreign fetch service worker.

You may be wondering what I mean by "static route".  This is something that has been discussed, but doesn't exist yet.  See:

https://github.com/w3c/ServiceWorker/issues/920#issuecomment-229016073

The idea would be to allow the service worker to programmatically setup a set of static resources to respond to foreign origin requests.  This lets the foreign fetch SW handle the most common use cases like the providing offline access to web fonts.  At the same time, by not firing a javascript event we can avoid the risk the SW will perform additional work to track the user.

This would also get triggered for browser features like disabling 3rd party iframe cookies, etc.  Since the requests are sent without credentials the same restrictions on the foreign fetch SW would apply.

This would allow us to achieve the main use cases we were targeting while also avoiding new privacy leaks.  It would also continue to work in a progressive way just like foreign fetch does today.  On browsers without this feature the requests would just go to the network/http-cache as they do today.

@jakearchibald @mkruisselbrink Thoughts?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/ServiceWorker/issues/1024