Serviceworker f2f

04 Apr 2017


chaals, Yves, JakeA, catalinb, Flaki, horo_, tyoshino, yhirano__, asuth, falken, Makoto, Kinuko, wanderview, Surma, Mek, jungkees, Ali_Alabbas, MikeTM, DomenicD, tess, bradyE, Salva


<JakeA> https://github.com/w3c/ServiceWorker/issues/1094

wanderview: is there anything we want to make sure covered? foreign fetch?

JakeA: yeah foreign fetch. anyone with requests?

falken: navigation preload?

JakeA: Just wanted to make sure we have V1 covered

Domenic: deprecate appcache? :)

JakeA: we should do that.

surma: [reloading fetch?]

JakeA: annevk posted on it yesterday in more detail, we should have a look


<chaals-ordhord> https://github.com/w3c/ServiceWorker/issues/1094

<chaals-ordhord> JA: There are various places where you should act as if there is no SW

<chaals-ordhord> ... there are some complicated cases.

<chaals-ordhord> ... we made decisions, but nobody has implemented. fetch.request will fail

<chaals-ordhord> Ben: We didn't do this in gecko because there are missing pieces

<chaals-ordhord> ... we will probably do it, we don't think it isn't valuable

wanderview: why we didn't implement this in gecko we need some [extra infrastructure]

<chaals-ordhord> ... have heard from developers they need mixed content.

<chaals-ordhord> Salva: usecase - podcast app. even if content is passive you need to call it through http

salva: one usecase e.g. for a podcast app, you don't want to proxy everything through https

<chaals-ordhord> JA: had people try to make podcast example. CORS is also an issue e.g. RSS feeds

<chaals-ordhord> Ben: You could do it with CORS, mixed content warning was the blocker

<chaals-ordhord> JA: standalone app would have that too.

<chaals-ordhord> Salva: problem is the crawling model.

<chaals-ordhord> JA: Even if we implement this, PWA will get scary warnings. plan is to prevent downgrades like this. Do we mark it as at-risk?

JakeA: the plan is to eventually prevent downgrades like this

<chaals-ordhord> Ben: No strong opinion as implementor. Maybe we just don't do it, developer feedback is what matters.

wanderview: consult the web dev community, see if they accept this as a limitation?

<chaals-ordhord> N8: facebook doesn't want mixed content warning.

<chaals-ordhord> Ben: Maybe remove it with note that says this is possible but isn't implemented yet.

<chaals-ordhord> Falken: Surma filed bug in Chrome. Do you recall a usecase?

<chaals-ordhord> [chrome bug 614375]


<chaals-ordhord> Surma: working with opaque responses. images...

<chaals-ordhord> ... so I would get blocked. We should be able to cache opaque response

<chaals-ordhord> Ben: You can do it from a page, not from an SW

surma: I got blocked... if it was an opaque response one should be able to cache it anyway

<chaals-ordhord> Surma: yeah. SHould propogate mixed-content state, but show the image.

<chaals-ordhord> Salva: @@

<chaals-ordhord> Ben: Should we say that you can't have it?

wanderview: I wouldn't have a problem--but couldn't implement just yet due to infra issues

<chaals-ordhord> JA: You mean if it fails, pass it through fetch, or prevent mixed content

<chaals-ordhord> N8: Let people do it through fetch.

<chaals-ordhord> ... don't call RespondWith

<chaals-ordhord> surma: So then you cannot cache it?

<chaals-ordhord> JA: Right. If anything mixed is in the cache you display warning.

salva: so we are not blocking?

<chaals-ordhord> ... if you want to display mixed content, if the request is http: don't call respondWith.

<chaals-ordhord> N8: that's safer.

wanderview: but then you can't do anything

n8s: and it's fine, as it avoid a whole many other issues

<chaals-ordhord> [only passive mixed content goes through anyway in other methods]]

salva: we can inform the user that for such content is not available offline

<chaals-ordhord> n8s: You can't get it

<chaals-ordhord> Ben: Does fetch require secure context?

wanderview: you can create a fake request with a http url, but [...]

<chaals-ordhord> Surma: no, you can fetch http:

<chaals-ordhord> MK: You can postMessage a response as a hack.

Mek: if you postmessage the response you would be able to get a http response

yhirano__: it's possible to [..]?

JakeA: not via Fetch
... if you call event.respondwith(event.fetch) it will fail due to mixed content

<chaals-ordhord> JA: we're fine with what browsers do now.

<chaals-ordhord> YL: what happens with an upgrade insecure request?

yhirano__: thought that was transparent

<chaals-ordhord> Ben: doesn't happen before the request

JakeA: step four of mainfetch

<chaals-ordhord> Ben: I will write some tests for that

wanderview: we should have tests for that, not sure of the implementations

<JakeA> https://github.com/w3c/ServiceWorker/issues/1075


<chaals-ordhord> JA: might have covered yesterday

<chaals-ordhord> ... Anne says he will get to it next week. seems fine.

Domenic: does anyone interested in the actual parse issue?

<chaals-ordhord> DD: Actual issue. If you're a popular site you often convince people to copy/paste an iframe snippet.

<chaals-ordhord> ... now you can use ancestor origins to see where a user saw those embeds. So provide a way for sites to opt out of that.

Domenic: via ancestororigins you can see a list of all pages where your user can see your snippet

JakeA: iframes can already reach their parents?

<chaals-ordhord> DD: iframes cannot reach their parent window crossorigin for things like location

Domenic: not cross-origin

jungkees: annevk is concerned about frametype

<chaals-ordhord> JS: In previous f2f we concluded frametype isn't meaningful, Anne pointed that back.

<chaals-ordhord> JA: wait for Alex.

<chaals-ordhord> Ben: And usage data. If nobody removed it, we should note that.

JakeA: as usage numbers come back we could remove it

<JakeA> https://github.com/w3c/ServiceWorker/issues/1033


<chaals-ordhord> JA: Spec just had most commonly used MIME types. We should switch to the HTML definition

<chaals-ordhord> ... doesn't feel scary

n8s: makes things less surprising

<chaals-ordhord> DD: Saw someone real confused by this... not just spec theory

<slightlyoff> OMW over now; apologies (meetings)

<JakeA> https://github.com/w3c/ServiceWorker/issues/719


JakeA: we talked about this briefly

<chaals-ordhord> JA: attack is I can find urls of your fonts

<chaals-ordhord> ... and imports

<chaals-ordhord> ... but doesn't feel like a big deal

no getcomputedstyle, so no background images

<chaals-ordhord> DD: tingles for me in combination with another attack

<chaals-ordhord> JA: Yahoo mail attack, right?

JakeA: is this like the yahoo mail attack?

<chaals-ordhord> ... construct a background image they could get.

<chaals-ordhord> Ben: SHouldn't leak cross-origin info except CORS

wanderview: on the one hand we shouldn't be leaking cross-origin info

<chaals-ordhord> ... Jonas argued that stylesheets are already so leaky this isn't a big deal

Mek: we don't have opaque requests--only opaque responses

<chaals-ordhord> MK: Request shows URL, only response is opaque.

<Domenic> https://www.linshunghuang.com/papers/css.pdf

<chaals-ordhord> DD: Oh, someone has an attack described

Domenic: someone has an attack that seems very similar

JakeA: does it treat a non-css resource as css?

Domenic: [yes]

wanderview: chrome should lead the way on this change due to having been released

<chaals-ordhord> Jake: I like the idea of abdicating responsibility... ;)

wanderview: I don't have strong position, in the end I'm willing to implement what the group decides

<chaals-ordhord> DD: Suspect few people load x-origin resource in styles via SW

wanderview: I think [there are a lot of unspecced issues]

<chaals-ordhord> JA: COunter - if you cache a google font.

<chaals-ordhord> DD: Hmm, maybe. Or maybe we can break them on people and live with it

<chaals-ordhord> JA: For an icon font that's bad.

<chaals-ordhord> KB: If it doesn't work you can reload and get your font.

falken: there's an open CRBug, and sec team is pinging us on it

wanderview: we had a restricted bug and since it was on github, we unrestricted it

Domenic: I'd really want to fix this
... someone will string this together with other ones, it's a sec issue waiting to hppen

<falken> (the restricted crbug is 532374)

Domenic JakeA: we need to look at the attacks

Domenic: from just skimming the attacks, it pushes me to fix this

<kbx> DD: we sometimes do break fonts, like the 2G intervention. (context for KB's comment; on 2G Chrome doesn't block on fonts, it still does an async download though for subsequent nav/visits)

<chaals-ordhord> Ben: We should try to resolve this not f2f

wanderview: let's try to resolve this async
... get the right people into "the room"

Domenic: ask people, look at the use counters

wanderview: there was an other issue we resolved
... are you still doing it?
... I'm willing to implement it

falken: we haven't yet, but yes we are planning to

wanderview: [finalURL]
... it would strengthen our sec infrastructure
... adds to cross-origin protections

<kbx> maybe this issue: https://github.com/w3c/ServiceWorker/issues/787

falken: I think we ended up with the same, that it would improve security so we want it

spec fixing issues

<chaals-ordhord> JA: Don't need to do that f2f, no behaviour changes.

<JakeA> https://github.com/w3c/ServiceWorker/issues/1040


wanderview: people were polyfilling bg-sync by creating new extendable events
... in hopes that it was going to be able to extend lifetime indefinitely
... I'm okay with having this extend to the allotted time budget
... or just say that manually constructed extendableevents have no associated time budget

JakeA: would speccing time budgets fix this?

<chaals-ordhord> TOC: so user-constructed events don't grant any more time?

<chaals-ordhord> JA: right

<chaals-ordhord> TOC: what about synthetic click from a page?

<chaals-ordhord> JA: you could do a postMessage to grant time.

<chaals-ordhord> TOC: SW cannot grant time to itself, as meta principle.

<chaals-ordhord> JA: right

wanderview: if we would have this on global time budget, one could have this time borrowed from any "disconnected code"

<chaals-ordhord> Surma: why expose constructor anyway?

<chaals-ordhord> n8s: so you can pass events to yourself.

wanderview: if we wanted it to have time one would have to pass in the original event (that had time budget associated)

n8s: [agrees]

<chaals-ordhord> [jake scribbles into the issue as we chat]

falken: in our implementation it would be hard to plumb these over to the main browser process

wanderview: in our code I just set extendable false for manually constructed events

Mek: there aren't any flag like that on spec!

wanderview: ah this is from before the async waitUntil stuff

<chaals-ordhord> JA: We'll figure out the spec-ese async/later

<JakeA> Next topic: Where are we in regard to multiple service worker threads? Also: what's going on with shared worker?

multiple service workers

*multiple instances of

<chaals-ordhord> TOC: we'd like it. is there a compat problem?

<chaals-ordhord> JA: Think so

<chaals-ordhord> n8s: seems like the bridge is burnt.

<chaals-ordhord> AR: Would support an opt-in given evidence we need it

<chaals-ordhord> JA: Is it for performance or ease of implementation?

<chaals-ordhord> TOC: Both.

<chaals-ordhord> JA: So opt-in for ease of implementation isn't going to help

JakeA: you can just treat global scope optimistically

pieter: but then if we want to rely on data we need to go to indexdb and it might stop being a perf win

<falken> i think the issue is https://github.com/w3c/ServiceWorker/issues/756

JakeA slightlyoff: having data on this would help us understand better how to prioritize

slightlyoff: we'd get data from fb right?

n8s: yes

slightlyoff Domenic: it might be hard to implement, not sure it's worthy of experimenting until we have data on (potential) benefits

wanderview: instrumenting service workers could come as a benefit from this

asuth: do we have data on SW js size?

falken: yes--but it would probably be all facebook :)

wanderview: for foreign fetch we might want to do this

JakeA: yes and foreign fetch might be a good way for testing this

wanderview: we could just do this with separate globals, but potentially same/different thread

JakeA: wouldn't that be slower?

wanderview: this is not a perf suggestion
... but then one could just use a threadpool to spicen it up
... not advocating for it, just saying it could have other benefits from this besides perf

tess brady: would even make this a default for foreign fetch

JakeA: so creating a realm...

tess: that's fine they're cheap

jake tess: we could do up to realm abstraction

ali: can we talk bg sync as well
... it runs in a separate process

brady: our indexdb is in separate process as well

n8s: for us, as long as all push events went to the same sw it would be ok
... our sw had to be able to msg clients

ali: usecase?

n8s: we have a throttled client that we want to notify from sw, to update badge count
... we don't need global state in general, but clicks and pushes should go to the same sw

ali: we could guarantee the click, but not sure about push
... there are edge cases, related to running the background sync in a separate bg task
... the bg task makes sw a "good citizen", advantages come from the os standpoint
... but there is a "drawback" related to having to have it in a separate process

tess: I don't see as a drawback
... does it coalesce payloads?

ali: don't think it does
... facebook knows what end point it wants to push to, but I don't think all devs will be that sofisticated and will need help from os level

JakeA: this all sounds like a good first step

ali: our goal is to be able to scale this to multiple sw, multiple fetches go to separate sw
... we're not there yet but the goal is to be able to do that
... my guess is for mobile we'll keep this at 1 sw, but maybe higher-end devices could do higher

asuth: would it worth to expose in an installing worker what will they be doing (e.g. sw-s specifically for push)

n8s: don't think we want to spec that

wanderview: one could spin up different sw like that
... do we wait until ms tries this?

slightlyoff: want to see data first

ali: even data aside we think it's the better approach

n8s: def agree for push

ali: and bg sync

tess: [agrees]

ali: f12 is gonna be tricky
... can't debug the sw that's not inside of edge

n8s: can the sw see each other?

slightlyoff: they can see the client, so can get a messageport through

wanderview: question is what a service worker dom object represents?
... is it an istance, a potential instance?

tess: you kill them all the time anyway

wanderview: we could have the sw dom have a getInstances()
... then get a list, postmessage the first one

n8s: which is the first one?

slightlyoff: in ms case you just don't let the two sw run at the same time

the os process service worker just has chakra, network stack etc

n8s: why does the sw have to live in edge in the first place?

ali: we thought about that, but it isn't
... the bg service worker is running in a process we don't own (in a bg service infrastructure)
... we want to own some stuff about our service worker process
... we are the first impl to try to do this (running in a bg thread), and it will certainly open a sort of pandora's box
... not having global state and postmessage is the two problem areas we have identified

n8s: postmessage is a problem, replying to (the correct) service worker might not be possible due to navigation and global state might have changed

asuth: would shared workers be still possible?

ali: we are not looking at shared workers right now, but I cannot answer now

JakeA: you could use broadcastchannel, have the service worker with an active push event respond?

n8s: yes but that's quite messy

ali: do you use a messagechannel?

n8s: we do

ali: who sets it up?

n8s: currently it's the sw, but could see it work the other way around

[discussion over M tabs and N service workers becoming a distributed system, and hard to find way to make interactions easier]

you can just channel your push messages through the running sw

ali: you cannot trigger the bg service worker thread, it is only triggered by the os as a result of a push

slightlyoff: it's a policy question of handling half-delivered events
... on android you could already have processes killed any time
... i don't think we redeliver now but you could

ali: then you don't know if your half-delivered event is idempotent, might potentially redeliver events

tess: it's not ideal

ali: it definitely isn't

slightlyoff: a push daemon starts chrome itself, with special cmdline flags that don't create a window early on
... we currently killed our windows system service, it wasn't very good
... it was effectively running chrome in the background (our profile service, but that starts up most of chrome)
... we are trying to atomize chrome and bring it back again

<JakeA> https://github.com/w3c/ServiceWorker/issues/1077

n8s: self.self? :)

<JakeA> https://github.com/w3c/ServiceWorker/issues/1076

n8s: [self.]serviceworker

[agreement, bikeshed further on name]

<JakeA> https://github.com/w3c/ServiceWorker/issues/1016

JakeA: often ppl just postmessaging into a serviceworker just to have it skipWaiting - why not expose this on the page?

n8s: I could see it come easy, if it isn't too hard to impl

wanderview: we shouldn't create reasons for ppl to postmessage

falken: should it go on the sw or the registration?

JakeA: service worker?

wanderview: better to be explicit

<JakeA> https://github.com/w3c/ServiceWorker/issues/842

JakeA: expose install time?

wanderview: don't see a reason why not?

n8s: feels like an id...
... I don't think it's useful as a timestamp, as opposed to an id
... ppl will just do bad things with it

wanderview: maybe have this display the last update check?

asuth: wait for more complaints?

n8s: yeah

asuth: we're gonna expose in devtools anyway
... "my sw is not installing -- check its timestamp!"

<JakeA> https://github.com/whatwg/html/issues/151

wanderview: wontfix it and come back later if needed

JakeA: disable it on http?
... maybe chrome should take a lead...

wanderview: how about the polyfill?

JakeA: haven't looked into that thoroughly but it's probably not right

flaki: maybe the appcache polyfill doesn't help with complicated setups

slightlyoff: we run one of the most complicated caching logics, deprecating and removing appcache would make it easier for us to transition more properties
... we are currently hamstrung by it

JakeA: appcache is not like mega-complicated -- it's just wrong

falken: for internal sites, it's mostly perf regressions, not the lack of willingness

JakeA: proposal to have a polyfill function that takes a manifest file and serves files according to it from inside the service worker

Domenic: what happens if you have both?

JakeA: handwavy, but tldr is: ignore appcache

wanderview: it doesn't make a lot of sense for annevk to integrate appcache into fetch

slightlyoff: what is the process of removing features?

Domenic: we generally keep them until they're gone from at least two browsers

JakeA: removing from http, what does safari thing?

brady: not an objectionable idea

<chaals-ordhord> FWIW https://github.com/w3c/html/issues/40 was closed and in HTML 5.1 appcache is in an appendix of stuff browsers need to know but authors shouldn't touch

aliams: unfortunately we have enterprise users, so it's gonna take some time...
... at some point we can say they should just use IE
... we're not gonna do it before we ship another solution...

JakeA: but you're not gonna have sw on http!

<slightlyoff> crbug: https://bugs.chromium.org/p/chromium/issues/detail?id=588931

<slightlyoff> sadly the engineer who added this left the team

<slightlyoff> I'll try to find a new owner

flaki: also on bugzilla: who is it gonna break, and how badly, on unmaintained sites if we remove it

JakeA: you can hack news permanently on sites!

n8s: this removes all the trust

salva: we are talking about removing a well-established feature

yves chaals-ordhord: question is, should we do more work to improve it or just let it die when sw becomes prevalent across the platform

JakeA: I _want_ to yank this from http

[?]: I want me to find a way

Domenic: what would happen if this actually became an easy to use attack?

wanderview: can we badge this terribly visibly?
... the user cares more about this, they could exert pressure on the developer
... at least our experience with password field was successful in getting sites to switch

JakeA: altohough opening in other browser, one that does not say "this site is compromised"

chaals: ppl do and switch browsers

Domenic: anecdotal security experiences shouldn't guide our decisions

JakeA: kill it with fire!

wanderview: non-throwing fire

JakeA: soft-fire

wanderview: should put "annevk will do all this work"

JakeA: allready done. :)

<JakeA> https://github.com/w3c/ServiceWorker/issues/920

920 Navigation preload

JakeA: this is a feature chrome wants to ship pretty soon-ish

n8s: we are seeing improvements but that doesn't mean we're gonna see noticable improvements in stable

JakeA: we are waiting for more data from FB then?

n8s: we _are_ definitely seeing improvements, but nonconclusive
... I think the API is in a good shape

JakeA: feedback we got falken ?

falken: they see preload response as a perf thing and not something one wants to use on every navigation
... issue preload resolving to undefined, partner needs guarantees against that
... proposal of parner: browser should automatically use preload response if there was no respondwith

n8s: sounds too confusing, partner should just build it in their sw
... the preload response header will be set anyway

slightlyoff: partner is very concerned about reliability, so they want to funnel as few events through it as possible

wanderview: great to have fb and other real-world use cases

asuth: what is the usecase?

slightlyoff: they are using a sw for just logging, but proxying things through the sw and makes things slower (albeit having no actual logic in yet)

[..]: ?

n8s: pre-tpac we debated a lot and decided it was more confusing

pieter: we're confident we have mitigated issues in a sufficient depth that they become just normal "bugs"

falken: other implementors?

wanderview: still doing the rearch, we don't have objections

<kbx> KB: ideally, they would want to opt-in nav preload but only to mitigate cold startup issues. Disable when receiving the first preload response and re-enable before the SW dies.

<kbx> => 13:46 [..]: ?

JakeA: facebook would still work without this feature right?

n8s: yes but we don't want to roll out a perf regression

ali: at some point it will come, would be happy to see it

brady: no strong opinions

<JakeA> https://github.com/w3c/ServiceWorker/issues/1000



foreign fetch

Mek: origin trial
... not too much usage, but measured _some_ usage...

JakeA: facebook was looking at this?

n8s: I don't recall
... it looks interesting, probably be good for plugins and such but not there yet
... we're definitely interested on the long term, but not on the short term

<falken> ( kbx is speaking)

kbx: fonts usecase is still strong
... they want to store "pings" on the local service worker, and ping it back to the server in the background
... that one would need some kind of "timed alarm" which is not available currently

[discussion on timed alarm]

kbx: usecase: doing one's own stale-while-revalidate, making sure one's script in the head never blocks
... usecase: trying to get something from the network, that takes too long, serving a fallback response after the timeout

<JakeA> https://github.com/w3c/ServiceWorker/issues/878


JakeA: site can turn on credentials for some requests

[discussion that the functionality is not a Super Cookie as it is deleted when requested from the user, since the service worker obeys that]

[discussion on having double-keying's impacts]

wanderview: apple wants to put this off and rethink it
... I don't think it's reasonable to put this off untill all browsers out there support double keying
... since foreign fetch is a progressive enhancement, so it might not always be there

JakeA: so apple won't be able to ship it?

wanderview: or ship it and be less effective, and that's fine

Mek: it's already disabled if one disables 3rd party cookies in chrome

slightlyoff: this was raised by mozilla

<slightlyoff> (more to the point, we propose navigator.connect() and the reason we're here is because Mozilla requested an API of this style instead)

wanderview: I'm not trying to abdicate responsibility, but chrome has put way more effort into it and has more skin in the game
... I'm just concerned about tracking
... I have proposed static routing to solve the SW usecase

Mek: but it doesn't solve the font usecase
... e.g. subsets of fonts

wanderview: we didn't know about this usecase


slightlyoff: we're probably gonna have resource-usage based limit

wanderview: having a separate Realm would help in this case
... allow the realm 1 or N fetches

Domenic: navigator.connect had the same issues...

Mek: that was opt-in from the intercepted site

JakeA: but this is opt-in from the site itself
... says "I trust this site not building a botnet"

Domenic: it's worth exploring opt in, csp, maybe opt-out - let's just give annevk/apple time to come up with a better or alternate solution

tess: noone is shipping this (yet) so we are not in a hurry

slightlyoff: we _do_ want to ship this at some point though so a decision would be great

JakeA: we'd still want to have an origin trial?

falken: what data are we missing from the previous one?

kbx: nothing..?

JakeA: I got the impression we didn't get conclusive feedback

kbx: we got, from ~80%
... the google fonts team couldn't get the perf metrics since it was unaccessible in the service worker context

salva: [..]
... one shouldn't be able to reduce the security of the incoming request

slightlyoff: is that an existing issue?

wanderview: it's part of it

[chrome team argues the problem still applies in any case?]

wanderview: having a separate realm enables more ways of mitigation?

kbx: [..]

JakeA: and the opt-in helps there

Domenic: it's not just webfonts, but "make webfonts faster across the board"

tess: [..]

slightlyoff: and it's terrible, really really slow

kbx: to be fair it's gotten better

<slightlyoff> (it has gotten better)

asuth: one doesn't want images

JakeA: but css signals clear intent

slightlyoff: do we still filter images?

surma: [..]

Domenic: we should fix this

asuth: is there a navigator.connect post-mortem?

Domenic: we had a cool idea -- Mozilla said: we have a better idea -- domenic: "well it is kinda better"

JakeA: do we want to start whitelisting types?

Domenic: annevk has been collected a list, if we do want to do it it seems doable

<Domenic> In particular: https://fetch.spec.whatwg.org/#concept-request-destination

JakeA: so are we at the opt-in and enumerating type

wanderview: we have multiple issues, with multiple solutions, talking about them at the same time is confusing

Domenic: this would benefit from offline (as in async, gh-back-and-forth etc) brainstorming

wanderview: who is going to organize the follow-up discussion?
... it's complicated enough so we need to drive it forward

<JakeA> https://github.com/w3c/ServiceWorker/issues/877

tess: currently is pretty ambiuous why a sw is killed, how about exposing this data to the client?

Mek: we have discussed during background sync some "you were timed out event"

JakeA: like next time you boot up?

tess: yes

Domenic: this sounds like the "long tasks reporting" I'm working on
... it fits wit recent platform trends

tess: it's rather coarse, but it could be useful to share things

slightlyoff: navigation error reporting sounds similar and appears on the perf timeline

<slightlyoff> here's the latest NEL: http://wicg.github.io/network-error-logging/

slightlyoff: maybe we should use the NEL error header?

JakeA: some coalesced api would be nice

kbx: it's not just for navigation only

<Mek__> http://wicg.github.io/reporting/ is the generic reporting API

Domenic: action item: [figure out the contact points?]

wanderview: might be too much data?

<kbx> Contact points for Reporting API: Ilya Grigorik and Mike West

tess: no need to retain too much of this

n8s: it's pretty hard to debug or notice even
... it's definitely bit of a blind spot

asuth: should we have like histograms: you lasted this long and died of (memory usage|cpu usage|etc)
... also maybe report to browser vendors
... have it as an opt-in

n8s: sounds like we all agree we should address this blinds spot--question is how?
... one can end up in a feedback loop

flaki: maybe more declarative, during registration

slightlyoff: or a header

Mek: e.g. via the reporting api?

n8s: navigation timing is kinda an odd fit

JakeA: there was an error reported for update failures
... changed url

wanderview: not just that but mime type failures and etc

n8s: we do this intentionally often

wanderview: why?

n8s: sometimes we want to keep old sw version, and don't care about it when it happens intentionally
... you can catch all rejections inside the sw

Mek: you wouldn't have much time

n8s: 30s should be enough

asuth: one could just throw an AbortError if not interested in submitting the error

wanderview: we have gotten reports of people wanting to know more about this

kbx: one might need more access which only client-side processing could provide

<JakeA> https://github.com/w3c/ServiceWorker/issues/939#issuecomment-240135914

wanderview: with a perfectly-written sw this wouldn't happen but when someone pushes a bad service worker...

JakeA: coming up!
... suggestion from a chrome eng: an event that fires on the service worker when the page displays an error

n8s: we love the idea
... we have made a polyfill, using indexdb pinging the service worker that can get us an approximation of this data
... the data is not perfect but already pretty useful

pieter: normally we have to wait until ppl tell us the page is crashing

falken: the client goes away at this point...

n8s: yes first step is to get the info, but then potentially try to recover

Mek: automatic recovery might be not desirable here

n8s: showing some ui, e.g. "try to recover" button could be helpful though

JakeA: the refresh button is always there

n8s: maybe we want a spinner that would wait for the sw to try to recover

pieter: the developer cannot be sure it won't crash again

n8s: probably browsers should only offer recovery once

wanderview: in firefox, multiple tabs run in a single process, so it might have been an another tab that caused the actual crash

slightlyoff: for sites that's as big as fb this should not be an issue

wanderview: more talking about the recovery
... that said, this might be possible but after the rearchitecture

n8s: sure

JakeA: does 404 etc. error pages count here?

n8s: crashes are more interesting to us in this case

JakeA: if we do, we should provide appropriate context

slightlyoff: updating {title|favicon|etc} from the service worker (upon push/bg sync)

JakeA: why not just postmessage?

slightlyoff: resource usage gains, eg tab should remain in a dozing state (maybe put to disk etc)

Domenic: is this just for desktop?

JakeA: sometimes this works on android, e.g. a custom app icon

n8s: most non-Google android has it
... there's also an issue of updating the title, but then upon tab switch the content not having been updated
... (do to postmessage being queued still etc..)

Domenic: do we do mobile/desktop together?

JakeA: they're different enough, on mobile we have "apps" on desktop we have "tabs"

slightlyoff: I'm happy to write something up

flaki: maybe we could have like a method that updates "page metadata" with an object with different keys

Domenic: we have to decide if this is appwide or tabwide

n8s: this could just live on the Clients API

brady: we are in, we want to see a spec
... we are also not interested in any scriptable ways to update in favicon

slightlyoff: would providing a "badge count" be okay?

<JakeA> https://github.com/w3c/ServiceWorker/issues/1087#issuecomment-290705968

tess: we have a badge count api so that should work

JakeA: what's the issue with favicons?

<hober> https://notifications.spec.whatwg.org/#badge-url

brady apple doesn't support any updates to the favicon

Domenic: not even data url hacks?

brady: nope

<JakeA> https://github.com/w3c/ServiceWorker/issues/614

wanderview: we even have a test in-between testruns that fails immediately if we have any service worker registered on any origin

Mek: maybe update web platform test harness to have async cleanup callbacks where you wait for their promise to resolve before moving on to the next test

falken: test harness already lets one access chrome-internal functions

[discussion on event.waitUntil and being able to rely on the service worker not being killed of for "a reasonable amount of time"]

JakeA: the spec is vague and we need to address this when we do time handling and passing around

<JakeA> https://github.com/w3c/ServiceWorker/issues/839

tess: we need guarantees both for "you got to be executing for at least this long" and both "you will be definitely killed of if you keep executing beyond..."

wanderview: wrote and reviewed patches, should land in 55 ideally

falken: currently we cache by default

JakeA: are we going to melt facebook?

falken: not facebook. any other sites?
... we don't have the exact data to know
... it's also hard to know the exact sites (for evang), if they in fact melt

kbx: we could try a phased roll out (for canary maybe) to make sure we don't break things

JakeA: next meeting?
... maybe better to have at least one more focused/teleconference?

next meetings

wanderview: maybe it's better to not phrase it around "n times a year" but shipping (e.g. after Edge ships?)

JakeA: we might have mkwst at TPAC again?

wanderview: we're at a point where before implementing new platform stuff we write wpt


wanderview: we don't need to be at a big-bang meeting

JakeA: how about august?

tess: first week of august is CSSWG

<falken> (wanderview was responding to a suggestion about holding a meeting focused on WPT)

ali: we should address these issues online (and prepare for the meeting)

JakeA: we might need a meeting where we organize meetings! \o/
... V1 status?

jungkees: slowly toiling away on issues, but also we're gonna file some after today
... if we want them to get resolved before shipping we either need to push them out or split them out

ali: we are tracking V1
... it might be worth to split stuff out (that's contentious, in origin trial etc)

JakeA: I'm worried about locking V1 down
... what if what ships turns out not to be in a good shape

slightlyoff: V1 is what eventually will ship

JakeA: I'd rather freeze V1 and have it at whatever ships eventually


import scripts

JakeA: we're moving onto a more modular world, we should spend more time on this

slightlyoff: getting the top-level script fixed is *good*

JakeA agrees

wanderview: usecache equals import default?

JakeA: like the idea
... the declarative imports will be checked on first launch, and will be checked on updates

Domenic: it sounds strange from a module standpoint, but you already do this for importScripts

JakeA: is usecache the right language?
... this is more about rechecking the script resources

wanderview: my take is we always include importScripts in the byte-for-byte check but we use the cache
... we hope to ship our usecache impl in the following weeks
... but I want to shift that boolean into an enum before we ship (maybe could even uplift)
... this is for toplevel
... we need to agree on what the default value should be

JakeA: n8s (representative of ALL developers around the world), what do you think??

n8s: fine.

JakeA: \\\o///

falken: should we think about es6 modules when we design usecache?

Domenic: yes, it would be advisable -- happy to coordinate

wanderview: we're gonna have different policies on toplevel script and dependent scripts

salva: and check for headers

wanderview: it's a revalidation, that uses eTags

JakeA: yes it's a "nocache" request (on cache api's terms)

wanderview: we probably won't ship our bypass cache in 53

JakeA: yes it was a late thing
... library authors will need to be setting the header...

Mek: they get the byte-for-byte check by default anyway

JakeA: true


Domenic: want to talk about cacheable resources

<JakeA> https://github.com/w3c/ServiceWorker/issues/962

Domenic: implementations event with service worker differ in implementation


Domenic: we have to somehow tackle the cache thing

JakeA: are you suggesting us speccing a handwavy "browsers may..."

Domenic: could do that, but also could just spec it

yhirano__: I think is nothing specified we should use http cache semantics

slightlyoff: memory cache doesn't respect caching headers, because we found we want to very much cache these resources

surma: compared different scenarios, bold means "the average developer would be surprised by this"
... it's very hard to predict what happens when doesn't have this table at hand

Domenic: it's a mess
... how does it impact service workers?

JakeA: wanderview said firefox would go to the memory cache
... but that's not specced

wanderview: yes our impl does not comply spec and reuse images from across documents
... these optimizations gave order-of-magnitude improvements
... we could just use headers, and SW would put headers on the responses

slightlyoff: what do we doe in chrome?
... is it disabled?

falken: not disabled, but we use a different memory cache for pages using serviceworkers

yhirano__: but it's also nonspecced behavior

wanderview: allowing the service worker participating in higher level caches is one effort, laying the specwork could be a different effort

Domenic: laying these on such a shaky foundation doesn't feel right...
... ...but also I don't see terrible compat risks here either
... it's little surprising that we are not fixing all issues first

wanderview: it's more "separation of concerns", rather

Domenic: we're exposing unspecced/nonstandard behavior to service workers, but before we exposed this to the http service

wanderview: we fixed our image caches because someone complained about the surprising behavior
... "I should be receiving a fetch--and I'm not"

Domenic: how come we are not seeing more complaints about other caches..?

JakeA: developers don't really understand caches in depth

kenjibaheux: well we never talked about client-side caches, mostly just server-side (re: headers etc)

wanderview: if the service worker updates one should evict all those caches

Domenic: behavior should get specced soon(tm)

JakeA: our designated developer..?

chaals: not designated, but representing ALL developers in the world

n8s: *nods*

wanderview: bfcache..?

flaki: do we need to expose b/f cache to the service worker?

wanderview: one could opt out via the same, to-be-specced mechanism

JakeA: we need to look at these

wanderview: if we could turn image caches back on that would be great

JakeA: last requests?

Domenic: [fixing top-level events after initial evaluation?]

JakeA: yes we should look into that.
... Thanks Facebook for hosting. Thank you all for showing up.

<chaals-ordhord> [Thanks to Nate/Peter/Kate and Facebook for hosting, thanks to Flaki for notetaking]


Summary of Action Items

Summary of Resolutions

    [End of minutes]

    Minutes formatted by David Booth's scribe.perl version 1.152 (CVS log)
    $Date: 2017/04/12 05:55:02 $