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
