| 02:09 | <DDK> | ILL to jit |
| 02:10 | <DDK> | #Syler ready |
| 02:10 | <DDK> | Sync now |
| 06:19 | <annevk> | hober: happy early b-day πππ» (still a tad early here for that last one, but you should be alright and prolly are π) |
| 06:31 | <MikeSmith> | heh |
| 06:31 | <terinjokes> | lol |
| 06:31 | <MikeSmith> | we need a beer emoji that is a proper pint glass |
| 06:32 | <annevk> | Isn't that the other one perhaps? πΊ |
| 06:33 | <annevk> | But they all take after the font-size so end up rather small |
| 06:33 | <MikeSmith> | hmm that one still has a handle (on MacOS at least) |
| 06:33 | <MikeSmith> | donβt need no handle on my beer glass |
| 06:34 | <MikeSmith> | thatβs training wheels on a bicycle |
| 06:34 | <MikeSmith> | if I drop my pint for lack of a handle, then I drop my pint |
| 06:35 | <MikeSmith> | and then I get another |
| 06:35 | <annevk> | haha |
| 06:35 | <terinjokes> | i would say cry me a river, but there's no river emoji |
| 06:35 | <annevk> | I found a way to make them bigger |
| 06:35 | <annevk> | data:text/html;charset=utf-8,<p style=font-size:15cm>%F0%9F%8D%BA |
| 06:35 | <MikeSmith> | oh wow |
| 06:36 | <MikeSmith> | good on, Firefox |
| 06:36 | <MikeSmith> | at least |
| 06:36 | <MikeSmith> | no love for that in Chrome tho |
| 06:36 | <annevk> | oh, weird |
| 06:36 | <MikeSmith> | anyway happy birthday indeed hober |
| 06:36 | <annevk> | works fine in Safari |
| 06:37 | <annevk> | lots of pixels to be seen though |
| 06:37 | MikeSmith | plays Forever Young for hober (the original Bob Dylan song) |
| 06:37 | <annevk> | and I don't even have a retina 27 inch |
| 06:38 | <MikeSmith> | heh |
| 08:29 | <zcorpan> | annevk: hober: wat? |
| 08:30 | <annevk> | zcorpan: ? |
| 08:30 | <zcorpan> | https://github.com/whatwg/dom/commit/f39eecee3d78913f47bf7680f7b36e003290a6c5 |
| 08:30 | <annevk> | zcorpan: seems like you missed https://twitter.com/hober/status/766746215966838784 |
| 08:32 | <zcorpan> | thanks |
| 08:36 | <zcorpan> | hober: congrats and good luck! |
| 10:51 | <smaug____> | oh, forgot to ask |
| 10:51 | <smaug____> | anyone going to tpac this year? |
| 10:52 | <jgraham> | smaug____: Yeah, seems so |
| 10:52 | <jgraham> | hober: Awesome! |
| 11:38 | <MikeSmith> | smaug____: lots of us going |
| 11:38 | <MikeSmith> | hope you are too |
| 11:47 | <annevk> | foolip: we could also list CDATA before Text in switch statements |
| 11:48 | <annevk> | foolip: maybe that is good enough until branding is available |
| 11:48 | <smaug____> | MikeSmith: yeah, just thinking. Looks like I'll need to be in the Bay area the week before. |
| 11:48 | <annevk> | foolip: even with branding you likely need that |
| 11:48 | <smaug____> | MikeSmith: but most probably coming |
| 11:49 | <smaug____> | or going |
| 11:49 | <annevk> | smaug____: yay |
| 12:09 | <annevk> | smaug____: I think I'll close the adopt memory leak prevention bug and open an issue for it on GitHub with a summary of the situation and try to get some more input from Safari/Chrome/Edge |
| 12:10 | <annevk> | smaug____: but with Edge saying they don't want it, rniwa telling me the other day Safari doesn't want it, and Chrome having said before they don't want it, I'm not too hopeful |
| 12:22 | <JakeA> | annevk: if I'm reading the specs correctly, it seems that jakearchibald.github.io would be able to provide a PUSH_PROMISE for a resource on www.github.com |
| 12:22 | <JakeA> | Since they use the same certificate |
| 12:23 | <JakeA> | I don't have control over the pushes jakearchibald.github.io can do, so it isn't a problem here |
| 12:24 | <JakeA> | But it feels surprising in terms of the origin model |
| 12:26 | <JakeA> | This could be a problem for *.herokuapp.com |
| 12:41 | <annevk> | JakeA: connection coalescing is scary |
| 12:42 | <annevk> | JakeA: however, jakearchibald.github.io can also get www.github.com resources cached |
| 12:42 | <annevk> | JakeA: it wouldn't surprise me however if connection coalescing leads to a number of attacks |
| 12:43 | <annevk> | JakeA: Alt-Svc is similarly tricky |
| 12:43 | <annevk> | JakeA: I argued a bit about it in Mozilla's Bugzilla and blink-dev, but nobody cared |
| 12:43 | <annevk> | JakeA: "if they share the certificate they already share authority" |
| 12:43 | <JakeA> | annevk: take https://jakearchibald.com/. I use cloudflare so I'm using the same cert as http://eurocashmarket.com/ for whatever reason |
| 12:44 | <annevk> | JakeA: that doesn't seem true at all, but it's hard to argue with these people |
| 12:44 | <annevk> | JakeA: having said that, the PUSH_PROMISE is tied to a request-response stream |
| 12:44 | <JakeA> | annevk: does this mean I could (if cloudflare forwarded PUSH_PROMISE) push a request to eurocashmarket.com & a response of my choosing? |
| 12:45 | <annevk> | JakeA: wouldn't a simple mitigation there be a same-origin requirement on the PUSH_PROMISE? |
| 12:45 | <JakeA> | absolutely |
| 12:45 | <JakeA> | I'm still keen on it being linked to the requesting fetch group |
| 12:45 | <annevk> | JakeA: yeah maybe that's an attack indeed |
| 12:46 | <annevk> | JakeA: the whole idea that same cert means access to the same application is so flawed, but I found it really hard to make that point with mcmanus et al |
| 12:46 | <annevk> | JakeA: they just say "well, server fault" |
| 12:48 | <JakeA> | annevk: hmm, all it takes is one of these wildcard-certing hosts to enable PUSH_PROMISE without filtering and boom |
| 12:48 | <JakeA> | it's probably happening somewhere already |
| 12:48 | <annevk> | JakeA: so, write a gist / blogpost and we float it around? |
| 12:49 | <JakeA> | annevk: shall do. Already been asked to write a doc on this stuff internally. Will share |
| 12:50 | <annevk> | JakeA: sleevi will feel justified since I think he tweeted already that connection coalescing will be trouble |
| 12:51 | <annevk> | JakeA: I'm surprised nobody noticed this thus far |
| 12:51 | <annevk> | JakeA: but maybe that's because they consider this kind of thing to be fine :/ |
| 12:51 | <JakeA> | annevk: maybe they did & like you say, thought "meh server's fault" |
| 12:51 | <JakeA> | heh |
| 12:57 | <annevk> | tyoshino: https://github.com/yutakahirano/fetch-with-streams/issues/66#issuecomment-241393392 is really good |
| 13:05 | <JakeA> | annevk: this isn't just a problem with coalescing, as I can give my pushed response some nice max-age headers & it'll be used in other connections |
| 13:08 | <annevk> | JakeA: very true, though maybe with the current client architecture that's never a problem? |
| 13:08 | <annevk> | JakeA: seems like it would be a big problem though |
| 13:08 | <JakeA> | annevk: not sure how. I can push a response for another origin, then I can request it with <img> to get it in the http cache |
| 13:09 | <annevk> | JakeA: yeah, putting it in the cache is an attack vector |
| 13:09 | <annevk> | JakeA: if it's used for <iframe> you've hit a homerun |
| 13:10 | <annevk> | JakeA: executing arbitrary code for an origin of choice |
| 13:10 | <JakeA> | annevk: and while matching is totally unspecified, nothing's saying you can't do that |
| 13:10 | <JakeA> | The answer is to make this same-origin |
| 13:11 | <annevk> | Yeah |
| 13:11 | <JakeA> | Or allow pushing for *any* origin, but tie the request/response to the document. Similar to how service worker lets you lie to yourself |
| 13:12 | <JakeA> | But that means it can never go in the http cache |
| 13:14 | <annevk> | JakeA: last sentence of https://tools.ietf.org/html/rfc7540#section-10.4 does suggest it's tied to connection coalescing |
| 13:14 | <annevk> | JakeA: so maybe it was considered after all? |
| 13:15 | <annevk> | JakeA: seems very sketchy though |
| 13:17 | <JakeA> | annevk: I think I'm missing something. The cert on https://jakearchibald.com/ is also the cert for http://eurocashmarket.com/. That means I could push a response for eurocash, then request it as part of the same connection which would put it in the http cache, since I'm authoritative for eurocash. Then later, in a new connection, eurocash makes a request to |
| 13:17 | <JakeA> | its origin, and gets my response from the http cache |
| 13:18 | <annevk> | yeah |
| 13:18 | <annevk> | what I meant was that the attack of just putting arbitrary stuff for *any* origin is outlawed |
| 13:18 | <annevk> | so the attack is limited to connection coalescing |
| 13:18 | <annevk> | and arguably the server would violate that 10.4 section |
| 13:19 | <JakeA> | ahh I see |
| 13:19 | <JakeA> | yeah |
| 13:20 | <JakeA> | "that server MUST ensure that tenants are not able to push" - so they'd say it's the server's fault |
| 15:42 | <zcorpan> | annevk: hmmm. is there a way to manually update https://resources.whatwg.org/file-issue.js ? it seems it didn't get the latest commit, i still get if (queryParamIndex != -1)) { |
| 15:47 | <zcorpan> | annevk: nm, fixed it with another commit :-) |
| 15:51 | <annevk> | JakeA: if we ever expose an API around push this is something we need to address |
| 15:52 | <annevk> | JakeA: seems Chrome might limit connections to same eTLD+1, too? |
| 15:52 | <JakeA> | annevk: this all goes away if we can associate pushes with clients or at least origins |
| 16:01 | <annevk> | JakeA: they are associated with a request, so you should have some of that |
| 16:02 | <JakeA> | annevk: given that CloudFlare are turning link rel=preloads into PUSH_PROMISE, it'd be great if they behaved somewhat the same |
| 16:03 | <JakeA> | and it seems like preload is tied to the lifetime of the document |
| 16:03 | <JakeA> | although that's handwaved right now |
| 16:03 | <annevk> | JakeA: yeah we should define that, I wish igrigorik could find someone to do it |
| 16:03 | <annevk> | I guess otherwise I should π |
| 16:05 | <JakeA> | annevk: I gave it half a shot at https://github.com/whatwg/fetch/issues/354#issuecomment-237508188 |
| 16:05 | <JakeA> | Still hand-waving though |
| 16:05 | <annevk> | True |
| 16:06 | <annevk> | I should review that |
| 16:57 | <annevk> | JakeA: yeah, too much hand-waving I guess, though maybe a useful starting point |
| 16:58 | <annevk> | JakeA: one thing I should probably resolve first is some ambiguity around the HTTP cache, waiting on mnot for that in part |
| 16:58 | <annevk> | JakeA: the other thing missing from that is actually putting things in the preload cache |
| 16:58 | <annevk> | JakeA: as for CloudFlare, what they are doing doesn't seem super great |
| 16:59 | <annevk> | JakeA: they also did not have numbers whether those pushes were actually helping |
| 16:59 | <annevk> | JakeA: and since the browser can't yet inform the server of what it has in the cache, it's likely a lot of those pushes are in vain |
| 17:00 | <JakeA> | annevk: the browser can RST_STREAM though |
| 17:01 | <annevk> | JakeA: sure, but that's a lot of chattiness for what amounts to nothing |
| 17:01 | <annevk> | JakeA: but I guess I haven't seen numbers on how wasteful that would be so maybe it's okay |
| 17:02 | <JakeA> | annevk: in terms of storage I had 'On document-insertion <link rel="preload"> creates an entry in the fetch group's "preload cache" containing the request and a promise for the response' - the intent is to make it as unracey as possible |
| 17:03 | <annevk> | JakeA: ah okay |
| 18:04 | <JakeA> | annevk: I wonder if I could H2 push a CORS preflight response for myself |
| 18:04 | <JakeA> | from another origin on the same authority |