07:33:24 <RRSAgent> RRSAgent has joined #webapps
07:33:24 <RRSAgent> logging to http://www.w3.org/2016/09/20-webapps-irc
07:33:34 <Zakim> Zakim has joined #webapps
07:33:53 <xiaoqian> zakim, this is TPAC Service Workers meeting
07:33:53 <Zakim> got it, xiaoqian
07:37:22 <IanPouncey> IanPouncey has joined #webapps
07:40:39 <smaug> smaug has joined #webapps
07:42:05 <LJWatson> LJWatson has joined #webapps
07:43:54 <anssik> anssik has joined #webapps
07:47:54 <weinig> weinig has joined #webapps
07:49:59 <jungkees> jungkees has joined #webapps
07:51:06 <falken> falken has joined #webapps
07:51:53 <makoto> makoto has joined #webapps
07:52:23 <makoto> makoto has left #webapps
07:52:36 <shimazu> shimazu has joined #webapps
07:53:39 <MichaelC> MichaelC has joined #webapps
07:54:10 <jamesn> jamesn has joined #webapps
07:54:15 <Florian> Florian has joined #webapps
07:58:08 <Gus__> Gus__ has joined #webapps
07:59:12 <rniwa> rniwa has joined #webapps
08:01:43 <xiaoqian> chair: chaals
08:02:44 <Todd> Todd has joined #webapps
08:02:48 <tantek> tantek has joined #webapps
08:03:03 <xiaoqian> present+ jakeA, jungkees, hober, weinig, chaals,
08:03:20 <kborchers> kborchers has joined #webapps
08:03:42 <taekyu> taekyu has joined #webapps
08:06:04 <lilin_> lilin_ has joined #webapps
08:06:06 <hjlee> hjlee has joined #webapps
08:10:06 <chaals> chaals has joined #webapps
08:10:14 <jungkees> https://github.com/w3c/ServiceWorker/issues/974
08:10:18 <bz> bz has joined #webapps
08:10:41 <chaals> scribe: chaals
08:10:46 <ericc> ericc has joined #webapps
08:10:54 <chaals> Topic: angenda-bashing
08:11:45 <dom> dom has joined #webapps
08:11:46 <Byungjin> Byungjin has joined #webapps
08:11:59 <Todd_> Todd_ has joined #webapps
08:12:02 <WalterTamboer> WalterTamboer has joined #webapps
08:12:24 <bz> What's the link to the stuff we're looking at right now?
08:12:30 <chaals> CMN: Please make sure you are signed up to the group if you're contributing substantive content.
08:12:56 <chaals> Topic: V1 update
08:13:17 <chaals> Jungkee: we've got 24 issues, half solved and need to be edited in, so the agenda issue has the rest.
08:13:47 <jungkees> https://github.com/w3c/ServiceWorker/issues/816
08:14:49 <chaals> … there are a couple of issues, already decided-ish: 816
08:14:51 <hjlee_> hjlee_ has joined #webapps
08:15:03 <chaals> … same object cannot be used for union type in IDL
08:15:18 <jungkees> https://github.com/heycam/webidl/issues/71
08:15:19 <chaals> … filed in WebIDL as an issue. Want to check the status.
08:15:39 <chaals> BZ: This is an IDL bug that should be fixed - just assume it will happen.
08:15:43 <chaals> JS: OK
08:15:44 <jcraig> jcraig has joined #webapps
08:16:00 <RRSAgent> I have made the request to generate http://www.w3.org/2016/09/20-webapps-minutes.html xiaoqian
08:16:30 <jungkees> https://github.com/w3c/ServiceWorker/issues/873
08:16:34 <chaals> Topic: 873
08:17:07 <chaals> JS: related to fetch. we have API that can probably use fetch event cache attribute.
08:17:09 <kbx> kbx has joined #webapps
08:17:38 <chaals> AvK: This is for normal reload stuff? not shift?
08:17:54 <chaals> JA: We don't get shift through the service worker.
08:18:01 <chaals> AvK: Why do we want this
08:18:08 <chaals> JA: Alex made the case...
08:18:11 <kborchers> kborchers has joined #webapps
08:18:27 <chaals> BZ: navigating to yourself is semantically different to reloading yourself - at least sometimes.
08:18:33 <chaals> SW: cache strategies are different.
08:18:43 <plh> plh has joined #webapps
08:18:54 <chaals> JA: If you trigger reload you *might* move from offline-first to online-first …
08:19:04 <chaals> … cache mode of the request would reflect that
08:19:08 <chaals> AvK: Hmmm.
08:19:23 <jungkees> This is exactly this issue: https://github.com/w3c/ServiceWorker/issues/875
08:19:23 <chaals> JA: Won't go to cache on reload, will re-validate.
08:19:31 <chaals> AvK: Do we want to expose that?
08:19:41 <chaals> … would need a hidden flag.
08:19:45 <chaals> JA: Why hide it?
08:19:54 <chaals> AvK: Then script can bypass the action...
08:20:03 <chaals> JA: service workers *do* that.
08:20:26 <chaals> JS: In normal reload serviec worker can do what it wants. For full reload it should bypass the service worker.
08:20:34 <chaals> JA: We already have that.
08:21:09 <chaals> … with cient API we know the page that triggered the request is the same as the URL you are asking for.
08:21:15 <chaals> s/cient/client/
08:21:22 <chaals> … does cache mode reflect this?
08:21:35 <chaals> AvK: May be implementation-specific what reload does.
08:22:22 <chaals> ??:If you hit the button we may have different things we do. It's up to the UA to decide what to do, but we want to match the service worker process.
08:23:22 <chaals> JA: We should reflect what the user wants to do. If you follow a live feed, and you hit reload, you might want to get the new stuff off the network, not the cache.
08:23:53 <chaals> JA: We have cache mode where you can skip the HTTP cache…
08:24:11 <chaals> … think the cache mode should reflect what the browser thinks it is doing.
08:24:33 <chaals> AvK: So UX reload, navigation to self, and location.reload can be different?
08:25:06 <chaals> KB: We currently have two kinds of behaviour, but we want to have just one
08:25:18 <chaals> SW: I'd have to write a test to see exactly what we do.
08:25:54 <chaals> … think we revalidate main resource if you hit return in the address bar, and reload button validates sub resources on cache.
08:26:21 <chaals> Salvador: There should be a way to say "this reload is meant to bypass the cache."
08:26:54 <chaals> JA: If browsers do different things - it isn't specced - we can expect different behaviours. Do we want to expose a user intent to refresh?
08:27:46 <chaals> JA: Is this a feature that is useful?
08:28:05 <kborchers_> kborchers_ has joined #webapps
08:28:19 <chaals> AvK: We can define location.reload in one way or another. If we reflect that in cache mode that would be easy, then suggest the UI gestures should behave in the same way.
08:28:35 <chaals> N8: Yep.
08:28:46 <chaals> JS: Can we drop the reloaded thing then?
08:28:47 <MichaelC_> MichaelC_ has joined #webapps
08:29:12 <IanPouncey> IanPouncey has joined #webapps
08:29:16 <aboxhall> aboxhall has joined #webapps
08:29:29 <chaals> JA: If browser decides what a reload button does, do you want the website to follow howthe browser intends its UI to work, or do you want to know what the user asked?
08:29:49 <chaals> N8: We want to know what the browser is going to do in regards to how it will treat the HTTP cache.
08:30:02 <chaals> JA: So that would be enough to replae the isReload property?
08:30:29 <chaals> AvK: We don't need to define shift-reload, but if normal reload affects resources then we need an inheritane model to store cache mode
08:30:44 <chaals> JA: Browser does this already, so it's just a hook in the spec to keep that data.
08:30:59 <jungbin> jungbin has joined #webapps
08:31:25 <chaals> AvK: if location.reload only reloads the main resource, then you only need to handle that request not a fetch-group policy
08:31:47 <chaals> JA: Should it be in spec?
08:31:55 <chaals> AvK: There's no API for it, so no...
08:32:50 <bkardell_> bkardell_ has joined #webapps
08:33:37 <chaals> AR: isReload can't be killed...
08:33:43 <chaals> JA: But this does it instead.
08:33:52 <chaals> … look at request.cache ...
08:34:00 <chaals> AR: This is the ugliest way to do it.
08:34:51 <chaals> … this is reload plus top-level navigation.
08:35:20 <chaals> JA: You see browser intent here. It's consistent for document reloads.
08:35:23 <chaals> AR: OK.
08:35:28 <chaals> … It's still ugly.
08:36:02 <chaals> AvK: Not sure if this is a comon pattern - if it is we could add a shortcut
08:36:12 <chaals> AR: Use case: Google Docs team
08:36:22 <chaals> … needs to know.
08:36:36 <chaals> SW: There are at least 4 different kinds of reload…
08:36:40 <chaals> BZ: 5
08:36:53 <chaals> SW: Each browser has different behaviour for all of these.
08:37:14 <chaals> AR: We said that if you were going to bypass the cache you should bypass the service worker.
08:37:31 <chaals> AvK: Doesn't happen for location.reload
08:37:35 <rniwa> rniwa has joined #webapps
08:37:54 <chaals> … there you go through the worker but not cache.
08:38:54 <chaals> SW: We should try to understand how browsers handle reload, in the future
08:39:04 <kborchers> kborchers has joined #webapps
08:39:27 <annevk> bz: https://github.com/whatwg/html/issues/1742
08:39:28 <lilin_> lilin_ has joined #webapps
08:39:39 <jungkees> https://github.com/w3c/ServiceWorker/issues/875
08:39:44 <chaals> Topic: Issue 875
08:39:58 <chaals> JS: This is covered by what we discussed.
08:41:23 <chaals> Topic: Issue 870
08:41:37 <chaals> -> https://github.com/w3c/ServiceWorker/issues/875 Issue 875
08:42:08 <chaals> JS: There is no concept like reserved client ID. We designed a reserved client ID to reference target client environment of a request.
08:42:28 <oh9405> oh9405 has joined #webapps
08:42:33 <chaals> … expose this as source / target of a fetch.
08:43:01 <chaals> … was having a hard time speccing this, because the HTML navigation doesn't have a concept like this.
08:43:33 <chaals> … When a navigation is triggered we have to create some state that holds the ID, URL and origin of the request to pass into fetch.
08:44:31 <sangchul> sangchul has joined #webapps
08:44:45 <chaals> … propose fetch have a client, passed through end of fetch, that developers can use. Fetch returns to HTML and HTML creates the status object. Plan is to override the ID at the end, we're discussing the design now.
08:45:21 <chaals> .. AvK thinks the design is a bit odd. I need the client ID…
08:45:36 <chaals> AvK: New info is that you need a reserved ID.
08:45:44 <chaals> s/.. AvK/… AvK/
08:45:55 <chaals> … we should just add the ID and pass it on the request.
08:46:10 <chaals> … then you make a collection of IDs and settings objects.
08:46:43 <chaals> … An environment settings object without a global object or realm, is pretty weird…
08:46:58 <chaals> … So change the API to also operate on reserved IDs instead.
08:47:23 <chaals> JA: So under the hood there is onformation coming from different places…
08:47:33 <rniwa_> rniwa_ has joined #webapps
08:47:37 <chaals> AvK: Right - either reservedID or an environment settings object.
08:47:42 <chaals> JA/JS: OK
08:48:25 <chaals> JS: So we need to refer to targetn client ID. It's browsing context, because we need to refer to UI properties, for use in the service worker
08:48:36 <chaals> AvK: What info?
08:48:45 <chaals> JS: Visibility state, focus state.
08:48:59 <chaals> AvK: That's in browsing context or document?
08:49:12 <chaals> JS: I capture that info during method call.
08:49:33 <chaals> AvK: What about target window object not browsing context. You can check if it is active, or abort.
08:49:43 <chaals> JS: Target client should be a regular client.
08:50:14 <chaals> AvK: There will be differnce where there is another navigation, and they race.
08:50:34 <chaals> JA: When you click a link and there is a target as iframe or window.
08:51:03 <jamesn> jamesn has joined #webapps
08:51:06 <chaals> AvK: Represent target by current active document, whatever that is at the time you check.
08:51:21 <chaals> JA: WOud be weird for the ID of a client to change ...
08:51:30 <chaals> AvK: not in browsing context.
08:51:48 <chaals> … why not pass the info before you enter, and not going back and forward.
08:52:10 <aliams> aliams has joined #webapps
08:52:14 <chaals> JS: We capture the info in the client's context, create object in service worker. So it doesn't cross.
08:52:25 <chaals> AvK: Yes, you do when fetch goes async.
08:52:40 <chaals> … better to pass that to fetch from the start.
08:52:48 <chaals> JA: This proposal is to do that.
08:52:57 <chaals> AvK: No. This is reserved.
08:53:14 <chaals> JA: We suggest both. 3 IDs on the fetch.
08:53:19 <jmann> jmann has joined #webapps
08:53:32 <hjlee> hjlee has joined #webapps
08:53:57 <chaals> JS: We hvae to go to client context to get visibility state. So we capture that from client context, service worker is waiing on the state, intialises it with what we captured.
08:54:11 <plh> plh has joined #webapps
08:55:19 <cabanier> cabanier has joined #webapps
08:55:20 <chaals> JA: There is a task to get the properties, but the IDs just live on the fetch event. At one point we have client objects on it, but that was really heavy.
08:55:44 <chaals> JS: Problem that client we get later could be different
08:55:47 <chaals> JA: Already can.
08:55:58 <chaals> JS: We can capture ID during creation.
08:56:10 <chaals> JA: The client might be gone when you look for it, but you have the IDs
08:56:30 <chaals> JS: Need both the browsing context and the ID …
08:56:36 <IanPouncey> IanPouncey has joined #webapps
08:56:59 <chaals> JS: So, how to design this - an we do superclassing for those two?
08:57:36 <chaals> AvK: ID is a new field on environment settings object. You could have a base class with ID, and env.settings is a subclass with more fields.
08:57:58 <chaals> … sounds OK, if it's OK with Domenic.
08:58:11 <chaals> JS: OK, I'll discuss that outside.
08:58:18 <jmann_> jmann_ has joined #webapps
08:59:33 <nainar_> nainar_ has joined #webapps
09:01:18 <chaals> I am a fish
09:01:27 <chaals> rrsagent, draft minutes
09:01:27 <RRSAgent> I have made the request to generate http://www.w3.org/2016/09/20-webapps-minutes.html chaals
09:03:40 <wilsonpage> wilsonpage has joined #webapps
09:05:42 <bz> bz has joined #webapps
09:05:48 <Florian_> Florian_ has joined #webapps
09:13:30 <MichaelC_> MichaelC_ has joined #webapps
09:13:46 <Florian> Florian has joined #webapps
09:14:32 <plh_> plh_ has joined #webapps
09:19:27 <Florian_> Florian_ has joined #webapps
09:21:47 <chaals> chaals has joined #webapps
09:22:09 <chaals> Topic: Longdesc
09:22:17 <chaals> Issue 873
09:22:32 <chaals> JA: It's important to have the fist client by creation time.
09:22:40 <kbx> kbx has joined #webapps
09:22:45 <chaals> … seems to make sense to focus the most recent one
09:22:51 <chaals> SW: I think we will be fine
09:22:58 <chaals> N8: think that is OK.
09:23:06 <chaals> JA: Doing it by focused order will be a bigger task
09:23:13 <chaals> SW: Yeah, but not that big.
09:23:20 <chaals> JM: What's the value?
09:23:42 <chaals> JA: If you've got a window that's been sitting three days, and another that you were using 5 minutes ago, pick that one…
09:23:54 <chaals> AvK: Most recently focused same-origin?
09:24:21 <chaals> SW: Yep. We could find most-recently focused of all origins, ...
09:24:25 <chaals> JA: Seems easy.
09:24:34 <chaals> … we track focus ordering for everything.
09:24:46 <chaals> SW: We recently added a lot more timestamped tracking.
09:25:25 <chaals> JM: Yes, this is OK.
09:25:46 <chaals> SW: We're OK with this.
09:26:25 <LJWatson> LJWatson has joined #webapps
09:26:53 <chaals> s/873/887
09:26:53 <jungbin> jungbin has joined #webapps
09:27:04 <chaals> Topic: Issue: 893
09:27:38 <chaals> JA: We agreed on this. Lots of long max-age for JS resources. We cap it for 24 hours already, but it's a real gotcha.
09:27:48 <slightlyoff> https://github.com/w3c/ServiceWorker/issues/893
09:28:02 <chaals> … we're planning to make it always revalidate with a way to opt back into cache, and that's the bit we are missing.
09:28:07 <Byungjin> Byungjin has joined #webapps
09:28:14 <chaals> AR: Still capping on 24 hours?
09:28:18 <chaals> JA: Yes.
09:28:30 <chaals> JS: Change this for v1?
09:28:31 <weinig> weinig has joined #webapps
09:28:32 <chaals> JA: Yes.
09:28:48 <chaals> JS: Suggest install API not register option?
09:28:59 <chaals> AvK: Seems good.
09:29:03 <chaals> JA: Yeah...
09:29:14 <chaals> … [thinks]
09:29:26 <chaals> … lots of options are on registration - it's a choice of the two
09:29:38 <chaals> AvK: prefer install, so you don't need to remove and add.
09:29:52 <dom> dom has joined #webapps
09:30:06 <chaals> JA: If it's on registration you could set it in install. Benefit of install is you can have a default that takes over if a new service worker doesn't have an opinion.
09:30:22 <chaals> N8: Can you read it later if it is on install?
09:30:33 <chaals> JA: Probably not. On registration it's set and forget…
09:30:57 <chaals> N8: Can't think why we would want to use the value later, but think people are going to want that...
09:31:10 <chaals> AvK: Why couldn't you still expose this on register?
09:31:23 <chaals> … do you need to unregister?
09:31:31 <rniwa> rniwa has joined #webapps
09:31:39 <chaals> JA: Scope is primary key, you can change values without unregistering.
09:31:45 <chaals> AR: You do get a new registration.
09:32:13 <chaals> JA: If you change URL you get an update. Otherwise tehre is a noop. So feels like it should sit on registration
09:32:13 <jmann> jmann has joined #webapps
09:32:31 <chaals> [yeah whatevs]
09:32:44 <chaals> AvK: We don't have a good strategy for choosing between register and install.
09:32:57 <chaals> JA: Would like to remove foreignFetch from install...
09:33:07 <chaals> AR: There are those two and activate as places to put stuff.
09:33:45 <MichaelC> MichaelC has joined #webapps
09:33:47 <chaals> chaals has joined #webapps
09:33:50 <plh_> plh_ has joined #webapps
09:34:01 <rniwa> rniwa has joined #webapps
09:34:11 <dom> dom has joined #webapps
09:34:23 <chaals> AR: Thought if caches should be tied to the worker. Desgined it against that. There isn't a lot of state hanging around on register or service worker. relationship is dynamic.
09:34:37 <chaals> JA: If it lives as long as registration it needs to go on the registration object.
09:34:53 <chaals> … don't think we should put too much on actiavte because that casuses blocking.
09:34:58 <kbx> kbx has joined #webapps
09:35:37 <LJWatson> LJWatson has joined #webapps
09:36:01 <xiaoqian> xiaoqian has changed the topic to: TPAC Service Workers meeting - https://github.com/w3c/ServiceWorker/issues/974
09:36:08 <weinig> weinig has joined #webapps
09:37:33 <chaals> [blue! Green! …]
09:38:37 <chaals> AvK: We can start with true as a keyword, and add an enum if we ever need to.
09:38:55 <chaals> Topic: path to CR
09:39:37 <chaals> JS: We're planning to publish the FPWD for v2 now to get the latest features, and publish a draft for v1 heading to Rec.
09:39:42 <hjlee> hjlee has joined #webapps
09:39:50 <chaals> … my question is if we can skip an exclusion.
09:40:05 <chaals> … until the next version. We did it with CR of the next spec.
09:40:24 <chaals> … purpose is to see the gap between the CR and the latest draft of v2
09:40:42 <chaals> … this can produce quite a lot of burden maintaining two versions.
09:41:16 <xiaoqian> chaals: once you publish the CR, you don't want to change it any more
09:41:41 <xiaoqian> ... when you make a FPWD, you have to start a CFE
09:42:02 <xiaoqian> ... people have 60 days from the day of CR for exclusion
09:42:20 <xiaoqian> ... you must have those two CfE
09:42:39 <xiaoqian> ... CR is your nightly
09:43:07 <kbx> kbx has joined #webapps
09:43:44 <xiaoqian> Yves: You might like to put a link to latest version
09:43:58 <xiaoqian> ... which should fit in the model for SW
09:45:08 <xiaoqian> ... the min time to move a spec to REC (?) is 6 months
09:45:33 <xiaoqian> slightlyoff: you can maintain two branches
09:45:42 <xiaoqian> ... one is the latest
09:45:46 <xiaoqian> ... one is the stable
09:46:39 <xiaoqian> JakeA: we have nightly for v1, which is the one missing foreign fetch
09:47:01 <xiaoqian> Yves: you can focus on updating the latest, once you have something stable, put it to ...
09:47:24 <xiaoqian> jungkees: let's go with adrianba's proposal
09:47:36 <xiaoqian> JM: we have a v1...
09:48:28 <xiaoqian> jungkees: /TR/ServiceWorkers always refers to the latest
09:48:30 <chaals> scribe: chaals
09:48:34 <chaals> Topic: 879
09:48:40 <chaals> JA: We'll do this after v1
09:48:47 <Yves> naming nit, I would prever "level 1" over "v1", but that's up to the grop
09:48:50 <chaals> Topic: 703
09:49:01 <chaals> JA: This is security and work.
09:49:31 <chaals> … HTML doesn't talk about range requests but browsers do it. We can't do it in service worker we need this in HTML and they need to defend against ranges from multiple origins.
09:49:39 <chaals> SW: We ran into this with service workers.
09:50:02 <chaals> … range requests plus CSP plus media engines == bad time.
09:50:14 <chaals> … so, agree. Needs to be dealt with in HTML
09:50:22 <chaals> JA: Not blocking for v1
09:50:25 <aliams> aliams has joined #webapps
09:52:08 <chaals> JS: We're done now for this?
09:52:22 <chaals> JA: Yep. Service worker can't do this, so we need it in HTML.
09:52:50 <chaals> AvK: Seeing range requests for images now.
09:52:58 <chaals> JA: Chrome can be persuaded to do it for CSS…
09:53:41 <chaals> Topic: HEIST
09:54:15 <chaals> JA: Heist was revealed - series of attacks where we provide info about size of a x-origin resource when we shouldn't.
09:54:41 <chaals> … e.g. a search will be a different size if there is a match or not, detectable through timing or cache-based attacks.
09:55:19 <MichaelC> MichaelC has left #webapps
09:55:43 <taekyu> taekyu has joined #webapps
09:56:37 <smaug> smaug has joined #webapps
09:56:47 <chaals> … Ryan Sleevi said we should stop trying to fiddle the edges, and block at the source. Would be opt-in, e.g. using mike west's proposal for same site cookies.
09:57:22 <chaals> BH: No great soluton, like Ryan's intuition. Almost impossible to beat these side channels because it is hard to disguise elephants as mice.
09:57:31 <IanPouncey> IanPouncey has joined #webapps
09:57:56 <chaals> … shouldn't expose privacy-differentiated data gives up on a lot of what we expect from teh same origin policy, involves pretty serious changes in how we use the web.
09:58:18 <chaals> … would like to find other ways to provide systematic answers that make it harder to get high-precision views from side channels.
09:58:38 <chaals> … randomisation is a strategy. Defeatable by statistical samples.
09:58:49 <chaals> … bucketising things?
09:59:41 <chaals> … this would have a big impact.
09:59:50 <chaals> AvK: This has been broken for a long time, right?
10:00:17 <chaals> BH: Yep. We have access control for timing to set resolution of views available.
10:00:49 <chaals> AvK: we're trying to minimise storage attacks - we've made estimating sizes easier.
10:00:58 <chaals> AR: We have that already.
10:01:36 <chaals> SW: What's the use case for x-origin storage in search cache
10:01:59 <chaals> AR: Website includes 3rd party JS. We don't want the responses for that to be exposed.
10:02:23 <Florian> Florian has joined #webapps
10:02:49 <chaals> JA: We culd say put CORS on your CDNs. Might work…
10:03:10 <chaals> … if your CSS is on CDN there is no way to request a background image with CORS
10:03:25 <chaals> AvK: We made a big effort to cache things…
10:03:36 <chaals> AR: If you're not doing anything in service worker, it's a noop.
10:03:54 <chaals> JA: upgrading CSS to CORS is a wrapping issue.
10:04:18 <chaals> SW: Should we have been explicit about resources you can cache being cached x-origin?
10:04:51 <chaals> [What the web would like like if we made it tomorrow…]
10:06:38 <chaals> JA: Mike you are disagreeing with opt-in solutions?
10:06:54 <chaals> MW: Would be nice if we could do something else - but we haven't figured out what that could be yet.
10:07:05 <chaals> … you have timing attacks, and those are hard to fight.
10:07:21 <chaals> … bucketise or reduce data granularity.
10:07:35 <chaals> … and there are explicit things like quota giving data.
10:07:59 <rniwa_> rniwa_ has joined #webapps
10:08:07 <chaals> … have we considered applying quotas based on origins?
10:08:31 <chaals> AR: Value of cache API is that you know what is in it. That's the property we want to preserve. We want to be able to have 3rd party things in it.
10:08:52 <chaals> AvK: Then you get persisitent storage, and if the quota doesn't count against yourself, who does it count against?
10:09:03 <chaals> AR: If you evict today you evict the entire cache not one entity
10:09:30 <chaals> MW: We give a handle to a resource, that might be in someone else's cache. You lose the reference, but the other guys do.
10:09:37 <chaals> … or we do some GC-like approach.
10:10:20 <chaals> AR: You need to know when you are going to have a write failure. I write into a cache as a 3rd party, I'm near the limit and want to write something too big. Do i have a write error?
10:10:43 <chaals> MW: Yes. But you wont know the size of the 3rd party cache.
10:10:50 <tantek> tantek has joined #webapps
10:10:51 <chaals> [yes, if you filled it up to start with...]
10:11:49 <chaals> MW: I see it as a better problem to solve, and if we assign blame for putting things into a cache we can deal with the issue.
10:12:12 <chaals> SW: We do something like this already…
10:12:28 <chaals> MW: Think this would be the inverse, allowing one origin to put things into another one.
10:12:55 <chaals> SW: Sure, but technique is the same
10:13:25 <chaals> JA: Think the storage issue can be dealt with by padding, but timing attacks are harder...
10:13:34 <chaals> BH: They an be solved to a certain resolution.
10:13:44 <chaals> Brad is sad. 3 ways.
10:14:23 <chaals> … would hate to take away a whole class of functionality.
10:14:56 <rniwa_> join #webdriver
10:14:58 <chaals> … Can we let people opt in, and then give people choices to do work to get more perf or security.
10:16:05 <chaals> s/join #webdriver//
10:16:30 <chaals> JA: If we have same-site cookies and let requests opt out via CORS preflight, does that solve it?
10:16:52 <chaals> BH: Nope. Don't want random 3rd party sites make requests to things and learn about them
10:17:39 <chaals> … want to show differentiated content without leaking data about which user is there.
10:20:25 <chaals> [frames, framebusting. There are use cases for wanting to be, or not be, framed]
10:21:03 <chaals> MW: If you have no-opener, you get problems knowing if you're framed, and where.
10:21:41 <chaals> ES: Giving you no-opener but having ancestor origin gets around a bunch of that.
10:22:13 <chaals> AR: To what extent is this a service worker problem?
10:22:20 <chaals> JA: It's an img problem.
10:22:48 <Zakim> Zakim has left #webapps
10:23:11 <Zakim> Zakim has joined #webapps
10:23:40 <bz> bz has joined #webapps
10:28:43 <chaals> [break - 15 minutes]
10:28:58 <xiaoqian> present+ Salvador, Kris_Borchers, Nathan_Schloss, yoav, Brad_Hill, annevk, Kenji, ilya, bz, Alex_Russell, yves, xiaoqian, toddreifsteck, Jatinder_Mann, Mike_West, Joshua, esprehn,
10:29:06 <xiaoqian> RRSAgent, make minutes
10:29:06 <RRSAgent> I have made the request to generate http://www.w3.org/2016/09/20-webapps-minutes.html xiaoqian
10:31:16 <jcraig> jcraig has joined #webapps
10:35:52 <Todd> Todd has joined #webapps
10:36:20 <jamesn> jamesn has joined #webapps
10:40:57 <jnurthen> jnurthen has joined #webapps
10:47:37 <Florian> Florian has joined #webapps
10:49:48 <kbx> kbx has joined #webapps
10:50:33 <chaals> chaals has joined #webapps
10:52:29 <chaals> Topic: storage…
10:53:36 <hjlee> hjlee has joined #webapps
10:53:44 <chaals> Topic: Uploading
10:53:55 <chaals> issue - fetch-with-streams 66
10:54:30 <aliams> aliams has joined #webapps
10:54:35 <chaals> DomenicD: problem - what if you upload to endpoint and get a redirect?
10:54:40 <aliams> present+
10:55:01 <chaals> … or asked for credentials. These are realistic scenarios…
10:55:08 <kbx> https://github.com/yutakahirano/fetch-with-streams/issues/66
10:56:03 <Yves> present+
10:56:04 <chaals> … could say "redirect-mode error", otherwise you get the problem…
10:56:10 <chaals> present+ chaals
10:56:47 <chaals> … Teeing is bad, because you can't delete bits of the stream.
10:56:54 <chaals> JA: This is where we are now?
10:57:11 <chaals> DD: Yep. We're trying to allow streaming uploads not hold the whole thing in memory
10:57:17 <jmann> present+
10:57:19 <chaals> JA: Do we want stream representing progress?
10:57:23 <chaals> DD: Separate question.
10:57:43 <chaals> … idea is to have a new status code "won't send 301/4xx" so you can drop the rest of the Tee
10:58:22 <chaals> YL: in HTTP 1.1 people were sending an expect 101 to ask if they could send a payload. Looks like this
10:58:43 <chaals> AvK: Looked at it. If you get a 101 there is no guarantee on not getting redirect later. And the expect thing didn't work
10:58:51 <chaals> YL: broken because of caches.
10:59:15 <chaals> AvK: That status code is not needed for v1
10:59:25 <chaals> JA: Not all codes require resending?
10:59:41 <chaals> … reposting is the exception.
10:59:49 <chaals> AvK: 301 for PUT doesn't go to GET
10:59:59 <chaals> … if you see 303 you can stop teeing.
11:00:05 <chaals> JA: But you've sent the thing
11:00:19 <chaals> DD: No, the response can come any time during the transfer.
11:00:34 <chaals> AvK: New code is when you need the whole body, but you know you won't redirect.
11:00:46 <aliams> aliams has joined #webapps
11:00:48 <chaals> JA: If function returned a promise for a stream does that expose the redirect?
11:00:51 <chaals> AvK: Yep.
11:01:02 <chaals> … you can detect the number of endpoints.
11:01:16 <chaals> … people didn't want to deviate from existing model.
11:01:58 <chaals> DD: v0 just dies on 301/4xx, v1 opt into allowing with maybe needing to buffer everything, v2 with new status code lets you optimise and throw away the rest of the body
11:02:11 <chaals> AvK: Requestere doesn't know about redirects and wants to follow.
11:02:41 <chaals> … server knows if they will redirect. Send early 199, wait with the final status. So client can discard tee early on.
11:03:12 <chaals> DD: Client runs into redirect, so allows it, but asks servers to provide 199 to help the client.
11:03:30 <chaals> … pushing to the future is fine, this is niche.
11:03:46 <chaals> JA: Michael fails on redirects, nobody cared.
11:04:04 <chaals> DD: Was looking to see if people cared.
11:04:15 <chaals> JA: Dev could turn a stream into a blob.
11:04:55 <chaals> … if you have to do full buffering, why not? I suppose you can start earlier, but it's not much.
11:05:40 <chaals> AvK: you get network error with redirect, 401, 407
11:05:47 <chaals> … we could allow 303.
11:06:14 <chaals> … you post to a generic endpoint, and get redirected to the comment page you came from
11:06:22 <chaals> DD: Do we opt you in automatically?
11:06:28 <chaals> JA: Yep.
11:06:33 <chaals> .. you provided a stream already.
11:07:55 <chaals> AvK: Want to allow 303
11:08:06 <chaals> JA: If you get redirect manual, you don't know what you're getting
11:08:23 <chaals> DD: Problem is error is not programatically treatable.
11:08:40 <chaals> AvK: Should we expose different classes of errors… oh look, worms.
11:09:18 <chaals> … if you get a redirect other than 303 for an upload of a stream or 401 or 407, you get a network error
11:09:49 <chaals> JA: This seems fine
11:09:56 <chaals> SW: I agree with Alex.
11:11:15 <chaals> Topic: upload progress
11:11:57 <chaals> DD: originally we figured you could track how much of your stream is uploaded. What if you have a blob?
11:12:26 <chaals> … API is uncomfortable. People do New request(blob.body)
11:12:41 <chaals> AvK: XHR makes progress easy, getting UI from fetch is pretty low-level.
11:12:57 <chaals> DD: Think the concern is ergonomic.
11:13:07 <chaals> AR: Is making a blob into a stream OK?
11:13:26 <chaals> DD: People are hacking this so we should do it. e.g. blob.toStream or vice versa
11:13:44 <chaals> JA: You'll need to observe your stream to get progress
11:14:02 <chaals> DD: Yeah, and it takes a bunch of low-level work to follow the stream's progress.
11:14:34 <chaals> [which side of the shed does the door go on]
11:14:47 <chaals> JA: If I have formdata with a bunch of things, it's blergh
11:15:27 <chaals> DD: Dislike factories…
11:15:44 <chaals> JA: We would need to know the size, and add tostream to formdata.
11:15:53 <chaals> DD: You need size to know upload progress.
11:16:04 <chaals> AvK; You can still say how much transferred.
11:16:05 <aliams> aliams has joined #webapps
11:16:29 <chaals> SW: This was done for progress events
11:16:35 <chaals> AvK: But not for streams.
11:16:45 <chaals> DD: Right. So you'll need to find the size somehow.
11:17:03 <chaals> JA: .toStream all the Thingz!
11:17:08 <chaals> … plus a .size
11:17:26 <chaals> SW: forces serialisation eagerly on a lazy object
11:17:31 <chaals> JA: Doesn't need to be.
11:17:48 <chaals> AvK: We can make it sync because blob is sync
11:18:06 <chaals> ES: We may send the serialising somewhere else.
11:18:14 <chaals> SW: You know the boundary size.
11:18:31 <chaals> ES: Once you escape all the values. If the code exists.
11:18:57 <chaals> JA: If .toStream() returns a bounded stream with .size it can be a promise
11:19:10 <chaals> DD: awkward… you figure out size when it goes to the network code.
11:19:23 <chaals> … we could add a magic uploadProgress API
11:19:30 <chaals> … strawman on init...
11:20:25 <chaals> ES: You want a progress handle, right?
11:20:39 <chaals> JA: Yep, a callback with amount-sent and total
11:21:10 <chaals> ES: Or wrap the blob and it's a drain you can watch. It's simpler with an uploadObserverFactoryThingy
11:21:58 <chaals> DD: Trying to make streams single observer only. This is probably fine.
11:22:07 <smaug> smaug has joined #webapps
11:22:09 <chaals> JA: a bounded stream would be good for download progress, too.
11:22:39 <chaals> DD: Interesting
11:22:52 <chaals> AvK: can't expose total easily. Fetch will have a notion for blob and stuff.
11:23:02 <chaals> JA: Don't need to give total until the first call of the callback.
11:23:24 <chaals> AvK: This means you require streams at each end.
11:23:39 <chaals> … which is extra work in a simple case.
11:23:55 <chaals> AR: Would like to see what pattern comes out here
11:24:03 <chaals> DD: This looks like it will set a precedent
11:24:12 <chaals> SW: Looks like observables.
11:24:51 <chaals> RESOLUTION: lunch is good
11:37:41 <kbx> kbx has joined #webapps
11:38:33 <WalterTamboer_> WalterTamboer_ has joined #webapps
11:54:01 <adrianba> rrsagent, make minutes
11:54:01 <RRSAgent> I have made the request to generate http://www.w3.org/2016/09/20-webapps-minutes.html adrianba
11:59:18 <hyojin> hyojin has joined #webapps
12:12:53 <Geunhyung> Geunhyung has joined #webapps
12:29:25 <Florian> Florian has joined #webapps
12:29:44 <bkardell_> bkardell_ has joined #webapps
12:32:54 <chaals> chaals has joined #webapps
12:33:34 <adrianba> Meeting: Web Platform WG - Service Workers
12:33:51 <adrianba> s/angenda-bashing/agenda-bashing/
12:33:53 <adrianba> rrsagent, make minutes
12:33:53 <RRSAgent> I have made the request to generate http://www.w3.org/2016/09/20-webapps-minutes.html adrianba
12:40:03 <adrianba> i/once you publish the CR, you don't want to change it any more/scribe: xiaoqian/
12:40:07 <adrianba> rrsagent, make minutes
12:40:07 <RRSAgent> I have made the request to generate http://www.w3.org/2016/09/20-webapps-minutes.html adrianba
12:45:26 <jcraig> jcraig has joined #webapps
12:46:08 <chaals> chaals has joined #webapps
12:47:35 <LJWatson> LJWatson has joined #webapps
12:47:51 <bz> bz has joined #webapps
12:49:33 <tantek> tantek has joined #webapps
12:49:35 <IanPouncey> IanPouncey has joined #webapps
12:51:16 <hjlee> hjlee has joined #webapps
12:51:25 <ericc> ericc has joined #webapps
12:52:20 <aliams> aliams has joined #webapps
12:52:42 <aliams> present+ Ali_Alabbas
12:54:53 <chaals> rrsagent, draft minutes
12:54:53 <RRSAgent> I have made the request to generate http://www.w3.org/2016/09/20-webapps-minutes.html chaals
12:59:25 <kbx> kbx has joined #webapps
13:02:10 <LJWatson> LJWatson has joined #webapps
13:04:13 <satoshin> satoshin has joined #webapps
13:04:15 <weinig> weinig has joined #webapps
13:13:14 <dom> dom has joined #webapps
13:14:48 <WalterTamboer> WalterTamboer has joined #webapps
13:18:02 <bkardell_> is webapps reconvening?
13:18:16 <bkardell_> s/webapps/platform
13:18:55 <annevk> bkardell_: minuting is happening on GitHub
13:19:56 <annevk> bkardell_: aw, hug
13:30:07 <dka> dka has joined #webapps
13:30:23 <dka> dka has left #webapps
13:32:11 <esprehn> link to github?
13:33:39 <chaals> [no scribing, follow the agenda issue to get to the issues being discussed]
13:36:04 <chaals> -> https://github.com/w3c/ServiceWorker/issues/920#issuecomment-245621515 upload requests
13:36:52 <LJWatson> rrsagent, make minutes
13:36:52 <RRSAgent> I have made the request to generate http://www.w3.org/2016/09/20-webapps-minutes.html LJWatson
13:42:29 <Florian_> Florian_ has joined #webapps
13:47:46 <chaals> [break]
13:47:59 <chaals> [resume in 15 minutes]
13:53:48 <hjlee> hjlee has left #webapps
13:55:05 <TabAtkins> This "no scribing" thing sucks pretty bad. It means people who have difficulty following live discussions are excluded, and it kills discussion context for the decisions that get recorded.
14:04:16 <jamesn> jamesn has joined #webapps
14:04:45 <plh> plh has joined #webapps
14:05:05 <chaals> chaals has joined #webapps
14:05:25 <LJWatson> LJWatson has joined #webapps
14:05:53 <dka> dka has joined #webapps
14:06:00 <dka> dka has left #webapps
14:13:48 <LJWatson> LJWatson has joined #webapps
14:20:02 <kbx> kbx has joined #webapps
14:28:23 <xiaoqian> -> https://github.com/jakearchibald/background-cache background cache
14:30:38 <satoshin> satoshin has joined #webapps
14:34:49 <xiaoqian> RESOLUTION: Put Background Cache in the WICG
14:36:08 <Florian> Florian has joined #webapps
14:38:47 <xiaoqian> -> https://github.com/w3c/ServiceWorker/issues/756 Multiple instances
14:39:29 <wanderview> xiaoqian: I'm around on irc if there are any questions for me on this issue
14:42:05 <smaug> smaug has joined #webapps
14:42:24 <kbx> kbx has joined #webapps
14:49:48 <xiaoqian> present+ wanderview
14:51:37 <wanderview> xiaoqian: you guys dropped
14:51:47 <wanderview> JakeA: I think you dropped... so you can stop talking to me
14:53:24 <wanderview> it says I'm still in the meeting but you guys are not...
14:55:03 <jcraig> jcraig has joined #webapps
14:59:00 <tantek> tantek has joined #webapps
15:01:37 <kbx> kbx has joined #webapps
15:03:49 <Florian> Florian has joined #webapps
15:08:31 <schuki> schuki has joined #webapps
15:15:44 <dka> dka has joined #webapps
15:19:09 <JFSIII> JFSIII has joined #webapps
15:26:26 <xiaoqian> RRSAgent, make minutes
15:26:26 <RRSAgent> I have made the request to generate http://www.w3.org/2016/09/20-webapps-minutes.html xiaoqian
15:38:47 <IanPouncey> IanPouncey has joined #webapps
15:46:42 <ericc> ericc has joined #webapps
15:48:30 <LJWatson> LJWatson has joined #webapps
15:49:23 <chaals> chaals has joined #webapps
15:51:32 <tantek> tantek has joined #webapps
15:52:01 <jamesn> jamesn has joined #webapps
15:52:20 <ericc> ericc has joined #webapps
15:52:46 <JakeA> wanderview: thanks for stepping in, sorry it was a bit tough
15:52:58 <weinig> weinig has joined #webapps
15:53:14 <wanderview> JakeA: np, thanks
15:56:36 <dka> dka has joined #webapps
15:56:43 <dka> dka has left #webapps
16:00:07 <plh> plh has joined #webapps
16:20:35 <jcraig> jcraig has joined #webapps
16:21:09 <IanPouncey> IanPouncey has joined #webapps
16:22:25 <smaug> smaug has joined #webapps
16:53:39 <Zakim> Zakim has left #webapps
16:54:03 <xiaoqian> RRSAgent, bye
16:54:03 <RRSAgent> I see no action items