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.
Here's the requisite cynical comment lamenting the death of "standards".
They could easily have implemented RFC 3091 [0], but instead they chose to create yet another proprietary API with vendor lock in, just as cloud service providers love to do.
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.
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.
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 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.
Those are symmetric(!); the real killer is the contract duration, the installation/activation fees (up to $1000 total), and the installation time frame (up to 8 weeks).
From a quick look through, most of it. Modern x86 micro-architectures still use integrated memory controllers and ~3 level CPU caches.
All the timings are a little faster, the caches a little bigger, and the buses a little wider, but it's still basically the same stuff with different names.