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.
How many people are doing a spring cleaning of unused passkeys in their password managers? We're talking like a kilobyte of data, nobody needs to delete these things in any kind of normal circumstance.
Sure, it would be great if users would store 5 copies of their encryption keys, with one in a lockbox on the bottom of the ocean. But that's just not going to happen at any kind of scale, so an automatic way of putting encryption keys in a replicated password manager makes sense. And compared to how people normally handle end-to-end encryption keys, it's going to result in a lot less loss data in practice.
I don't know about spring cleaning, but it's pretty easy to delete by accident if you connect to the browser or OS when setting up instead of the password manager.
That said, I've been assuming I could have multiple passkeys per site and that's turning out to not always be something websites behave sanely about.
Most password managers implementing passkeys only allow one passkey per account entry, and I've ended up with multiple passkeys per site, while the site only supports one (and deletes the others upon creating a new one), so I've been in the exact situation of not knowing which entries are safe to delete before.
This is usually due to relying party and possibly password manager bugs, but it does happen.
I thought the point of passkey security is that you don't have to send the private key around, it can stay on your device. Different passkey per device. Lose or destroy a device, delete that passkey and move on.
None of the password managers (including but not limited to ones built-in iOS/Android) work that way. The Apple one (and I think Google is the same) keeps the private key inside the secure enclave (security processor), but it is still copied to each new device - though it is end-to-end encrypted during that transmission.
The issue there being there's a big usability headache with enrolling multiple devices. You really want one device to be able to enroll all your devices (including not-present and offline), but there's no mechanism to do this with the way the webauthn spec works at the moment.
That’s how I use them. Passkeys on two Yubikeys. And I tag in my password manager which credentials have what form of auth. UP, TOTP (also stored on the two Yubikeys), Webauthn or passkeys (the former indicating 2FA).
reply