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>

This is pretty silly.

🙂

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
it is, yeah. Same output in firefox though