09:29 | <annevk> | freddy: so SRI attempts to both base64 and base64url decode the specified base64 value? This is not specified, but that's how it's implemented in Chromium and WebKit it appears. And it kinda matches with how CSP defines its use of base64, though that should not require decoding in principle (though in practice implementations might?). |
09:30 | <annevk> | That's quite the mess and on top of that there's a test that the base64 decoding happens without padding validation, as far as I can tell. Which would be quite novel. |
09:30 | <annevk> | Gecko fails that test though so maybe there's some hope. |
09:35 | <freddy> | annevk: Right. This came up as a webcompat thing. CSP used to be base64 but started to include base64url within CSP3. We added support for that in Firefox 106 but apparently had not looked at SRI when dealing with this issue. Both in terms of spec and implementations, it looks? |
09:36 | <freddy> | So, what exactly do you propose? |
09:38 | <freddy> | https://bugzilla.mozilla.org/show_bug.cgi?id=1785871 was the base64url support in CSP |
09:57 | <freddy> | is this in https://wpt.fyi/results/content-security-policy/script-src/script-src-sri_hash.sub.html?label=experimental&label=master&aligned ? |
10:17 | <annevk> | freddy: attempting to decode as base64 and then base64url seems somewhat reasonable, if the particular method of decoding is defined in detail as well; for better or worse there's quite some variety there in implementations |
10:18 | <annevk> | freddy: yeah, I think "multiple matching integrity" is the one I found issues with |
10:19 | <annevk> | freddy: see also https://github.com/WebKit/WebKit/pull/12768 for how I found out |
10:21 | <freddy> | searchfox has a webkit index called wubkat? 🙃 |
10:22 | <freddy> | anyway, this looks fun. I'll take a look. thanks! |
10:35 | <annevk> | (Also, I would have objected to this had I known, but I guess it's too late now.) |
12:35 | <freddy> | sorry... objected to what? |
14:12 | <annevk> | freddy: supporting both base64 and base64url; though maybe it seemed less objectionable in the CSP context, but given how it's implemented it still seems pretty bad |
14:17 | <freddy> | yes, we were also caught by surprise when we implemented base64url in CSP3, but it was due to a web compat bug. Looked like it crept in before we could intentionally object to it |
14:20 | <annevk> | freddy: there's also https://github.com/w3c/webappsec-csp/issues/423 by bakkot |
14:21 | <freddy> |
🙂 |
14:23 | <annevk> | Looking at the history of base64url in CSP it seems like it was a Chromium design decision that then got standardized without much scrutiny: https://github.com/w3c/webappsec-csp/issues/37 |
14:23 | <annevk> | Lovely |
14:24 | <annevk> | I mainly got here because I was interested in seeing what varieties of base64 were out there in browsers and if WebKit could be further simplified around that |
14:29 | <annevk> | Domenic: emilio: ping for https://github.com/whatwg/html/pull/8998 |
14:44 | <emilio> | thanks, looking |
19:27 | <dv8fromtheworld> | I'm currently working with the URL constructor for canonicalization of some URLs and have stumbled upon some confusing behavior in regards to custom protocols |
19:27 | <dv8fromtheworld> | For example, steam://run/game |
19:28 | <dv8fromtheworld> | It is surpising to me that this produces no hostname, but even more so that the pathname has the // protocol delineators in it |
19:30 | <dv8fromtheworld> | This is different from Node's new "WHATWG compliant" URL constructor |
19:30 | <dv8fromtheworld> | I'm curious as to what the correct "compliant" behavior here is in regards to custom protocols |
19:42 | <dv8fromtheworld> | Node's URL produces a different output, but one that is closer to what I'd expect to actually see in regards to path and host handling |
19:50 | <Dominic Farolino> | Is the first picture of Chrome DevTools? If so I think that's a bit expected given https://crbug.com/869291 |
20:04 | <dv8fromtheworld> | Is the first picture of Chrome DevTools? If so I think that's a bit expected given https://crbug.com/869291 |