base64

[annevk]

Can we still switch base64 dialects? We use the other variant for data: URLs and window.atob(). Seems unfortunate to require another one.

The other variant is defined here: https://infra.spec.whatwg.org/#forgiving-base64

[martinthomson]

A lot of code on the web is moving to base64url and the forgiving algorithm rejects '-' and '_', which would be needed.

The algorithm there is too forgiving for use in security-sensitive code. Our implementation of base64url is (I believe) constant-time with respect to the length of a valid input.

Also, atob isn't the API I'd most aspire to be like.

[annevk]

Which code? Why would anything new use base64? And is the algorithm for base64url defined anywhere? Is there an exhaustive testsuite for invalid input to make sure nobody uses the same algorithm with the relevant code points swapped?

[martinthomson]

Which code?

I'm talking about code in Firefox. I'm fairly sure that we have tests. I don't know how comprehensive the tests are, but that's not strictly relevant in this context.

Why would anything new use base64?

Because we have a bunch of places that insist on strings (e.g., JSON) and binary data to move using those things.

And is the algorithm for base64url defined anywhere?

RFC 4648.

Is there an exhaustive testsuite for invalid input to make sure nobody uses the same algorithm with the relevant code points swapped?

I don't know how comprehensive the tests we have are, but that's not strictly relevant in this context. Why do you care about that particular test?

[annevk]

I'm talking about code in Firefox

I thought you said a lot of code on the web is moving to base64url. If it's just Firefox it doesn't matter much, though obviously it matters what is done here.

RFC 4648.

That doesn't really define an algorithm for decoding though. Although I guess you can try to read one into it.

Why do you care about that particular test?

I'm curious if implementations are actually aligned.

[annevk]

(Note that I created shared base64 tests for data: URLs and atob() here: web-platform-tests/wpt#6890.)

[martinthomson]

Hmm, well, base64url IS used a lot more, but it doesn't touch web APIs that often. Though I wish we did have a generic encoder/decoder, we don't.

WebCrypto exposes it via JWK encode and decode, this API, and then I don't have a lot of examples. Both of those examples are of the form where you want the binary data to serve some other end and the result of a variation is a promise rejection. I very much doubt that you could get a "/" past either API.

You could expand the existing WPT tests for webcrypto or try to add some for push, I suppose. But if you were looking for a primitive to test, I don't think that we're at the point of having one.

FWIW, one invariant that would be worth testing is whether string -> blah -> string returns equivalent strings. It should here (unlike atob(), which is a mess).

[annevk]

Even if we had a primitive you'd still need to verify it's actually used in the places that claim to use it.

(whatwg/html#351 was filed for an API endpoint for base64url, but not much interest materialized thus far.)

[marcoscaceres]

@annevk, is it ok to close this one? Please see the comments relating to "#280" at #334 (comment)

[annevk]

I think it would still be good to ensure implementations use an interoperable base64url implementation, both for decoding and encoding, especially as it's sometimes raised as a primitive to expose directly. I don't want browser engine reality of having multiple independent (and possibly incompatible) implementations in a single engine to become web platform reality.