01:32
<sideshowbarker>
I feel like there must be a good answer for https://stackoverflow.com/questions/76068346/is-it-possible-to-restrict-the-visibility-of-domains-in-csp-frame-ancestors but if so, I don’t know what the answer might be
06:26
<freddy>
annevk: So, to clarify: The tests you found failing in Firefox but succeeding in Safari & WebKit were (a) missing padding and (b) base64url decoding works. The case (a) seems to be in WPT; but looks like (b) is not even tested in wpt?
06:34
<cdravcte>
aLoha
06:38
<annevk>
freddy: could be, it would also be interesting to test base64 that has whitespace and whether implementations strip it or not (as they do for data: URLs and atob/btoa)
06:40
<annevk>
Austin Keener: Chrome and Firefox are buggy, Safari does this correctly; hopefully it'll get addressed as part of Interop 2023
06:40
<freddy>
Script files with whitespace or integrity metadata with whitespace?
06:41
<annevk>
freddy: something like sha256-base64withtab\tandspaces init
06:41
<annevk>
freddy: hmm, I guess that naturally ends up failing due to how integrity is parsed
06:41
<freddy>
well, we split multiple items of integrity metadata on spaces, so not sure if that's even expected to work
06:41
<annevk>
freddy: so maybe that cannot be tested
06:42
<freddy>
yup
06:42
<annevk>
freddy: and I guess "spaces" there is HTML/Infra's definition of ASCII whitespace?
06:42
<annevk>
freddy: could still test \v then, but that's about it
06:42
<freddy>
With the "missing padding" and base64url already working in other browsers, it seems unlikely that we can deprecate in Safari and Chrome. I consider just filing a bug for Firefox to support it
06:43
<annevk>
freddy: I kinda wish we could remove missing padding from base64 "default"
06:43
<freddy>
Do you want to drive a deprecation in Safari and Chrome?
06:43
<annevk>
Even forgiving base64 is stricter on padding than that
06:44
<annevk>
I want fewer base64 decoding options, yes; I'm not personally signing up for Chromium work
06:45
<freddy>
Well, how bad do you want them?
06:51
<freddy>
Especially with the test case for "missing padding" passing since forever in wpt, I don't see anyone care if Safari and Firefox were to stop supporting it
06:53
<annevk>
freddy: there's not just that problem right, it also needs to be specified
06:54
<freddy>
so, "base64 decoding with padding ignored" is a new thing in terms of standards infra?
06:54
<annevk>
freddy: I could totally see this getting fixed as part of some interior effort, esp as base64 encoders will add padding so I doubt this is a problem in practice
06:54
<annevk>
freddy: yes
06:54
<freddy>
But is it also a new thing in terms of how browsers implement decoding across other features?
06:54
<annevk>
freddy: I'm not currently aware of features besides CSP/SRI
06:55
<annevk>
freddy: though there are some code paths that have used it due to lack of care
06:55
<freddy>
Firefox does not seem to have an "ignore padding" setting in the existing base64decoder but there is a setting for the base64urldecoder
06:56
<annevk>
freddy: for base64url WebKit never is strict on padding, but I believe that is somewhat expected for base64url even though that could have sec consequences as well
07:02
<freddy>
well "never" except that one integrity test case
07:11
<annevk>
freddy: that's a base64 failure, not a base64url one
07:14
<annevk>
I think for now I'll update that patch to have 4 decoding modes, DefaultWithoutStrictPadding, DefaultWithStrictPadding, DefaultWithStrictPaddingAndIgnoreWhiteSpace, and URL (equivalent to DefaultWithoutStrictPadding except for the map used); that's what WebKit has today minus a mode for treating \v as whitespace, which was just a bug due to how C defines ASCII whitespace
07:15
<annevk>
I somewhat hope that DefaultWithoutStrictPadding can be removed and some investigation is needed whether we should have URLWithStrictPadding
07:16
<annevk>
And I need to look into whether "StrictPadding" is accurate enough of a term as data: URLs and the like aren't super strict on it either (but they do have some checks at least)
07:46
<sideshowbarker>
What happened to the Trusted Types spec?
07:47
<sideshowbarker>
nevermind, I guess the URL just changed
07:47
<sideshowbarker>
…or else I had it wrong to begin with
10:09
<annevk>
freddy: what would be even better btw is if we could make CSP/SRI rely on base64 encoding exclusively; that would be even stricter, but also a lot cleaner for security-sensitive stuff
15:07
<Ansya Waka>
Changeea home password
16:12
<annevk>
Jeffrey Yasskin: heya, shall I merge the Web IDL string PR or do you want to make further changes?