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).
What about this ban is anticompetitive? The only think I can think of is accusing them of dumping product (as opposed to price discrimination), in which case the remedy is going to be to making them charge the API price for everything.
The issue with them being a monopolist is less about competition and more about the fact them penalizing you on one of their products can result in them deleting you from the Internet. You can lose decades of email history, the ability to publish apps on over half of the mobile devices on the globe, etc.
In Europe the Digital Services Act (DSA) is beginning to set expectations, particularly for large platforms about not just clear documentation of their terms, but also a meaningful human appeal process with transparency and communication requirements for actions taken.
The DSA is more focused on social networks, but if you were to apply the concepts of the DSA to this story, Google would have violated it several times over.
How useful is a GPS position for theft prevention? IME cops are not interested in doing more than filing a report after a theft, even if you have a live GPS location of the item for them. Do you try and go get it yourself?
i can speak to this as i had my motorcycle stolen on NYE last year in Santa Monica with an airtag in it. the Santa Monica police said “smart, but it’s in LA so we can’t help you get it. tell the LAPD.”. it took me seven hours of calls to the LAPD while personally hunting down my bike in the shadiest areas of LA, and being a block away from getting it myself, did they come. so yes, if you’re in LA, you basically get it yourself.
in my case, the damage was so much i wish i had just left it stolen and taken the bigger insurance payout.
GPS won't prevent theft, but can help in recovery. Can.
But Apple does more stuff as well, like encrypting your phone and making it so even harvesting a stolen phone for parts is unattractive (everything has serial numbers and you can't just swap a part out).
IPs owned by Iranian entities could be blocked straightforwardly by network operators at various levels. They could probably fudge the paperwork via Russian or Chinese entities and obfuscate the routes with cooperation from Russian/Chinese network operators, but that would take time.
If they mean a real proxy, that’s even more involved - you can’t just do that with BGP configurations and will need someone running what is basically a country-wide VPN in Russia or China (which will probably be very identifiable).
I’m really not sure what you’re going on about. Russia and China won’t cut off Iran and will be more than happy to have them pay to connect to VPN providers in country (eg the routes advertised will only let them connect to VPN providers). Or you can use botnets to proxy your traffic for you.
Okay, but now you’re running a country-scale VPN service in Russia or whatever, and somebody has to pay for it. Or you have to acquire a botnet, again to handle the internet of a whole country. These are non-trivial barriers to overcome, and simply having transit to Russia does not solve them.
You know they can run NAT at the border right? Iran -> Russia -> the rest of the Internet. Russians would never re-advertise Iranian routes, and because they're all such good pals they could let them use whatever segment, so all Iranian traffic would simply appear as Russian traffic to the rest of the Internet, using normal residential subnets of which there are plenty. No need to ever involve the commercial VPN providers, and the scale would be negligible considering we're only talking about "the elites" of which there aren't many.
But also Wireguard VPNs are also trivial to spin up and operate at scale, especially since what’s being discussed here is Internet access just for the elites which is a small fraction of the entire population. But yeah, lots and lots of ways to make this work if you don’t get everyone else to go along with your embargo.
Does the Iranian economy rely heavily on access to the global internet? They can’t trade with most of the world due to sanctions, so what in their internal economy grinds to a halt without global communications? I’m not saying I think that it wouldn’t, just that I don’t immediately grasp the mechanism.
Good points! I’m not an expert, so I’ll wait for people who know more to weigh in. But as far as I know: (1) they still need to import basic necessities like food and medicine, and (2) despite heavy investment, they haven’t managed to build an intranet that’s fully isolated from the internet.
Even if you don't have fiber all the way into your house, most cable internet terminates pretty close to the home these days. It kind of has to, since bandwidth has gone way up and as a result they can't put very many subscribers on the same termination system.
We didn't really understand this kind of thing when the Carrington event happened, so nobody knows for sure, but estimates for induced voltage on long conductors are usually something on the order of 20V/km. So for a 5 km long coaxial cable, you're only talking about ~120V of induced potential difference (i.e. the same voltage as a residential plug in the US). When people are analyzing the potential damage from this kind of electromagnetic disturbance (E3 is the term you'll see, based on analysis of nuclear EMP which has other components that you don't see in geomagnetic storms regardless of severity), it's mostly about really long conductors, like on the order of 100km.
Interesting - I found this quantitative historical study [0] showing that while a civil war does significantly increase the likelihood of inflation, only 36% of countries analyzed which had a civil war between 1975-1999 ended up in an inflationary crisis. And with the USD having such a strong foundation, I would expect the risk to be significantly lower.
I am speculating wildly but I would expect the exact opposite due to different actors trying to destabilize the US to the point of no recovery in such an event.
They're threatening to take their ball and go home. If they move all of their operations out of Italy, under what principle does Italy demand they block content globally? Should Wikipedia remove their page on Tiananmen Square because the Chinese government demands it (which they would, if they thought it would work)?
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.
reply