[whatwg/fetch] considering adding a proxying concept for service workers (#1323)

Currently we have a number of request headers and getters that describe the initiator of the request.  Some of these are security sensitive; e.g. origin and sec-fetch-site.  This works well in traditional sites, but tends to get difficult when service workers are introduced into the mix.

When a site has a service worker that does a passthrough fetch handler (`respondWith(fetch(evt.request))`) what we really need to do is represent the concept:

"Service worker context B is making a request on behalf of original context A."

It can be difficult to know which context should take precedence when selecting values for the request.  Should it have an origin header matching context B or context A?  If we choose the SW context B, then we may make unsafe requests appear to be safe.  On the other hand, for values like destination we probably need to pick the SW context B in order for CSP to work properly today.

It seems like it might be nice to have some kind of concept and infrastructure for this proxying "request on behalf of another" situation.  Perhaps headers could be structured as `HEADER: <SW value> (<original value>)` in a consistent way.  Perhaps there could be CSP that formalizes restrictions like "never permit this SW to issue a non-GET request for a cross-site initiator".

I don't really have a proposal here, but it seems like it might be worth discussing.  Folks who might be interested: @arturjanc, @annevk, @mikewest 

This was discussed at the recent SW virtual F2F: w3c/ServiceWorker#1604

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