Edit: Reading one of those issues it sounds like they want the keys stored in an encrypted way, is that too much to ask for? I dont care about viewing it but it shouldnt be stored in a plain easy to open JSON.
They are proposing an attestation scheme. I'm not sure the details are out yet, but the authenticator would presumably use one of the hardware security mechanisms (like a TPM bound key) to "certify" its own authenticity along with the challenge.
This will effectively ban all open-source implementations, and end user freedom if widely adopted. Fortunately for us it seems like Apple isn't cooperating here for now, and without Apple signing on, it wouldn't get anywhere.
Attestation is incompatible with having the authority conferred upon upstream automatically inherited by all forks thereof.
If you want your fork to have the same authority as upstream, you have to apply for that authority to be recognized and make your case that it deserves that. This is the problem with attestation: that it reintroduces human reputation authorities into the Wild West of computing.
If you’re going to argue successfully against attestation, you’ll need to focus on the actual problem rather than the distraction of source code licensing. The same attestation would be necessary whether the app you’re modding is closed source, open source, or a PICO-8 cartridge image: when attestation is in play, everyone knows you’re running a modded version, and they may choose to deny you service over that. That’s the problem attestation poses, and why arguments against passkeys fail so spectacularly to gain traction, by focusing on “open source” (irrelevant) rather than e.g. “right to be modify without being refused service”.
You can check my comment history to see the arguments I have against attestation. That's exactly what I argue. It's not an open source problem, it's a user freedom problem, and this is exactly why corporate interests like "open source", but not "free software". Open source is freedom-agnostic: you can use it to hurt users just fine. The current iterations of remote attestation is especially egregious, because most of it is the government itself or an entity the government forces you to deal with (banks).
In general I believe remote attestation is actually fine, so long as it does not transcend ownership boundaries. A company can use it to ensure its own colo servers aren't tampered with, for example. But an external authority shouldn't be able to exert control over something I own. In particular there should be no expectation that my device is "trustworthy" in any way at all. Anything else ends privacy and freedom as we know it.
This is the only point where I differ: it will effectively ban most implementations, with no regard for whether they’re open source, closed source, or private. 1Password could be open-sourced tomorrow and continue being an approved implementation, no sweat, because they can be trusted not to disguise and release “export your passkeys as plaintext at rest” functionality — but in today’s market, there are certainly a thousand implementations (whether source or not) that died on the vine, whose sole purpose would have been to circumvent that one restriction, far more than there are implementations that are willing to genuinely try to uphold it.
Glad someone else is fighting for repurposeability — but there is no universal answer for how to balance privacy, freedom, and security. It’s something people have to decide for themselves, and just as my phone has an “highest security, lower convenience” mode for certain scenarios, so too I wish it had a “no security, total modifiability” mode for other scenarios. (Even if that denied me app store access, and I would demand that it wipe pre-existing passkeys from the HSM when I enabled freedom mode, or else it’s just an uncontrolled attack vector!)
Remote attestation in general is a backdoor to software freedom and ownership bestowed on you by free software, in the same way that tivoization is. Tivoization prevents you from running a modified version of the software on the same hardware, while attestation discriminates against you for running a modified version.
I do agree we should have repurposeability, but that's mostly independent of this attestation topic, IMO. I also think the tradeoff between security/privacy and freedom is greatly overblown. There is some, but giving the user an adb root shell or ssh server with key will not significantly decrease security of the user on Android. (It might reduce the security of the apps against the user, but it shouldn't be there in the first place). I'd be fine with not having app store access if it isn't mandatory for daily life, but that's not the case in our world.
Well, they are encrypted but the issue is talking about exports. The maintainer of KeepassXC already mentions the issue with that: portability. A backup of such sensitive data (a password manager) is going to be stored somewhere secure (to the user) already. Why would you encrypt the contents and add another layer of complexity that other tools may not be able to handle? I want to be able to rely on those backups in the future and copy paste them around manually if needed. It's user choice, put simply.
A specification committee should never be deciding what a user does with their data, period. The security maximalist is always going to advocate for the most secure thing but most of the time that's not practical or friendly to humans.
- because I like backing up my data, especially credentials
- because I like looking at how things work in practice - you are on a website called hacker news after all
That's the key difference. If it mattered, they would make it part of the spec, not threaten a ban. That's even more concerning, there is a central group of people who get to decide who can and cannot use Passkeys.