alcari

The parser as described _only_ cares about identifiers; it has no concept of operator precedence, which is not required for its purpose.

This is a cool idea. Please don't take the below as gratuitous negativity, just a reminder that these are hard problems for which there are no general solutions.

The README says it was tested on ZFS, but I doubt its utility in real-world deployments. I don't know of anyone who has significant data in a ZFS pool that isn't one or more of: raidz, compressed, encrypted, or embedded_data.

raidz implies that logical blocks aren't allocated as single physical blocks, but instead striped across multiple drives. Finding the SBX magic isn't enough to get you the rest of the block, but the checksum might (but, given that's it's CRC16, probably won't) let you try appending blocks from other disks to find the remainder of the block.

Transparent compression prevents you from identifying the magic header on each block, unless you decompress every disk sector that could have data (which is certainly feasible, but complicates recovery if you don't know which compression was in use, and zfs supports at least 3 kinds, and pools will generally have at least 1 in use whether compression is on or not).

Encryption (present in Oracle ZFS) means there's no plaintext data to recover.

embedded_data is a feature flag (and on by default in supporting versions of zfs) that packs blocks into block pointer structs when the amount of data is small. I can easily imagine the final block of an SBX, which may be mostly padding, getting compressed into one of those block pointers, which itself may be embedded in a larger structure which is part of an array that's compressed by default. That array is also probably long enough the compressed stream takes multiple blocks, and you may have lost some of the early ones, making the rest of it unrecoverable.

Regardless of the title editing discussion in the sibling comments, the title at the source was changed to "Omnibox hostname heuristics misunderstand internal redirects.", which accurately reflects the problem.

OpenJDK was created by Sun.

The client connects to the backend with a binary protocol that, among other things, gives it a token which it hands off to a web API that returns a valid cookie for the Steam store. They inject that cookie into the integrated browser instance.

That's the tech they already have on hand.

The rationale was that if, password hashes got compromised, the attacker would only have until the next forced rotation to crack the passwords and take over accounts.

edit: or, in particularly terrible systems, if plaintext passwords were leaked.

Of course, that's only useful if it doesn't affect any other password security concerns, and it turns out that users who are forced to change their passwords frequently pick worse passwords, which is a bigger problem than the scenario this was supposed to protect against.

The front page demo does it with the while loop.

The CPUs in question support up to 16 GB of LPDDR3 or 32 GB of DDR4, but do not support LPDDR4. Apple needs the LPDDR* variant to meet their power budget.

They're in the article, and the original post is linked at the end.