> Browsers recently added convenient and safe functions to process base 64 functions Uint8Array.toBase64() and Uint8Array.fromBase64()
Wow, finally! I've had to work around this so many times in the past (btoa/atob do not play nicely with raw binary data - although there are workarounds on the decode path involving generating data URIs)
Looks like this was brought up there as a result of this article too, which is neat! And helpful since I was just messing with a node script that is heavily decoding base64
That blog post left me hungry for more. I was expecting Daniel Lemire to provide a SIMD crazy optimized version that shows the default browser implementations are sub-optimal. But it's not in this article. Anyone knows?
I remember in the early days of Phoenix LiveView on an intranet app using http1 I noticed it was faster to base64 encode an image, putting it in an img tag and sending the diff through the Channel websocket than the regular http request through Cowboy.
Probably so you can put in line breaks? Seems common in base64 data, such as armored PGP keys or emails attachments. HTML attributes allow line breaks, although I haven’t seen it done for base64 images.
Now? There's no change. Also human readable text substantially consists of letters. But that's most of the base64 alphabet too. So this isn't like steganography. All the letters in the human-readable words are valid base64 characters too. The only thing about this is that you get to choose where to put the spaces and newlines. You can't exactly construct arbitrary payloads starting from arbitrary messages.
Maybe he means invisible whitespace characters that don't render? I haven't verified this but depending on the definition of whitespace it's possible you can pass a base64 string and insert an arbitrary number of them. When decoded per spec they do nothing so nobody notices them. But if you can pass the base64 string through you can receive or verify the hidden message. Lots of reasons you might want to hide data in plain sight.
Mozilla's "privacy" image prevents them from knowing what their browser actually does in the wild, while Google collects CPU time profiles from user devices, comprehensively, and hammers down the hotspots they find, and that refinement has been going on for many years.
That’s nonsense. Firefox has telemetry built in, it’s just that you can opt out of it. Your answer doesn’t explain why at all but instead just takes a wild guess at what might have happened. You don’t know if this was discovered in Chrome or in some other use of V8. Or maybe it was always fast in Chrome! What a weird non-answer.
> Browsers recently added convenient and safe functions to process base 64 functions Uint8Array.toBase64() and Uint8Array.fromBase64()
Wow, finally! I've had to work around this so many times in the past (btoa/atob do not play nicely with raw binary data - although there are workarounds on the decode path involving generating data URIs)
https://chromium-review.googlesource.com/c/v8/v8/+/7208125 v8 changed yesterday to avoid the temp buffer which will likely double the base64 decode speed.
Looks like this was brought up there as a result of this article too, which is neat! And helpful since I was just messing with a node script that is heavily decoding base64
That blog post left me hungry for more. I was expecting Daniel Lemire to provide a SIMD crazy optimized version that shows the default browser implementations are sub-optimal. But it's not in this article. Anyone knows?
He's already done that: https://github.com/simdutf/simdutf?tab=readme-ov-file#base64 (see also https://github.com/lemire/fastbase64 )
I remember in the early days of Phoenix LiveView on an intranet app using http1 I noticed it was faster to base64 encode an image, putting it in an img tag and sending the diff through the Channel websocket than the regular http request through Cowboy.
> However, when decoding, we must handle errors and skip spaces.
This had me scratching my head. Why would a base64 decoder need to skip spaces? But indeed, MDN documents this behavior:
> Note that: The whitespace in the space is ignored.
JS never ceases to surprise. Also, check out that typo :D
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
Probably so you can put in line breaks? Seems common in base64 data, such as armored PGP keys or emails attachments. HTML attributes allow line breaks, although I haven’t seen it done for base64 images.
This might be for compatibility with XML Schema base64Binary, which collapses all whitespace (such as line breaks) to single spaces.
So technically it’s now possible to hide a payload in somewhat human-readable text, as long as it base64-decodes.
Now? There's no change. Also human readable text substantially consists of letters. But that's most of the base64 alphabet too. So this isn't like steganography. All the letters in the human-readable words are valid base64 characters too. The only thing about this is that you get to choose where to put the spaces and newlines. You can't exactly construct arbitrary payloads starting from arbitrary messages.
Maybe he means invisible whitespace characters that don't render? I haven't verified this but depending on the definition of whitespace it's possible you can pass a base64 string and insert an arbitrary number of them. When decoded per spec they do nothing so nobody notices them. But if you can pass the base64 string through you can receive or verify the hidden message. Lots of reasons you might want to hide data in plain sight.
What do you mean hide a payload?
Base64 isn’t obfuscation or encryption.
Does anyone know why Firefox/Servo are so slow compared to the rest?
Mozilla's "privacy" image prevents them from knowing what their browser actually does in the wild, while Google collects CPU time profiles from user devices, comprehensively, and hammers down the hotspots they find, and that refinement has been going on for many years.
That’s nonsense. Firefox has telemetry built in, it’s just that you can opt out of it. Your answer doesn’t explain why at all but instead just takes a wild guess at what might have happened. You don’t know if this was discovered in Chrome or in some other use of V8. Or maybe it was always fast in Chrome! What a weird non-answer.