This attack is on the early models that didn't have those protections enabled. The researcher surmised that later models do indeed have anti-glitching mechanisms enabled.
I'm not saying there's definitely no coordination, but nobody had to get together to decide that 2026 was the year for 90s fashion to make a comeback. Human society is very prone to fads in all areas.
They may be including maintainers who are explicitly employed to maintain the respective projects (e.g. some RedHat employees). This is not common, but not vanishingly rare either.
Just because the US won’t literally run out of oil doesn’t mean the economy (or populace) will be unaffected by a supply crunch. As everyone in the country can already see when they go to fill up their tank.
Large DDoS botnets will have hundreds of thousands of return-path-capable IP addresses. Your temporary blocks will have to be very sensitive (i.e. trigger on a relatively small number of requests within the time window) for an application-level DDoS to be usefully mitigated.
Once an IP in a botnet attacks someone, it ends up on a blocklist and can’t attack anyone else who uses that blocklist. This is a big part of Cloudflare’s DDoS model: if you attack one CF property (with non-volumetric DDoS) you will not be able to attack any others with the same bot for an extended period. This makes attacks to CF properties limited in scope and way more costly, because you have to essentially “burn” IP addresses after sending relatively little traffic.
Considering nobody blocks the entirety of Verizon, apparently a long time. You can act like this is some insane plan, but it’s happening all the time and while it can lead to annoyance for end users the internet chugs on. Which it wouldn’t if there was no way to mitigate DDoS other than rate limits.
The law can be bad and a specific legal argument against it can be wrong at the same time. Would you logically accept (as opposed to mere political convenience) every potential argument whose conclusion is that this law is invalid? If not, does that mean there is something “wrong with you”?
On the object level: giving medical advice is a form of (literal) speech. If you want to practice medicine and give medical advice as part of that practice, there are tons of constraints on what you can say to patients. The argument you’re laying out here is clearly too general.
RAM is always storing something, it’s just sometimes zeros or garbage. Nothing in how DRAM timings work is sensitive to what bits are encoded in each cell.
The attestation actually has nothing to do with the browser, only the holder of the passkey's key material. You can satisfy the attestation by having a passkey on your Android device and doing the normal Bluetooth flow with your Firefox browser on your Framework laptop. So this mechanism is totally useless for enacting this plan.
The operating system doesn't manage attestation because that's totally useless for the stated goal of the attestation system. Enterprises don't want their SaaS vendors to accept passkeys from some random employee's BitWarden, instead of the hardware keys they issued the employee. If the OS manages attestation and doesn't send anything to the relying party, then it doesn't solve anybody's problem at all.
It seems like it will only be a matter of time before consumer sites start requiring a patched OS with an attestation bit set in the key.
Also, as I understand it, sites can whitelist credential hardware.
If not, then the attestation is security theater. I (or an attacker on your machine), can just make a sw emulator of a hw attestation device, and use that to protect my choice of OS, (and skim your credentials).
If a whitelist exists, then my “hijack your OS” plan works: Require the builtin macos/windows/signed chrome on signed os password managers. That’s 90% of the market (and dropping) right now.
As I said, the attestation structurally does NOT attest to your OS or your browser that are displaying the website performing the authentication. It attests to the device that holds the passkey's key material, which is usually not your desktop computer.
Yes, but the attestation does not tell the RP anything about the browser. The whole point of the nightmare scenario above was for Google to sneak browser attestation in via passkey attestation. The browser being able to see the attestation doesn’t matter for that.
That's a matter of implementing an open standard. Google hasn't done anything to prevent open source browsers and OSes from implementing it, and nothing in the spec makes it difficult for Firefox/Linux specifically AFAICT.
An open standard that has attestation in it which allows sites to block all open implementations. FIDO Alliance spec writers have even threatened that apps like KeepPassXC could be blocked in the future because they allow you to export your keys.
The export is end to end encrypted, so you do not have ownership of the data, and the provider (Apple in this case) has full control over who you are allowed to export your keys to. (Notice how there are no options to move your keys to a self-hosted service.)
Most of these systems already do this, especially since very few applications have a flat encryption key hierarchy regardless of passkeys. The counterpoint would be that not everyone will set up multiple passkeys unless you require it on sign-up, but you're going to have that problem with any other method of storing end-to-end encryption keys. Might as well piggy-back on the password manager's replication methods.
reply