Re: Request for input on Foreign Fetch

+rsleevi, who has thought more about the ways in which Chrome requests
things with and without credentials than I have (socket pools, etc).

On Fri, Jan 22, 2016 at 8:43 AM, Anne van Kesteren <annevk@annevk.nl> wrote:

> Now, when you hear CORS, you might think, but what about the
>
credentials? And that is where things get complicated.
>

When I hear "CORS", I think "Will the foreignorigin's service worker be
able to respond to OPTIONS requests?" because that sounds dangerous. I
assume preflights will continue to skip both service workers?


> 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.
>

What are the threats we're concerned about?

On the one hand, we have requests which do not include credentials to
protect the server from accidentally leaking data. I'd suggest that tying
this entire mechanism to service workers means that we can be a little more
lax about the kinds of restrictions we impose in response to this threat,
as essentially all the risk would be opt-in. We couldn't inadvertently
expose data that the service worker didn't explicitly request, and we could
mitigate the risk of accidental leakage by requiring some sort of flag on
the response to return a cached response that was fetched with credentials
when the request wasn't.

On the other hand, we have requests which do not include credentials in
order to protect the user from inadvertent identification. I'm not sure how
we could effectively mitigate this risk, as the service worker could leak
data about a user's requests via delayed, credentialed requests, and the
service worker itself always knows who you are, as it was fetched with
credentials, and could easily have served up a file hard-coding those
credentials in some way. Incognito/private mode seems like a better
response to this kind of use case, but I admit that it's not clear to me
how widespread this kind of usage might be.


> Anyone here have any idea what to do? If you want to read more about
> foreign fetch:
>
>
> https://github.com/mkruisselbrink/ServiceWorker/blob/foreign-fetch/foreign_fetch_explainer.md
>   https://github.com/slightlyoff/ServiceWorker/pull/751


We have a carveout in MIX for fetches which a service worker performs in
response to requests that came from a document. I wonder if we could place
some restrictions on the kinds of fetches that can be made in response to a
foreign fetch event. I don't know what those restrictions would look like
or how they'd work, but, you know.

-mike