Reminds me of this sample from the Lwan project: https://time.lwan.ws/blocks -- where the clock is rendered on the server, and new frames are sent to the client using chunked encoding.
Details are hazy as this was a long time ago, but at some point you could make parts of messages not render in Outlook and Outlook Express by writing "begin something" (two spaces after "begin") by itself in a single line. Outlook would thing that it was the start of an uuencoded block and not render anything after that.
I remember annoying friends in a mailing list by quoting emails with "begin quote from Person Name:" :)
And to be fair in normal English orthography the word begin is never followed by two spaces. This is more like Microsoft wanting everyone to write proper English than Microsoft wanting to change the English language
I have vague memories of it being a Microsoft thing to insert two spaces at the end of every sentence? I could be misremembering.
The bug here was not "begin" followed by two spaces, but rather its "begin" followed by some other text followed by two spaces, which if i recall correctly is exactly what Microsoft would auto-format your text to.
I don't like Excel, but 1) it is a true feature when used as intended in a finantial environment and 2) you shouldn't use Excel to fiddle with genetic data, learn proper tooling, you are supposed to be a pro. Still I think changing user data silently is an error.
This is known since at least 2004, with workarounds (https://link.springer.com/article/10.1186/1471-2105-5-80), yet people still use Excel instead of learning a bit about proper data storage. In my lab I sent a mail with the steps to harden Excel against this "bug". Want to guess how many did it? Zero.
Excel is second after Access for bottom-up developed data storage. And since Access is all but gone, it's absolutely not surprising people reach for Excel.
The unix mbox format uses the sequence ["F", "r", "o", "m", " "] as its indicator that a new mail has started. If you're not careful about escaping your stored mails, you can easily corrupt them by starting a body paragraph with the word "From".
How do you escape the word From? Well, that's up to the client! Be careful using different clients for a given mbox file!
The fun part is that the actual uuencode format has the file mode in octal after the word begin. Somebody at microsoft decided this was optional and that begin with two spaces and then the filename should also be the start of a uuencoded section. Of course also without checking if there was any content that was actually encode in that format.
This is roughly what my JSON parser does. It does type-checking, albeit without using JSON-schema, but an object descriptor that you have to define to parse and generate JSON.
It's been developed for embedded systems (it was written originally for a NATS implementation in the Zephyr RTOS), so it's a bit limited and there's no easy way to know where some parsing/type validation error happened, but the information is there if one wants to obtain it: https://github.com/lpereira/lwan/blob/master/src/samples/tec...
It's collected after 15min, give or take. The hash isn't random, it's the SHA-1 hash of the base64-encoded data, so it's predictable -- if something keeps accessing the base-64 encoded URL, the /s/... URL won't vanish.
I tried making it more strict (by checking the Sec-Fetch-Site and Sec-Fetch-Dest headers), but not all browsers send that.
Data is already stored in the ZIP file deflated, so I can just send whatever is inside the ZIP file back to the client if they accept that encoding (which is pretty much always the case, given how ubiquitous deflate is).
The server parses the ZIP file and stores that information in a hash table for quicker lookup but it's otherwise not decompressing anything. This hash table is kept for a few minutes to avoid having to decode the base64-encoded data and parse the ZIP file for every request.
So decompression is happening on the client, but not at the JS level, instead you are taking advantage of browser's ability to accept zip-encoded content from the server, hence decompression is done the by browser's own behavior when it receives a "content-encoding: gzip" stream or something like that.
It doesn't seem like the client actually verifies that the content it got back matches the SHA256 it requested, so in theory if you really wanted to meet them you could start sending an update website with details to get in contact with you. Though, that'd ruin the magic of it I'd bet :)
