It's a pretty niche region. It's about 20% more expensive than other major regions so I think it's unlikely to be a core part of most large deployments. That being said, we did hear about it and continue to track it.
Perhaps I don't understand it but the encryption security model for MacOS/iPadOS/iOS currently doesn't allow multiple different encryption keys for each user. So any user can decrypt the whole drive and while it does enforce user permissions, the security model can't support true multiuser.
I actually don't know if Windows or ChromeOS support this either but this is certainly something Linux can with LUKS et. al.
Yeah but now they're using npm to install a million packages to do things like tell if a number is greater than 10000. The chances of the programmer wanting to understand the underlying system they are using is essentially nil.
It still blows my mind that they called that crappy partial buggy characterset “utf8”. Then later came out with actual utf8 and called it “utf8mb4”. Makes no sense
They should have addressed it much earlier, but it makes way more sense in historical context: when MySQL added utf8 support in early 2003, the utf8 standard originally permitted up to 6 bytes per char at that time. This had excessive storage implications, and emoji weren't in widespread use at all at the time. 3 bytes were sufficient to store the majority of chars in use at that time, so that's what they went with.
And once they made that choice, there was no easy fix that was also backwards-compatible. MySQL avoids breaking binary data compatibility across upgrades: aside from a few special cases like fractional time support, an upgrade doesn't require rebuilding any of your tables.
Your explanation makes it sound like an incredibly stupid decision. I imagine what you're getting at is that 3 bytes were/are sufficient for the basic multilingual plane, which is incidentally also what can be represented in a single utf-16 byte pair. So they imposed the same limitation as utf-16 had on utf-8. This would have seemed logical in a world where utf-16 was the default and utf-8 was some annoying exception they had to get out of the way.
OK, but that makes perfect sense given utf-16 was actually quite widespread in 2003! For example, Windows APIs, MS SQL Server, JavaScript (off the top of my head)... these all still primarily use utf-16 today even. And MySQL also supports utf-16 among many other charsets.
There wasn't a clear winner in utf-8 at the time, especially given its 6-byte-max representation back then. Memory and storage were a lot more limited.
And yes while 6 bytes was the maximum, a bunch of critical paths (e.g. sorting logic) in old MySQL required allocating a worst-case buffer size, so this would have been prohibitively expensive.
This still makes no sense. The UTF-8 standard was adopted really in 1998-ish and the standard was already variable using 1 to 4 bytes. MySQL 4.1, which introduced the utf8 charset, was released in 2004.
Even if there were no codepoints in the 4-byte range yet, they could and should have implemented it anyway. It literally does not take any more storage because it is a variable width encoding.
> The UTF-8 standard was adopted really in 1998-ish and the standard was already variable using 1 to 4 bytes.
No, it was 1 to 6 bytes until RFC 3629 (Nov 2003). AFAIK development of MySQL 4.1 began prior to that, despite the release not happening until afterwards.
Again, they absolutely should have addressed it sooner. But people make mistakes, especially as we're talking about a venture-funded startup in the years right after the dot-com crash.
> It literally does not take any more storage because it is a variable width encoding.
I already addressed that in my previous comment: in old versions of MySQL, a number of critical code paths required allocating worst-case buffer sizes, or accounting for worst-case value lengths in indexes, etc. So if a charset allows 6 bytes per character, that means multiplying max length by 6, in order to handle the pathological case.
How does the API know that it's a secret, though? That's what's not clear to me from the blog post. Can I e.g. create a customer named PLACEHOLDER and get a customer actually named SECRET?
The point is that without semantic knowledge, there's no way of knowing whether the API actually considers it a secret. If you're using the Github API and have it listed as an approved host but the sandbox doesn't predefine which fields are valid or not to include the token, a malicious application could put the placeholder in the body of an API request making a public gist or something, which then gets replaced with the actual secret. In order to avoid this, the sandbox would need some way of enforcing which fields in the API itself are safe. For a widely used API like Github, this might be something built-in, but to support arbitrary APIs people might want to use, there would probably have to be some way of configuring the list of fields that are considered safe manually.
From various other comments in this thread though, it sounds like this is already well-established territory that past tools have explored. It's not super clear to me how much of this is actually implemented for Deno Sandboxes or not though, but I'd hope they took into account the prior art that seems to have already come up with techniques for handling very similar issues.
Say, an endpoint tries to be helpful and responds with “no such user: foo” instead of “no such user”. Or, as a sibling comment suggests, any create-with-properties or set-property endpoint paired with a get-propety one also means game over.
Relatedly, a common exploitation target for black-hat SEO and even XSS is search pages that echo back the user’s search request.
And if it’s tab delimited usually people call them tsvs.
reply