Forgiving base64

[annevk]

Is forgiving base64 essentially

1. Remove ASCII whitespace.
2. 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

[annevk]

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: tc39/proposal-arraybuffer-base64#5.

[annevk]

cc @mozfreddyb @martinthomson

[martinthomson]

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.

[annevk]

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.

[martinthomson]

Firefox considers it, at least in those few places we moved to a CT encoder, which at least includes base64url in Push.

[annevk]

@martinthomson could you point to the cases in the Push specification that warrant that? Thanks!

[martinthomson]

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.

[lemire]

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.