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? |