This part of their requirements for how PCC is architected directly addresses your concern:
“Verifiable transparency. Security researchers need to be able to verify, with a high degree of confidence, that our privacy and security guarantees for Private Cloud Compute match our public promises. We already have an earlier requirement for our guarantees to be enforceable. Hypothetically, then, if security researchers had sufficient access to the system, they would be able to verify the guarantees. But this last requirement, verifiable transparency, goes one step further and does away with the hypothetical: security researchers must be able to verify the security and privacy guarantees of Private Cloud Compute, and they must be able to verify that the software that’s running in the PCC production environment is the same as the software they inspected when verifying the guarantees.”
No, it is not. And if you fall in love and want to get married to someone on a student visa, your fiancée should not need to leave the country for a year or two to wait for paperwork to process. Which is one of the real world impacts of this change.
This is true at companies that treat security as a checkbox driven by compliance.
Not true at top-tier tech companies building software in product categories that by their nature have very high security requirements, like Fintech (e.g. Coinbase, Mercury bank, Wise).
This is the bill referenced at the end of the TechCrunch article:
> Last week, Wyden and several other lawmakers introduced a bipartisan, bicameral bill called the Government Surveillance Reform Act, which among other things would require a court-authorized warrant before federal agencies can buy Americans’ information from data brokers.
Passwords are terrible UX for old people in my experience. They try use the same password everywhere, but then password complexity requirements mean they can't use the exact same password everywhere, and then they forget which variant they used on which service, so they just end up going through the reset password flow every time they sign in. I am not convinced that's a better UX than them just using their fingerprint or face to login.
>They bind you to your device/iCloud/Gaia account so if it gets stolen/banned you're out of luck
This is the biggest myth/misconception I see repeated about passkeys all the time. It's a credential just like your password. If you forget it, you go through a reset flow where a link is sent to your email and you just setup a new one.
And if it happens to be your Gmail account that you're locked out of, you need to go through the same Google Account Recovery flow regardless of whether you're using a password or a passkey.
I am not sure if you missed my earlier comment, but it's directly applicable to this point you've repeatedly made:
>If Apple believes this class of attack is no longer viable, that’s worth stating.
To say it more directly this time: they do explicitly speak to this class of attack in the keynote that I linked you to in my previous comment. It's a very interesting talk and I encourage you to watch it:
Apple's head of SEAR (Security Engineering & Architecture) just gave the keynote at HEXACON, a conference attended by the companies who make Pegasus such as NSO Group.
That doesn't seem like avoiding the elephant in the room to me. It seems like very much acknowledging the issue and speaking on it head-on.
Finneas (Billie Eilish's brother) isn't one for virtue signaling from what I've seen over the years from his posts. He keeps it very real and down to earth as far as celebrities go.
Both of the major smartphone companies (Google and Apple) have pretty robust account recovery processes. Are you familiar with all the options they have? Your comment gives me the impression that you are making assumptions about what would happen, instead of doing research on how it actually works.
I experienced Google's recently and it was very robust.
Even before passkeys, the average user would have major problems if Apple and Google didn't have good account recovery processes.
There's nothing different about using a password vs. a passkey that makes it easier or harder for vendors to lock you out. I am not sure where this misconception comes from.
Whatever process a vendor requires someone to go through in order to gain access to someone's account when they pass away remains the same whether the user previously used a password or a passkey to login.
Are you aware of any vendor that actually does have differing policies based on the account's login credential type? I'm not aware of any.
(1) is already true today. There is no way for services to enforce whether a passkey is stored in software or hardware.
(2) I understand you don't like the user experience. But to make a technical clarification: requiring a user action to prove there's a human involved in the login action (e.g. by clicking a button in UI or requiring Touch ID) does not necessarily mean there's another factor involved at all (MFA). What you are describing is more of a "liveness check" than a separate factor/separate credential.
In theory any code could be written at any time that does something good or bad. Sure.
But in reality, the people who actually work on these standards within the FIDO alliance do not want a world where every website/service makes arbitrary decisions on which password managers are allowed. That would be a nightmare.
The primary credential a user relies on for logging in (whether it's a password or a passkey) is pretty unrelated to the the "lockout issue". The lockout issue is really the age old question of: what happens if I can't do a normal email-based account recovery flow (aka "I forgot/lost my password/passkey").
People should be setting up Recovery Contacts so that they have a way of getting back into their Google account even if they lose all credentials (passwords and/or passkeys) and all their devices.
I legitimately wish there was an option for: "I show up for my appointments 100% of the time and I'll agree in advance to pay a giant fee if I ever don't show up, if you promise not to bother me with appointment confirmations every time".
Not sure why this is being downvoted. This user (palata) is correct — phishing is any attempt by an attacker to trick a user into giving up sensitive information.
“Verifiable transparency. Security researchers need to be able to verify, with a high degree of confidence, that our privacy and security guarantees for Private Cloud Compute match our public promises. We already have an earlier requirement for our guarantees to be enforceable. Hypothetically, then, if security researchers had sufficient access to the system, they would be able to verify the guarantees. But this last requirement, verifiable transparency, goes one step further and does away with the hypothetical: security researchers must be able to verify the security and privacy guarantees of Private Cloud Compute, and they must be able to verify that the software that’s running in the PCC production environment is the same as the software they inspected when verifying the guarantees.”