> Android 16 no longer provides device trees for Pixels as part of the Android Open Source Project. It's important to note it doesn't provide those for any other devices. There are no other OEMs providing similar AOSP support. [...]
Way back before I made the jump to a Nexus S, I was maintainer of a CyanogenMod port. Granted there were other challenges involved with that (bypassing locked bootloaders with kernel module exploits) but I am well aware of what's involved. What Google is doing is a fucking waste of people's time for no reason whatsoever. And it's not just on the AOSP front--it's clearly a strategic platform decision.
I'm done with Google. On every front they are being assholes. The DOJ should have exploded Microsoft into bits and pieces back in the day the way they handled AT&T so that Google would fear the same.
AFAIK the impact of that is overblown, because "device trees" are just files that can be extracted from the stock ROMs. Moreover drivers and kernels are still provided by google, albeit in code dump format (no git history).
The screen is a 16:10 screen with some extra pixels added next to the notch.
By default, the system uses a resolution of 1512x982 (14"), which you can change to 1512x945 (16:10) to move the menu bar below the notch and end up with black pixels next to the notch.
"If you go make weird contortions and workarounds you might just find a semi-working non-solution to a problem that didn't exist until Apple introduced it".
> a feature that can only be appreciated by a subculture of people (privacy advocates)
Just because it can’t be “appreciated” by all users doesn’t mean it’s only “for” a small sub-group.
It seems to me they’re just trying to minimise the data they have access to — similar to private cloud compute — while keeping up with the features competitors provide in a less privacy-respecting way. Them not asking for permission makes it even more obvious to me that it’s not built for any small super privacy-conscious group of people but the vast majority of their customers instead.
What you write sounds plausible at first, but then there’s this example from the German KSK:
„In 2018, the German Federal Criminal Police Office uncovered a plot involving unknown KSK soldiers to murder prominent German politicians such as Claudia Roth, Heiko Maas and Joachim Gauck among others, and carry out attacks against immigrants living in Germany.[7] Also, earlier that same year in a separate investigation, the State prosecutors in the city of Tübingen investigated whether neo-Nazi symbols were used at a "farewell" event involving members of KSK.[8][9]
In June 2020, German defence minister Annegret Kramp-Karrenbauer announced that the unit would be partially disbanded due to growing far-right extremism within the ranks.[10] The KSK had become partially independent from the chain of command, with a toxic leadership culture. One of the force's four companies where extremism is said to be the most rife was to be dissolved and not replaced.[11]“
It’s recommended to have at least two anyway, to still have access to your accounts in case one is lost. That means you can keep one key at your desktop and you’d only need to go up to get your keys when adding them to an account.
Having two in the same house is a pretty bad compromise. Ideally you'll want one of them to be physically somewhat distant (in case of a fire etc.), which makes things even less ergonomic.
The downside of this (at least in my personal view) is it's a regression from the elevated security you got with non-resident FIDO/U2F MFA.
The moment you go "passkey" and have to use a system like the one you suggest, you need to trust software based storage of long term credentials.
That isn't the case with a hardware FIDO2/U2F token, which has unlimited capacity for non-resident MFA keys the server holds for you to decrypt and use locally to sign login attempts.
I liked that FIDO seemed to get towards hardware backed security modules for login, without cognitive load of worrying about number of sites and yubikey slot capacity. Resident Webauthn keys limit the number of sites you can have, and push you towards software based solutions (so you lose out on doing the crypto on the single purpose, limited platform that's dedicated to generating those signatures).
I agree that it's annoying that there's now a limit on the amount of credentials you can store on hardware keys. But while older Yubikeys only support 25 resident keys, models with firmware 5.7 onwards support 100. That probably makes it feasible to exclusively store passkeys in hardware.
https://www.yubico.com/blog/empowering-enterprise-security-a...
However, I don't know whether it's possible to delete only a single resident key you no longer need.
Yeah, a fair point (though if you can't manage keys one by one that seems a massive usability issue and oversight with no safe path to resolution).
This adds another step needing considered for a user, as finite storage means a whole edge case to consider (can't register as slots full), and no simple actionable step to take ("which account would you like to never be able to log into again?" or "sorry you need to wipe this key and lose everything, or buy another one")
I feel there is a usability aspect of FIDO2 (for non-resident MFA) that is being overlooked - the paradigm was simple - a physical key you don't lose, and you can have multiple keys. The gotcha was no way to replicate backup keys, which becomes fairly difficult for users. But hey - passkeys launched with no export or migration process between closed device ecosystems!
From my perspective though, I won't use passkeys until I get sufficient control over them to be allowed to decide if I want to make them "resident" or not. (I don't want resident keys!!)
I want to use non-resident keys everywhere as a hardware-backed second factor that is phishing resistant, without capacity limitations (so zero cognitive burden on whether to use or not).
It feels like a regression for passkeys to be forgetting about what (for me at least) was the core basic use-case of FIDO2 - as a highly secure second factor for someone who already can manage storage of secrets in software, and just wants high assurance phishing resistant MFA during their conventional login process.
I'm honestly very annoyed with Yubico that they just froze their product line-up circa 2018 and pretend the major changes in firmware (5.2, 5.7) don't matter at all and don't warrant a separate SKU.
I haven't really looked into it myself, but it seems to be using the same database format as KeePass, and it hooks into macOS's "FIDO provider" API, which makes it accessible to not only Safari but all browsers that use it (which includes Firefox and Chrome on macOS, and probably everything on iOS), without requiring any browser-side extension.
The time investment could even be worth it, since "Signing in with a passkey is three times faster than using a traditional password and eight times faster than a password and traditional MFA", according to the article.
-> My back-camera lens is shattered. Using the front is dodgy at best. I don't feel like I need fork out for an to upgrade as I use a digital camera if I want to take pictures.
Register a passkey on a different device or get a hardware key or whatever. Or call Microsoft support and complain to them. This doesn’t feeling like an honest discussion anymore.
There are syncable and hardware-bound passkeys and you are free to use a password manager that syncs your passkeys. iPhones don’t even let you create a passkey with the built in password manager if you have synchronisation disabled. I don’t know for sure if Google does the same but I expect them to.
If you’re remembering all your passwords there’s a good chance they’re terrible, you frequently re-use them or both. That really helps attackers e.g. when they use leaked passwords to run credential stuffing attacks on your employer.
You just wrote two comments bashing a technology you admit you didn’t properly educate yourself about.
Except, you can't sync the iphone's passkey with non apple products. And it's still tied to your apple ID, which uses a password. This in theory, defeats part of the point. (It's definitely better than the alternative though)
For android, the passkey is clone-able iirc, but again, it's an expensive smart device.
So now I am expected to have at a minimum, two use-able smart phones, per family member.
Iphone? Frankly, fuck that shit. Too expensive.
Android, I can manage it. But doing that for all family members is not financially viable.
Also I do use a password manager and an encrypted text file. (Not smart, I know. The file is basically a backup)
But I really cannot expect people like my mother to understand how to set up a passkey. Much less, how to setup multiple for the off chance one is lost. Add onto the fact that Yubikey does not support twins, and many services do not support multiple passkeys.
In terms of computer literacy, using my mother as a baseline (Age:Mid50s) the current passkey system is non-viable.
The "how do you recover from zero devices" problem is a real one. It's not a problem at work because you have a root of identity and access to a human (your IT dept) who can reset you. For public services like Google, if you lose your recovery methods then go fuck yourself.
Something I know is the only authentication method that can't be physically destroyed. When your customers are the masses every failure mode that can happen will happen, usually at the most inconvenient time.
What sucks about passkeys in abstract is that you want at least two failure modes that are uncorrelated— you're unlikely to forget your password and have your house burn down at the same time. Passkeys consolidate everything into to physical possessions which can be and are destroyed all at once.
