consider allowing static routing only for "foreign fetch" for anonymous requests

[wanderview]

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:

#920 (comment)

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?

[jakearchibald]

STATIC ROUTES MOTHERFUNKERZ!!

I'm similarly concerned about the privacy aspect here. Another way around it would be to make foreign fetch opt-in by the site (via meta tags or something in the site's service worker), but I guess that also raises the bar to entry.

[wanderview]

I think we've mainly be considering static routes as an optimization in the past. The fact it avoids js, however, makes it also a nice way to restrict arbitrary code execution in dangerous situations. This could be more of a driver to implement it (for me anyway).

For example, another possible use here would be a CSP directive indicating static routing is allowed, but service worker js should never be executed. This would allow a site to utilize some of our main use cases while locking down the risk of losing control of their site via some XSS service worker exploit.

[jakearchibald]

Closing, since we're removing foreign fetch.