infra
infra copied to clipboard
whatwg
Forgiving base64
Is forgiving base64 essentially
- Remove ASCII whitespace.
- Ordinary base64 decode.
?
It's a lot clearer about erroneous inputs though so if we decide to change this we want to make sure we end up making the same requirements.
cc @zcorpan @bakkot
I guess https://www.rfc-editor.org/rfc/rfc4648#section-3.5 in particular is a thing that our algorithm addresses explicitly. We ignore some bits instead of checking they are 0. That's a thing I haven't seen a single browser-based base64/base64url implementation enforce. Number of = is enforced though.
So we might need to define something equivalent for base64url given CSP/SRI use that and might not rely on encoding alone.
Related: https://github.com/tc39/proposal-arraybuffer-base64/issues/5.
Something to consider here is whether you might want to recommend that implementations avoid creating side-channels (esp. through timing) based on the content of the information being encoded. There are a number of cases where the information that is being passed should not be leaked to other processes, but might be if the encoding function were highly variable.
Maybe we should instead encourage folks to not use base64 for such cases? I doubt any browser has base64 code paths that take that into account and I'm not sure we should have those.
Firefox considers it, at least in those few places we moved to a CT encoder, which at least includes base64url in Push.
@martinthomson could you point to the cases in the Push specification that warrant that? Thanks!
Nothing concrete in the spec. But the values are secrets and I've learned that you don't write code that changes what it does based on the value of a secret.
The simdutf library (used in Node.js for base64 decoding) implements forgiving base64. As far as we know, it is fully compliant. One issue that I have encountered is that there is no base64url equivalent that is explicit.
