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

 * Microsoft - Ali Alabbas, Jatinder Mann, Adrian Bateman, Travis Leithead, 
Todd Reifsteck
 * Google - Joshua Bell, Matt Falkenhagen, Jake Archibald, Alex Russell, Marijn 
 * 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 
      * 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 
      * 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 
           * 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 capable service worker. The effect of this flag would be for 
the service worker to be isolated in effectively its own origin. This origin 
will never be able to make non-credentialed requests. If a service worker isn't 
registered with this flag it won't be able to intercept non-credentialed 
 * v1 timelime
      * Want to be able to lock down on v1 (stable) so that we can move forward 
to v2
           * This way we can get implementers to go after v1 and not skip it 
and implement v2
      * Don't need to prove that there are no issues to reach v1 completion
           * Need to have tests and prove interoperability
           * Also need to feel that there is some level of completeness that 
implementers are able to implement and have an interoperable solution
      * We already have a v2 branch where v2 work is going
      * v1 issues stem from corner and non-trivial cases
      * Other work in progress to bring spec up to speed
           * Want to have client and response.url changes in Chrome and Firefox 
to satisfy and validate new changes of the spec as per yesterday's issue 
           * Need to adapt the spec with the latest HTML spec changes
      * Aim for TPAC to have an official draft to be reviewed for CR
 * Moving the spec somewhere neutral & moving Cache API to its own spec
      * Should we have the Cache API split from the service worker spec?
           * It would make a few things more clear to have it in a separate 
           * Developers are currently not aware that the Cache API is exposed 
to the window, separating out the spec may make this more clear
           * You don't need to have service worker to use the Cache APIs, as 
they can be used in the window object
           * Cache lifetime is not tied to a service worker, it is tied to an 
           * Could potentially be a copy and paste of the relevant parts 
related to Cache
           * It would be process overhead for the time being to maintain two 
different specs
           * Outcome: defer to when v1 is complete and then decide if we should 
do the split (#879)
      * Would prefer to have the service worker repository under the W3C 
instead of slightlyoff
           * We also want to use the contribution tracking tool
           * Small contributions can be pulled in without having them be 
identified as contributors
           * Substantive contributions require that they sign the IPR policy
           * Concerned that we will have reduced contribution because there is 
a barrier to contribute with having to sign the IPR policy
           * We are already doing this for other W3C specs and should do this 
for service worker as well
           * We want ideas to be royalty-free if they are included as part of 
the spec
           * Outcome: Jake to investigate moving repo to w3c account
           * Look into whether we can have gh-pages redirect
           * In case we cannot do gh-pages redirects, so that we preserve 
public links, but comply with W3C contribution policy investigate having IPR 
tool run in slightlyoff
 * Transactions (#823)
      * Cache have transaction-like properties that aren't explained well by 
the spec
      * Each browser is different based on their own implementations
      * Any opaque response would reject even if it was a 200
           * No-cors request from a CDN via addAll would reject
      * Developers have asked for IDB and caches to be operated on atomically, 
but behavior is not always that
      * How does this interact with IDB transactions?
           * There is a proposal for IDB promises that will be able to play 
well better with this model
           * Goal: have IndexedDB and Cache transactions be tied together
           * When running an IndexedDB transaction that runs a Cache operation 
where the Cache fails, the transaction for IndexedDB will fail
           * Interlocked commit that allows them to depend and wait on each 
           * Need to introduce a way to wait until a Promise settles for 
IndexedDB to enable this as transaction completion is controlled by the browser 
           * There are concerns with deadlock due to this
           * If you're caught in such a case in the wild, it might be hard to 
           * It could be addressed by timeouts
           * We already do this for service workers when 
ExtendableEvent.waitUntil is passed a Promise that never resolves
           * Not having transactions makes it easier for developers to write 
code involving caches
           * However, the tradeoff is that developers have been running into 
race conditions involving multiple read/write operations on the same cache
           * Would be nice to make the transactional API optional for those 
that need it
      * Outcome: Need to make sure you can make a transaction across multiple 
           * .waitUntil needs to be able tocompose between multiple transaction 
           * We can do timeouts via setTimeout and abort (to not overcomplicate)
           * Be explicit that cache.match isn't in its own transaction because 
it isn't locking
 * #63: Response constructor with ReadableStream
      * We're going to continue with waitUntil
           * May look at ways stream controllers could provide a closed Promise 
to make this easier
 * #626: How are unloaded tabs represented?
      * When a page is inactive it is eventually evicted
      * Unloaded tabs want to be observable to scripts
      * Scenario that cares about this: Push wants to be able to refocus a tab
           * If there's a tab already loaded, we shouldn't have to reload it
      * Making postMessage throw would be possible
      * Expose a new state on the window for inactive tabs to make it 
observable to scripts
           * Making evicted tabs is a huge thing to add to the platform, and 
may lock browsers into a particular behavior
           * Big decision that should not be taken lightly - would require that 
we introduce more information than necessary for a use case that we could 
potentially solve in another way
           * There is opposition to adding more complexity to the window model
           * To deal with not having to add extra metadata (another state) for 
the client objects, we can do the following:
           * openWindow(url, { reuseIfExistingClientMatches: 
/\/my-messaging-app\// });
           * Another solution: we could treat these dead tabs as uncontrolled 
clients - but it feels hacky
 * #839: Consider relying on eTags (or other headers) for service worker 
dependencies to check for updates
      * Currently, service workers do not check for updates for dependencies 
unless there is a byte difference to invoke the update
      * This is forcing developers to do post-processing of the service worker 
on the server to make a small modification to force the update
      * Prefer to have a JavaScript API, but we can use headers to enable 
forcing of updates
      * We agree on serviceworker.skipWaiting() and reg.update({force: true})
           * May need to bikeshed naming of force
           * Lots of problems using etags for this, e.g. if CDN stops serving 
etags for some reason
           * Rough idea around some-header-name: value where value is a digest 
like etags
      * update({force: true}) will leave you with the existing worker if the 
update fails (as usual)
 * Navigation timing and service worker
      * now can be used from any worker
           * However, high resolution time between workers is not yet possible
           * There is an open issue to try to figure this out on the web 
performance working group
      * Navigation timing v2 is ready to be implemented
           * IE/Edge has implemented already, we're just waiting for another 
           * Chrome has no pushback, just needs to be prioritized higher
      * Most interesting use case for developers is to understand the overhead 
that is introduced by service worker vs. using just the network
           * Developers want to know how long it takes for the service worker 
to start up and handle a fetch event
 * Cookies API
      * Service worker does not currently have access to cookies because the 
APIs are synchronous through document
      * The proposal enables an asynchronous way of getting/setting cookies
           * Origin only by default
           * Filtering based on cookie name
      * Should we have properties and methods that allow us to get things such 
as paths and names of cookies?
           * API should enable us to do more in the future e.g. have a 
dictionary for the cookies object type that allows us to get name and path
      * Potentially we could we have the API be the minimum viable product so 
that we don't have to specify a brand new API that can be updated
      * Ben needs to create an explainer with details about the goals, scope, 
and API usage so that we can understand the long-term evolution of the proposal
 * Persistence and quota API
      * Not discussed
 * Allowing multiple SW instances for performance
      * Not discussed
 * Timing for next meeting
      * July or August for 2 days
      * Would like to spend some time before TPAC to sort out remaining v1 
issues to bring us closer to bringing the service worker spec to CR by the end 
of the year
      * More details to follow as we narrow down the options for possible dates 
and locations

Please let me know if you have any questions or concerns.

Thank you,

Reply via email to