| 12:23 | <JakeA> | annevk: Catching up on the CSP thing. I'm not sure I understand the problem. When you make a request from a page, the CSP is checked before the request goes to the service worker, but the response is also checked against the original request. The destination is taken from the original request, so service worker can't tamper with it |
| 12:31 | <annevk> | JakeA: the concern is about routing something into a cache |
| 12:47 | <JakeA> | annevk: I can't figure out the attack. <img> -> service worker -> fetch() -> cache… but if a response is later pulled from the cache it'll still be CSP checked |
| 12:49 | <annevk> | JakeA: so in that setup the fetch() uses SW's CSP |
| 12:50 | <annevk> | JakeA: but would it still consult that SW's CSP if it uses routing to bypass invoking the SW? |
| 12:50 | <annevk> | JakeA: I think I managed to convince myself that using the document's CSP is sufficient, since both the document and the SW can pollute the cache, but it's still a little surprising |
| 12:51 | <annevk> | JakeA: the referrer would also be different and there might be other subtle things going on too |
| 12:51 | <annevk> | JakeA: perhaps routing isn't a thing yet though, I don't really know the state of things |
| 12:52 | <JakeA> | annevk: as in the static routes proposal? That's a good question. Using the service worker's CSP would make things more consistent, especially with static route polyfills, but I like the idea of just using the document's CSP since it's all behind the scenes anyway. But yeah, it isn't enough of a thing yet to worry too much about |
| 12:54 | <annevk> | JakeA: okay |
| 12:54 | <annevk> | thanks |
| 13:08 | <yoav> | annevk: I'm wondering what's the best path forward for CH and a `Sec-` prefix, which we discussed in https://github.com/whatwg/fetch/pull/880 |
| 13:31 | <annevk> | yoav: I'm not sure, I kinda wonder what media elements do for Range when crossorigin is set |
| 13:32 | <annevk> | yoav: JakeA might be onto something that following Range is the way to go, but what Range does is not fully clear |
| 13:33 | <JakeA> | They would trigger a preflight right? |
| 13:33 | <annevk> | JakeA: my suspicion is that browsers don't |
| 13:34 | <annevk> | JakeA: and that the treat Range as privileged because they initiated the range request |
| 13:34 | <annevk> | JakeA: similar to EventSource's Last-Event-ID |
| 13:34 | <JakeA> | annevk: Interesting. I think Chrome does if it goes via a service worker, so I guess that needs fixing somehow. |
| 13:37 | <yoav> | JakeA: can you expand on what you had in mind? Do we want to add specific CH headers as privileged? All `Sec-` prefixed headers as privileged? |
| 13:37 | <yoav> | And if they are privileged, does that mean that SW can copy them from the incoming Request without breaking them? |
| 13:38 | <yoav> | s/copy them/forward the incoming request to fetch()/ |
| 13:43 | <annevk> | Domenic: https://github.com/whatwg/html/issues/4400#issuecomment-474827602 what if the network hangs for multiple seconds after the first </script>? |
| 13:44 | <annevk> | Domenic: seems that would result in multiple tasks from the parser to manipulate the tree |
| 13:44 | <Domenic> | annevk: not as currently specced for HTML modules, but, maybe that's thing to raise with the MS folks about their spec? |
| 13:44 | <annevk> | Domenic: ooh, inside an HTML module |
| 13:45 | <annevk> | Domenic: my bad |
| 13:45 | <annevk> | Domenic: no that seems like the right semantics for HTML modules |
| 13:51 | <JakeA> | yoav: Is the intent that `Sec-` headers should pass through a service worker as long as the request isn't modified? And `Sec-` headers shouldn't trigger a preflight unless it was manually set by the developer (or is this forbidden?) |
| 13:51 | <yoav> | they are forbidden |
| 13:51 | <JakeA> | Is the rest correct? |
| 13:52 | <yoav> | yes, I want `Sec-` headers to be able to pass through |
| 13:52 | <yoav> | or alternatively, add CH sec headers both before and after SW |
| 13:53 | <yoav> | the latter might be better, as it'll add CH headers also when the request was changed |
| 13:53 | <yoav> | basically, SW needs to be able to observe those headers, but not modify or add them |
| 13:54 | <JakeA> | yoav: That's kinda how `Range` works, except `Range` will trigger a preflight for cors requests (but I think this is a bug), and `Range` can be set by the developer (in which case it should trigger a preflight) |
| 13:55 | <JakeA> | But the mechanism that allows `Range` to exist unless the request is modified seems useful for `Sec-` |
| 13:58 | <yoav> | Can Range headers survive if the request was modified? |
| 13:59 | <yoav> | JakeA: I think that would be desirable for CH headers, but not sure how to achieve that. Maybe we should keep a copy of all `Sec-` headers before SW is called and then restore them afterwards? |
| 14:05 | <JakeA> | yoav: "Can Range headers survive if the request was modified?" no |
| 14:07 | <JakeA> | yoav: https://github.com/web-platform-tests/wpt/blob/master/fetch/range/general.any.js |
| 14:08 | <JakeA> | yoav: what do you want to happen to the `sec-` headers if the request is modified? Remove them, or set them to some kind of default? |
| 14:10 | <yoav> | I want to set them back to what they were |
| 14:10 | <JakeA> | What's the difference between that and doing nothing? |
| 14:10 | <JakeA> | (given that developers can't set them anyway) |
| 14:11 | <yoav> | Let's consider `Sec-DPR: 2`. I want to set it before SW (so that SW can observe it and maybe change its response accordingly), but want to make sure it is added to requests going to the server, even if the request was modified |
| 14:11 | <JakeA> | Why do you need to add something that's already there? |
| 14:11 | <yoav> | and I want that value to not be modifiable by the developer |
| 14:12 | <yoav> | If `Sec-` headers gets blown off when the developer modifies the request, I want to reinstate them |
| 14:12 | <yoav> | if they are there, no need to add them again, obviously |
| 14:12 | <JakeA> | just don't blow them off then? |
| 14:13 | <JakeA> | ew, phrasing |
| 14:13 | <JakeA> | I think I'm missing something. If you don't want the headers to be removed, instead of removing them and re-adding them, just don't remove them, right? |
| 14:14 | <yoav> | Maybe I'm missing something. When a SW gets a Request object in its fetch event, is it immutable? Or can they change it? |
| 14:15 | <JakeA> | It's immutable, but once you do `const request = new Request(event.request)` then `request.headers` are mutable |
| 14:16 | <yoav> | oh, so devs will be able to change those request headers without killing any forbidden headers which were present in the original request? |
| 14:16 | <yoav> | that'd work |
| 14:17 | <JakeA> | Yeah. That's different to how `Range` works btw. `Range` headers are removed as soon as the developer modifies the headers. |
| 14:17 | <JakeA> | But it seems like `Sec-` needs to work differently |
| 14:34 | <yoav> | JakeA: Thanks! I'll take a look and come up with a Range-inspired proposal |
| 14:49 | <annevk> | Domenic: want to do a final pass and land https://github.com/whatwg/html/pull/4360? |
| 14:49 | <annevk> | Domenic: I gotta go soon |
| 15:28 | <Domenic> | Can do |
| 16:52 | <annevk> | Domenic: never mind, Maciej spotted a mistake |
| 17:26 | <annevk> | Domenic: playsinline was added in June 2016, FWIW |
| 17:29 | <Domenic> | Ah wow OK |
| 21:07 | <annevk> | I can look into when the checkpoint flag got added I suppose |