Hello, here are the day 2 meeting notes from the service worker F2F in
Redmond,. The attendees are CC'd if there are any corrections that need to be
made or if anyone has any questions or concerns that they would like to raise.
=
Service Worker F2F
Redmond, WA
April 12, 2016
Day 2 Notes
Attendees:
-
* Microsoft - Ali Alabbas, Jatinder Mann, Adrian Bateman, Travis Leithead,
Todd Reifsteck
* Google - Joshua Bell, Matt Falkenhagen, Jake Archibald, Alex Russell, Marijn
Kruisselbrink
* Mozilla - Ehsan Akhgari, Ben Kelly, Andrew Sutherland (remote)
* Samsung - Jungkee Song
* Apple - Ted O'Connor
Agenda & Notes:
-
* Foreign fetch architecture (#878: Foreign fetch vs non-credentialed requests)
* Reduce state on the serial object
* Is there a way to fetch something locally that will always be visible?
* Yes, if there's no origin, it will be an opaque response
* New CORS header that the destination needs to support?
* alice.com (A) foreign fetch to bob.com (B), response from B to A:
that's a cross-origin request
* Want to reuse CORS infrastructure as much as possible
* Must create a new Response with the CORS headers
* SW is like B's server
* Response always creates a copy of the response and then modifies it
* Mechanisms should be the same in that the service worker
* Should we loop the request back through CORS or should we just make it
visible for the origin?
* Adding a new step with what the service worker responds with (adding
extra step in the network layer)
* Current security model is that A can do whatever it wants to A
* A has a security boundary (SOP) since it's in a different origin
* Constraining foreign fetch would defeat the purpose
* A can only see what credentials that are exposed through scripts (which
are none today)
* We shouldn't allow transparent smuggling of data
* A requesting data from C is not allowed
* A requests data from B which then requests from C and passes that
data on will have the same headers as C unless B creates a new response with
different headers
* CORS does not fit model
* Why make foreign fetch more complicated than postMessage in terms of
how origin B lets origin A have access to bytes?
* postMessage doesn't allow you to send opaque bytes
* Response time is when the CORS check occurs
* After the network request goes out is when the check occurs
* B can do whatever it wants to B and expose it to A
* We should minimize the number of policy security mechanisms so that we
do not have to service different policies
* A can make a request that initiates a foreign fetch even and
intercepted by B's service worker without having known and potentially with
no-credentials
* We don't need preflight because it requires that you are going to the
network and SWs don't necessarily require going to the network
* Fonts and analytics are the biggest use case for foreign fetch at the
moment
* Opaque requests can allow no-credentialed request
* It would create some issues with maintainability
* Would prefer to have some sort of partitioning instead
* New issue created: #878: Foreign fetch vs non-credentialed requests
* Summary from issue: As currently specified foreign fetch doesn't
play together well with non-credentialed requests. In a world without foreign
fetch, a website on origin A can fetch something from origin B without
credentials, and there is no way (modulo fingerprinting) for B to associate
that request with its cookies. If B can intercept the request with foreign
fetch this is no longer the case as B itself was fetched with credentials, and
can make credentialed requests and access data that was cached using
credentials. There are a few options here:
* Live with this: non-credentialed requests aren't an important
security/privacy boundary since B can use fingerprinting etc. anyway to track
things and associate requests with credentials.
* Completely disable foreign fetch interception of non-credentialed
requests. This would be very unfortunate as things like fonts are always
fetched without credentials, so this would disable a major use case of foreign
fetch.
* Require origin A to opt in to having its non-credentialed requests
be intercepted by a foreign fetch service worker. This would be rather
unfortunate as well, as it would largely get rid of the transparent nature of
foreign fetch, making it much less powerful.
* Somehow make it possible for origin B to say "this service worker
does not need credentials". In the case of something like the fonts use case
this would be done by adding an extra flag to the Link: header that installs
the foreign fetch capab
