falken@, rdevlin.cronin@ - WDYT?  Is this WAI, or is it a bug?

falken@: Also a Site Isolation question (kind of related to issue 786673): Would a compromised *web* renderer be able to route a fetch request through an *extension* service worker (the latter being mostly exempt from CORS)?  I hope the answer is "no, the browser process won't let that happen".

I'm not fully sure what's the correct behavior since any fetch requests from a controlled page seem to need to be handled by the page's service worker. It seems including fetch() from content scripts.

From the implementation point of view, it might not be easy in the current implementation to let those requests fire FetchEvents on an extension service worker since a page doesn't have any connection to the extension service worker and also we need to distinguish fetch() calls from an extension and a page.
For the same reason, I don't think a compromised renderer have a way to send a request through an extension service worker for now.

My understanding is content scripts are injected into web pages. I would expect requests made such a content script to be intercepted by the wb page's service worker, not the extensions service worker. That fits the model of service workers: a context can be controlled by a single service worker, which sees all requests from that context.

I agree there seems to be a discrepancy between that model and |request_initiator|. I haven't encountered use of |request_initiator| in service worker implementation code. So I don't immediately see how to reconcile these two models, or if it's fine as-is.

For c#2, the answer is indeed "no, the browser process won't let that happen". With ServiceWorkerServicification, the renderer only has access to a service worker that the browser  gives it a Mojo connection to. And pre-ServiceWorkerServicification, the browser makes the decision about where to route each request, and it'd only route it to the appropriate service worker.

s/requests made/requests made by
s/extensions service worker/extension's service worker/

Thanks for the explanations - the current behavior sgtm.  I'll resolve the bug as WontFix/WAI.