Pretty much. ES6+ scores are from running compat-table's test suite (https://compat-table.github.io/compat-table/es6/), along with their weighting. If you click on an engine's name to go to a page about it, there's a report at the bottom with failing tests.
I never understood this complaint. You won’t get a “loop trace” when you convert your tail calls into an iterative algorithm. And your code will be less readable to boot.
V8 team decided that it's not worth it, since proper stack traces (such as Error.stack) are essential for some libraries, such as Sentry (!). Removing some stack trace info can break some code. Also, imagine you have missing info from the error stack trace in production code running on NodeJS. that's not good. If you need TCO, you can compile that code in WASM. V8 does TCO in WASM.
Most Bun users don't even know about this (unless they are bitten by this). That doesn't mean absolutely no one cares or would not care even though such complaints might be uncommon.
Supposedly, although the team at Apple were able to implement it. I think they had some oddly named technology like Chicken which created a shadow stack trace? Half remembered.
Yes, It's called ShadowChicken, and it has negative implications for debuggability. To make debugging tolerable, JavaScriptCore added an (intentionally silly) mechanism called ShadowChicken: a shadow stack used by Web Inspector that can show a finite number of tail-deleted frames (they mention 128). It's has some tradeoff.
V8 team decided that it's not worth it, since proper stack traces (such as Error.stack) are essential for some libraries, such as Sentry (!). Removing some stack trace info can break some code. Also imagine you have missing info from the error stack trace in production code running on NodeJS, that's not good. If you need TCO, you can compile that code in WASM. V8 does TCO in WASM.
I agree 72 characters is plenty for most circumstances. However, as the blog points out, this is a byte limit not a character limit.
Some of the family emoji can be > 20 bytes. Some of the profession emoji can be > 17 bytes. If people are using emoji in their passwords, we could quite quickly run out of bytes.
I think it’s a limitation worth being aware of, even if “unsafe” is perhaps overstating it.
I still don't see how that's an issue, yes a password using a series of ridiculously complicated family emoji will be truncated but the actual bytes still provide entropy, just because the data doesn't use pixels when rendered doesn't mean it doesn't increase the search space
If your password is comprised of three emojis that each take up 24 bytes, then yes, a 72 byte truncation dramatically reduces the search space for a brute force against these hypothetical 24-byte-emoji-only passwords.
There are far fewer possible combinations of any three emojis than there are any 72 ASCII characters.
This is x^3 vs y^72, where X is the total number of distinct emojs and Y is the total number of distinct ASCII characters.
24 bytes of data is not 24 bytes of entropy if there are only a couple thousand different possible inputs to produce all of the possible 24 byte sequences produced by those inputs.
For simplicity: picture having only two possible input buttons. Each one produces 1000 bytes of random-looking data, but each one always produces the exact same 1000-byte sequence, respectively. You have a maximum password of 1 button press. The "password" may contain 1000 bytes, but you only have one bit of entropy, because the attacker doesn't need to correctly guess all 1000 bytes, they only need to correctly guess which of the two buttons you pressed.
Of course, in practice, not all emojis are 24 bytes, and I'd assume few people are using emoji-only passwords, but the distinction between bytes of data and bytes of entropy is worth clarifying, regardless.
I would argue that a password containing emojis is unlikely to ever be cracked, because no attacker is going to test emojis unless they have some reason to believe you use them in your password.
Attackers don't come up with every entry on the wordlist they throw into hashcat themselves. The attacker's imagination has essentially zero correlation with the contents of their wordlist.
Rest assured, the world's intelligence agencies and cybercrime rings aren't just taking vanilla open source wordlists off github and hoping they get lucky.
You don't know what your adversary's wordlist contains, and assuming you do is a recipe for overconfidence.
Yes, "if your enemy is state sponsored attackers" you shouldn't do many things, like use bcrypt incorrectly, or really passwords almost at all. That's obviously not what I'm saying.
The hash is 24 bytes. Even without an input character limit, you're likely to find tons of valid aliases for your 1000-character password within the 72-byte password space.
I never actually considered it until I read parent, and now I'm gonna try to start using it wherever it's supported, it's genius to use it for passwords as long as it's supported by the platform. Edit: Just to clarify, together with a password manager of course, otherwise I'd never have the patience for it.
Correct. The Beatles appearance on Top of the Pops survives only because a clip from that show was used in episode 1 of The Chase.
Ironically, The Chase often has rights clearance issues when it comes to home release because of this. Beatles music costs a fortune to clear, making releases untenable.
Double ironically. This is because the Beatles chose to mime to their studio record for Top of the Pops. If they had played live, it would have been less of a problem.
But all it takes in that world is for a single browser vendor to decide - hey, we will even render broken XHTML, because we would rather show something than nothing - and you’re back to square one.
I know which I, as a user, would prefer. I want to use a browser which lets me see the website, not just a parse error. I don’t care if the code is correct.
On the one occasion I met Steve Furber, he told me about how when they connected up the very first chip, he was surprised that the it started running before he had even connected the power.
Turns out the design was such a low power design that just the voltage from the data lines was enough to run the chip.
I assume this is the reason they're characterising this as "PHP License V4 will have identical wording to BSD-3" rather than "We will switch license to BSD-3".
It amounts to the same thing, but the former framing means they're covered by the "or later".
It is not unreasonable to try and write in a fashion which attempts (perhaps unsuccessfully?) to coax people away from Mercola’s world. Even if you are fully steeped in that alt-med rabbithole, I would hope the revelation that Mercola’s information often comes from ChatGPT (“because it has no reason to lie”) would be enough to give someone pause.
Perhaps it’s not, but fair credit to the compassion of the author for the assumption that it might.
(Disclosure: I know the author personally, though we have not discussed this topic)
reply