Re: [service worker] f2f meeting notes, next meeting details

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 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 requests.
 * 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 resolutions
           * 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 spec:
           * 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 origin
           * 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 other
           * Need to introduce a way to wait until a Promise settles for IndexedDB to enable this as transaction completion is controlled by the browser currently
           * There are concerns with deadlock due to this
           * If you're caught in such a case in the wild, it might be hard to detect
           * 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 caches
           * .waitUntil needs to be able tocompose between multiple transaction systems
           * 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 implementation
           * 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,
Ali

Received on Wednesday, 13 April 2016 04:57:12 UTC