> Which consumer base has demanded enhanced security and convenience (for which passkeys are the proclaimed answer)? The non-tech crowd has no idea what it is and is probably just hearing about it. The tech crowd on a forum like HN seems to be mostly against it because of issues with account recovery and cross-device use that passwords don’t pose.
Yeah it's going to be mostly the tech crowd at this point, and it will filter down to non-tech people. And we will all be better off when we are all using passkeys. Looking at my girlfriend's computer her password situation is a nightmare of potentially compromised passwords, reuse of weak passwords, among other issues. Even after spending hours trying to clean it up there are still tons.
If we were in a passkey only world then no more weak passwords for her to reuse, no chance of phishing said password from her. Even if the server gets hacked there is no password to get pwned.
I really don't care what the contingent of passkey haters on here say. A lot of the discourse here isn't what it used to be. Little better than Reddit for techies.
> From what I understand, it seems like passkeys may ultimately rely on SMS OTP or similar mechanisms for account recovery. The other likely result would be losing the account forever, especially if the user is a single device one (there are billions of such people around the world).
That's not as I understand it. Why would SMS OTP be used? 100% of accounts today will already have a password, that's how you would login if you lose your only passkey device.
If/When passwords are not a thing anymore then why wouldn't the recovery use a "lost password" type flow that happens is facilitated via the account email?
> I’m going to wait it out a little longer to see how the interoperability factors play out in reality and learn from those who are braver than me.
Fair enough, but you can add a passkey to an account and your password will still work. So it's not like it will cause any harm to try it. You can even remove passkeys from an account if you really don't want to use it.
The worst thing about passkey support on Amazon is they didn't embrace it completely so you still have to go through all of the login form bullshit instead of being a one step biometric unlock that passkeys can enable.
> I really don't care what the contingent of passkey haters on here say.
I think what a lot of passkey advocates misunderstand is that this isn't a debate about what passkeys should look like once everyone has adopted them. It's a discussion about whether passkeys will ever get adopted.
Ordinary users are not going to use passkeys until these problems are solved. You're envisioning a world where everyone says, "there are tradeoffs, but we all made the switch and the security is better so tough luck." The reality is that fixing the tradeoffs are a precondition for passkeys to be a replacement for passwords.
The same industry that was incapable of teaching people how to use real 2FA tokens is not going to be able to teach them how to clone passkeys across devices. The discussion around passkey problems is not a discussion about how many people will grumble when passkeys eventually break into the mainstream. It is a discussion about whether passkeys are ever going to break into the mainstream at all.
----
Note that passkeys themselves are a response to this reality: it used to be that everyone talked about how cloud synchronization within an ecosystem was just too insecure and critics were going to have to get over the fact that it wasn't supported. This was a common debate on HN.
That changed, because it became obvious that passkeys were not going to happen without cloud sync and that roaming passkeys were a requirement, even if they made the standard slightly less secure. Now the same people are out saying that portability and better standardization among services is not the FIDO Alliance's problem to solve and people are just going to have to get over it.
And I don't think y'all understand how standards get adopted. Ordinary users are not going to get over it, they're going to refuse to use the standard. The first time they use passkeys and run into Amazon telling them that they can't log in from Firefox, they're going to walk away from passkeys forever.
> That's not as I understand it. Why would SMS OTP be used? 100% of accounts today will already have a password, that's how you would login if you lose your only passkey device.
I've been using passkeys on yahoo.co.jp for a while now after they prompted me to set it up.
It works fine on my Mac, but for whatever reason it won't see the passkey on my phone - it just pops up a QR code dialog and says to scan it on another device (my only other device is my Mac which won't scan QR codes). iCloud Keychain is syncing fine - regular passwords on other sites work.
Once that fails it drops back to SMS OTP. There is no option to log in with a password.
So as far as I see it, Passkeys are still an experimental technology. Passwords suck so I hope one day they figure out how to get it working.
Yes, the implementation is a challenge and the WebAuthn specs are even for experienced devs hard to understand (as it's an entirely new paradigm compared to other authentication methods).
In your case with your phone, I suspect that Yahoo has implemented some kind of device management and works with the WebAuthn request option AllowedCredentials to allow only certain credentials on a device (here probably something was messed up).
> Why would SMS OTP be used? 100% of accounts today will already have a password, that's how you would login if you lose your only passkey device.
> If/When passwords are not a thing anymore then why wouldn't the recovery use a "lost password" type flow that happens is facilitated via the account email?
Well, passkeys are descended from FIDO/U2F keys, which have traditionally been used for "two factor authentication" - by confirming both 'something you have' and 'something you know' your account is protected if someone has shoulder-surfed your password, or stolen your phone, or hacked your e-mail, or whatever.
And FIDO/U2F keys kinda a hassle, so they're only used by the most security-conscious people in the most security-critical situations.
For these people, a recovery mechanism that falls back to a single factor (password-only login, e-mail only login) is a big weakness, security-wise.
> That's not as I understand it. Why would SMS OTP be used? 100% of accounts today will already have a password, that's how you would login if you lose your only passkey device.
If we continue to do this, don't we then still just have all the same problems with passwords?
You're right about the level of discourse, and it's become especially obvious to me whenever there's a discussion about passkeys. Everyone keeps repeating the same debunked arguments over and over, with only maybe one argument (attestation) holding some water.
It's too bad, I'm really excited about passkeys increasing authentication usability (and security second, for me), but most people here seem to want to hold on to passwords, as if they aren't both terrible UX and terrible security.
There is not a single implementation from any major provider, including 1Password, that supports moving passkeys across ecosystems. When asked about this 1Password said that they're trying to lobby FIDO to support a migration spec but they don't have any timeline.
It's not that the arguments have been debunked, it's that advocates seem to almost purposefully misunderstand what people mean when they talk about attestation, portability, and account recovery. Registering multiple devices isn't portability. Keeping keys within a single ecosystem isn't portability.
Additionally, advocates ignore the current state of the ecosystem in favor of only talking about what the ecosystem is intended to be. A nontrivial number of services are using passkeys as a 2FA token. As a result, the current state of the ecosystem is that even ignoring the issue with providers, even websites themselves are not presenting a unified vision of what passkeys are intended to be. It borders on misinformation. No one is in alignment about what passkeys are, and multiple problems are being systematically ignored, and saying that the criticism is "debunked" isn't going to change that fact.
Attestation is a big barrier for self hosting which is the only way I'd adopt it.
But afaik the biggest implementation of passkeys (Apple) doesn't support attestation so right now it's not a problem, nobody requires it in order not to lose all the Apple userbase. This may change in the future though.
Another problem is no self hosted toolchain with full cross platform sync but hopefully it'll come.
Attestation is basically gone – it doesn’t work with cloud sync, which is largely where things seem to be moving.
My main concern at this point is user confusion, followed by platform lock-in.
Or am I missing a way for users migrate from the Apple ecosystem to Google or vice versa, for example, without registering new passkeys for all of their accounts before they trade in their old device (or it breaks and they try to recover on another platform)?
Not even 1Password supports exportable passkeys at this point. Apple even lets me easily share them across accounts (which seems like a huge risk!), but obviously not across ecosystems either.
I'm hoping bitwarden will start offering this. After all it's open source and with its own server you can self-host, so once it does we should be able to own it all ourselves. I also have zero interest in this if it means being tied into Google or Apple.
> Attestation is a big barrier for self hosting which is the only way I'd adopt it.
The issue I have with attestation it that I feel that I feel that we're saying "is it a problem?" "no, but it theoretically could be, so let's use passwords instead".
I think that passkeys are better than passwords, even with attestation, and if it becomes a problem, we can complain about it then.
Attestation is a huge problem because it can be used to exclude self-hosted systems, which is the only way I would even consider using passkeys. I abhor "sign in with Google/Microsoft/Meta...etc" things too.
For example the admins at my work refuse to "certify" any security keys other than yubikeys. And because those do support attestation it is not possible to circumvent it. For work it's not an issue, they will just have to supply me a key if they want me to use the damn thing, but I don't want consumer-focused sites to use it obviously. Attestation is inherently evil and anti-FOSS.
I just won't opt in to it until attestation is gone, but thanks to iCloud not offering it, it is currently not demanded by any of the sites.
Mac computers are more capable than they have been for a long time, if ever. All it takes is for a developer to have the will to make it work on Mac.
Recent game releases for Mac include:
- Lies of P
- Baldurs Gate 3
Soon - Resident Evil 4
Slightly older release - Resident Evil Village
Maybe Valve just can't hack it? They also flamed out on their VR support a few years back, only releasing a few betas before they gave up and cancelled the whole thing.
iOS 17 has multiple and named timers, why make a rant when a major part of it is already a non-issue?
To fix your confusion:
Timers - generally considered one time. If you swipe away the notification the timer is finished. If you press the circular arrow button it will restart the timer. Pretty obvious. On the Lock Screen they are clearly labeled as "Done" and "Repeat"
Alarms - by default alarms are set with snooze on. Swiping away will snooze. There is a "ZzZ" and "X" button on the notification. On the Lock Screen they are clearly labeled as "Snooze" and "Stop". If the snooze function is disabled on an alarm the only option is to stop the alarm.
When I posted the comment, iOS 17 had been out... ~1 week? You really think everyone upgrades in lockstep on day 1? I've been annoyed by this for all the 4 years I've used an iphone.
I haven't upgraded yet, so I'm not sure what to make of your comment. But for pre-iOS17 the lock screen notification/dismissal view is anything but "clear" or "obvious"...
Who is complaining exactly? I think a developer identifying a weakness and building a tool to fix those weaknesses is great. Are you trying to say there aren't also tons of mouse tweaking software for Windows and Linux? Do you even know what this app does?
I typically buy gaming mice that don't necessarily have Mac support and just let macOS handle the mouse. It works sufficiently, not great but good enough for day to day stuff when I'm not using the trackpad.
I also use Windows for gaming and the built in mouse functionality is far from mind blowing. Not to mention that pretty much all 1st part mouse software on windows (and in general) is hot garbage. Ugly confusing UI, often slow and buggy and resource hogging.
For anyone interested in this App I would also suggest going to the Github page and checking the 3.0 Beta stuff which is completely different from the 2.0 version on their web page.
This app makes the scrolling really nice with a mouse it feels very much like the trackpad inertial scrolling.
The most interesting thing is you can assign different behaviors when you Click, Click and Hold, Double Click, Click and Drag, etc. various mouse buttons.
Other macOS mouse tweaking software I've tried are either too limited (ie. only adjusts scrolling, only adjusts mouse button assignment) or are way too complicated. I really don't want to have to keep track of multiple apps just to tweak the mouse. I like this app so far as it seem to cover everything with a nice simple UI.
Even in the objc-cocoa days, you could create a .xib, drag a few connections, and have this working with 10 lines of code (8 of which generated automatically by XCode)
A lot of these just seem like you aren't familiar with the Finder, did you check the menus, preferences, or do a web search for Finder tips?
- No folder tree you are correct. I don't miss it personally. Gotta just deal with this one I think.
- What way specifically does the search not work for you? It's incredibly powerful and you can search by file name, content, file type, creation date, etc.
- It should save the window size you last set it as on a per folder basis when you open a new window from a location. Don't really have any troubles with how it works personally.
- Finder has tabs. Command+T
- Not 100% clear on the problem exactly. If you're going into the wrong folder you don't just have to select a folder by the first character, just keep typing and it will jump to the matching folder name in a list.
- File -> Make Alias
- This one is a bit unclear too. Use spring loaded folders, or a new tab in the location you want to drop to or add the folder to the sidebar that you want to drop files to. Cut and Paste with same named files is a lot better than it used to be and basically works fine now, IMO.
- View -> Show Preview
- Indeed it is designed to keep people away from the system files. 95% of people shouldn't be in there. And of the remaining 1% most of them shouldn't either even if they think otherwise. :P
If you actually need to muck in the system files you can toggle their display in the Finder via a terminal command.
- Command + Up Arrow to go up a directory
- You can open a directory in the terminal easily in a number of ways, including dragging and dropping the folder into the terminal window or icon, using the services menu, etc.
- I don't really find drag and drop copying to be slow in general, are you on a spinning HDD? Anyway with High Sierra the new APFS will make copying files instantaneous.
- There are various services you can use or you can create your own automator services, folder actions etc. to do a multitude of things.
- Finder is decently clutter free IMO, AND it can do a lot of sophisticated things as well.
I'm not GP, but I recently sank time into trying to change Finder searches to default to the current directory instead of my entire machine. It mildly infuriates me that I can't change this; I gave up after I saw com.apple.finder.plist is not plaintext.
Plist files have two standard encodings, an XML-based textual one and a binary one. You can use plutil to convert between the two, e.g.
plutil -convert xml1 com.apple.Finder.plist
However, for preferences you probably want to use the `defaults` command instead, because IIRC they’re managed by a daemon (cfprefsd) that might not notice if you modify the backing files while it’s running.
The two different encodings aren't just for config files; property lists are used throughout the OS for all sorts of things. They're a serialization of standard data structures such as arrays and dictionaries: same idea as JSON, decades before JSON. In retrospect, the XML-based text format is excessively verbose, but back then XML was all the hotness… As for the binary format, well, even given JSON's relative succinctness, there are many different formats that attempt to fill the role of 'binary JSON' (BSON, BJSON, JSON-B, MessagePack, CBOR, UBJSON, Fleece, PSON). It's just that none of them have become ubiquitous, probably because of some combination of fragmentation and the lack of built-in browser support.
As for the daemon, among other benefits, it allows preference changes to be immediately visible across all processes on the system, rather than requiring manual action to reload from disk. See:
Uh, no. I wrote that something 'showed up on my twitter feed', implying it's unverified. Last night there wasn't a way to verify it, it merely seemed plausible. In any case, the Huffpost article sufficiently makes the case.
https://www.youtube.com/watch?v=hmiJ0OzFKd0