Because, as one of the original GUIs, when they conceived of how the Macintosh worked, you used the command keys to perform actions on files, and you could rename the file just by typing. Cmd-O was the shortcut for opening files, which makes sense for obvious reasons.
When they released the Macintosh to the world, Andy Hertzfeld realized that people were renaming items in the Finder by accident; so he added the "return" key (already used to confirm actions) as an "arming" step[1].
Now, one might ask: wouldn't that interrupt people navigating via the keyboard? No, because the original Macintosh didn't have arrow keys on the keyboard. This was an intentional choice—or, perhaps, mandate from Jobs—as a way to get users to use the mouse as their primary input device, and to force developers to create mouse-driven interfaces. With no arrow keys, no typeahead search implemented, and a clean slate for designing an interface, I'm guessing using Return to open a file wasn't a strong consideration at the time.
Why wasn't it changed? Because Mac OS X was made for Mac users, and we all have muscle memory dating back decades :P
I can't imagine editing text on a keyboard with no arrow keys to be any better than the horrible experience of doing it on a mobile device... which might be why Apple decided to add them quite early in the history of the Mac.
It's also ironic that despite justifying the menubar at the top of the screen as being easier to hit, they then totally missed the awkwardness of not being able to navigate with only one hand by using the arrow keys and the nearby return/enter. Watching someone experienced using Windows' file manager with only the keyboard is almost vi-like in its efficiency.
Not sure if you're just talking about past design, but currently you can use arrow keys and enter in the menubar, tapping first letter of options to hops there, and can activate menubar with a keyboard shortcut of your choosing. You can also hop directly to help, start typing and get matches to select, all without a mouse.
As someone with a bunch of "USB-C" devices that do this, I'd wondered for years why nobody sold these. I recently just found them on Aliexpress in a more finished format (nice-looking case and such), so I'm hopeful they'll start to filter out into the world more. (If you're interested, do a search for "usb c resistor" and you'll find them for ~$2-$4.)
As positive as I can be without having bought one just yet. The ones I've seen specifically say they "solve the problem that low power devices cannot be powered via C to C", that they support 480Mbps data transmission, and are listed as 5.1K ohm resistor adapters.
Seconded. I went in with only a vague awareness of what Bois' thing is and knowing it somehow involved Tims, Als, and oceanic telegraph cables. I was not disappointed.
I was so steamed about this as a teenager back when it happened - pretty sure it was one of the foundational reasons I started to consider building my own gaming PC once I got the money together.
As an adult, and with the hindsight of seeing how Valve has (generally) supported their games over the years, I can appreciate gaben's reasoning for cancelling it... though as someone gaming on the Mac, we were all kind of used to being second class citizens and bodging together mod support and whatever, so I still think they should've let it come out.
> “Given the realities of the Mac gaming market, our Mac customers were… always going to be second-class customers where we couldn’t invest to the same degree in the Mac version as we did elsewhere,” commented Newell. “I don’t want to be in that business. I would much rather we just eat the money we’ve spent so far than take money from Mac customers and shortchange them.”
Of course, if Rebecca is to be believed (per the above interview)...that's not at all why they cancelled it. They cancelled it because Valve was pissed off with Apple for lying to them about the size of their userbase, and then unilaterally decreed henceforth that no Valve game would ever see a release on an Apple platform.
Ah, interesting - I saved the video but haven’t gotten around to watching it yet. I don’t know if this is touched on, but it certainly does seem like Gabe’s statement could be a nicer-sounding front for what Becky says; if there are fewer users than the math for supporting HL on Macs on an ongoing basis doesn’t make as much sense.
I recognize the point of your post is more about the lack of clarity and details around passkeys. That's real, and I don't really have an answer for that - other than, I think maybe the quest for making them simple and "just work" has maybe made them nebulous enough that we've wound up in the current situation where a lot of even technically savvy people don't really understand them. But I feel like answering your questions might sort of help explain why that's the case, so I'm going to take a stab at it:
> If I accidentally set up a passkey on my phone (let’s say I use Safari one day instead of my go-to, Brave), can I still log in without that passkey on other devices?
Assuming you have LastPass set up to be an iOS password manager, and it fully supports iOS' passkey implementation: when you create a passkey in Safari, it will ask you if you want to store it in LastPass or in the iOS Passwords app (previously known as iCloud Keychain). If you say LastPass, then it's up to them, but I assume it'll sync to all your devices - it's how 1Password works. If you were to accidentally say Apple Passwords, it'll sync to all your Apple devices automatically, and you can either use Apple's password browser extension on Windows, or you can use the "another device flow" I'm about to detail.
> Is there a way to ensure that passkey can be used on other devices?
As mentioned above, passkeys are intended to sync via your password manager of choice as the primary use case. If for any reason you don't have that passkey synced to that device, _and that passkey is on a mobile device with a camera_, most browsers will give you the option to scan a QR code with your phone. This kicks off a flow that will authenticate you via your phone's biometrics or passkey, then use Bluetooth to first ensure device proximity and then handle the authentication exchange. In the case of iOS, this includes any passkey-supporting password manager, so the passkey itself can be in 1Password; it doesn't have to be in the iOS password system for this to work.
When I first read the above, my hackles were raised given how well Bluetooth operates at times; but every time I've used it so far, it's been fast and flawless. Still, I can see a lot of scenarios where this might not work - e.g., the first one I thought of was a public computer at a library where Bluetooth might be locked down; corporate computers or remote servers could also be troublesome. As far as I know, passkeys don't yet have answers to those scenarios; other than to just use your password + 2FA as you would without a passkey.
As far as I know, both of the above apply to every passkey-consuming site.
> Can I add another passkey on another device? How many passkeys can I set up for a particular site/app?
This touches on your last paragraph, where it indeed could change based on the website. In my experience, every website where passkeys are fully supported - e.g., not ones that are using passkeys as a substitute for FIDO/U2F keys - has let me add multiple passkeys and have not _appeared_ to have a limit. I typically will create a passkey in both 1Password and Apple Passwords just to have a backup, and I can't recall any cases where that's been a problem. Still, I can't say for sure that isn't a problem on any website.
I went all in on trying passkeys when they started to be an option, and I don't have any notable regrets. For me, passkeys have generally worked well when the site is designed to use them well; and at no point have they been a _major_ hindrance. That isn't to say there are _no_ annoyances, though:
- Most websites that support passkeys tend to use them as a replacement for both the password _and_ 2FA, which makes them more convenient. However, a few - Amazon being the most notable I can recall - only use them as a second factor, which just makes them feel a little useless.
- A passkey can _also_ be used as the proof of identity, meaning you can log in in one fell swoop and don't need to enter a username or email address, which is IMO the best showcase for passkeys. Like above, this makes websites that ask you to enter an email address before letting you use a passkey also feel annoying.
- Most web browsers I've used support the QR + Bluetooth flow I mentioned above (otherwise known as Hybrid Transport or caBLE) without issue; Linux has been the odd duck out. Firefox doesn't seem to support it at all on Linux, and Chrome-based browsers do but sometimes are missing what they need and in that case don't show it as an option. Since I sync just about every passkey with 1Password this typically isn't a problem; the exception is the passkey for Apple Accounts, which Apple creates automatically, and (AFAIK) doesn't allow you to enroll your own. Apple Accounts are the only service I've found that does this, though.
- Some websites seem to only offer passkeys as an option if you're on a mobile device, or at least did so at the time of enrolling. eBay and PayPal I think are the two that jump out at me as having done this. Why they did it this way instead of simply detecting if the browser supported passkeys, I have no idea.
All of the above issues have gone down over time, so it's generally been a net decrease in friction over time. And, at least as far as I can recall, passwords themselves continue to be an option in every instance I've enrolled a passkey. So if you like your passwords, generally speaking, you can keep them :P
> passkeys are intended to sync via your password manager of choice as the primary use case.
The sync was actually a compromise to the standard. The idea was unique, device-bound credentials. One person, one device. The private key/passkey on your phone should not be the same one on your laptop, or your tablet, etc. Each device was supposed to have it' own unique credential.
Allowing sync is a security downgrade to the standard, in terms of threat-model guarantees. Pure WebAuthn credentials should be sealed in hardware (TPM or Secure Enclave or equivalent) and be mathematically non-exportable which guarantees zero remote blast radius, an attacker must physically posses the device.
Allowing sync and storing passkeys in a password manager reintroduces cloud account compromise risk and recovery flow hijacks. You lose non-repudiation.
Still more secure than passphrase + TOTP, but doesn't eliminate account takeover attacks against your cloud credential vault, which purely hardware based, per-device credentials do.
I don't get it. How does every device combo having a unique key pair help with security? They can all log in, right? So all you need is to compromise their session and you're in, whether they share the same passkey or not.
And if you're compromised in such a way that an attacker could steal your password then wouldn't they be able to just hijack your session instead?
Passkeys protect against credential theft, not session hijacking, two different parts of the stack. Passkey's only concern is initial authentication, it was never meant to provide any sort of protection against session theft. RFC 9449 Proof of Possession is how you prevent session hijacking, or session binding with a client-side TLS certificate.
Device-bound passkeys take care of non-repudiation. With synced keys (e.g., 1password), an account compromise of your vault hands the attacker all your credentials, the private keys are in the vault.
Device-bound keeps the private key sealed in the TPM (or secure enclave), the key cannot be exported, so it cannot be extracted remotely. Even malware on the machine, can hijack your session, but it cannot exfiltrate your private key, TPM won't release it to the service without user verification via biometrics, yubikey, or a PIN. There's also an attestation chain that breaks with synced passkeys. The attacker has no way to get your private key, so the only way to compromise the account is, yes, session hijacking, or physical access to the device with the user present to pass the biometrics check.
Ooh, thanks for the insight, I didn’t realize that - though that makes sense given how they work. My initial reaction is, I like the idea of the pure hardware-locked passkey as you describe it, but I feel like the syncing is a reasonable-ish nod towards making them more usable in the real world since it does let you have more flexibility.
I haven’t ever looked at the APIs for passkeys; is there any semblance of those types of keys being an option, or did opening the door to syncing basically let anything happen with the APIs and lose those guarantees?
> Still, I can see a lot of scenarios where this might not work - e.g., the first one I thought of was a public computer at a library where Bluetooth might be locked down; corporate computers or remote servers could also be troublesome.
None of my desktop computers support Bluetooth. Neither do my wife’s.
Yes, I mean, that’s also a possibility - or someone didn’t know they needed to screw on the antenna, or it’s otherwise borked. Every PC motherboard (sample size of four, three for me and one for a nephew) I’ve bought in the last five years has had on-board WiFi and Bluetooth though, so I’m curious to know, was that a deliberate choice?
(In thinking about it, it’s possible that the motherboards I bought did have non-wireless alternatives that weren’t stocked at my local Micro Center - lot of digging required to figure that out, though :) )
Wifi is becoming more common on desktop motherboards, but it's still not a guarantee, especially on the lower end. On the higher end they can throw in wifi to make the feature list bigger without cutting into their margins. Out of my sample size of 4 over the past 5 years, only two had wifi. And honestly, I'd opt out of having that if I could trade that for a lower price or some other feature I'm missing, since I haven't used the wifi on those boards at all.
I have a history of asking incredibly basic questions about the assumptions that are going in to a debugging issue for exactly these kinds of reasons. Something changed somewhere; so have we verified our basic assumptions that things are what we think they are... or did something change under our feet without our knowing? Or maybe we actually have a different understanding of the state of the world, and one of us is actually wrong?
It's not fruitful every time, but the number of times you skip asking those questions and chase something around, only to realize that, actually, it _was_ the ridiculous/simple thing... well, it feels a lot better to realize it earlier :)
(personal footnote: do be mindful of the context you're asking in! I feel like in general those sorts of questions are _fairly_ well tolerated by technical people. Sometimes you feel a bit stupid asking the question, but many of the systems I've worked on are large and complicated enough that it's not that weird - and if there's downtime and a healthy team, people genuinely want to hunt every possibility down. People not used to that, though, will sometimes bristle a bit, thinking you're implying that they're stupid and don't understand the basics. There can be ways to be more tactful, but at the very least, it's worth being aware of that reaction so you can follow up with a "just making sure I understand!" or something like that.)
Given they’ve had several skirmishes with customs and law enforcement agencies around the world, this always struck me as similar to the “don’t talk about installing retail Switch games on the Switch modding Discord” type of deal - everyone knows you can do that, but allowing mentions in official channels opens us to liability and causes nothing but headaches for both us and for customers, so if you’re going to do that, you need to talk about it somewhere else. I freely admit that’s an assumption on my part, though, and I don’t know if there’s something uglier there…?
Its one thing to have a skid come in going "I wanna hack the RFID on the gubbmints's doors how can i do that?"
Versus "we forked the firmware to include a wide range of pentesting tools"
And then get banned for even saying the alternate firmware.
And seriously, this little thing is a wonderful hacker multitool. You can seriously fuck shit up with the hardware they included. For fucks sake, thats WHY they created it.
That's how you have to be on Discord, or else your guild gets banned from Discord. I wish we weren't using this crap. On IRC, sometimes you had to deal with cranky netops, but they mostly left you alone.
Absolutely nothing you said refutes anything in the comment you’re replying to. You are just reiterating “I’m angry and this is stupid”. Go write in your journal or something. It’s impossible to engage with someone who isn’t engaging themselves.
IRC is still alive and there is bunch of communities around that are a bit more lax, probably because they're half-dead compared to what they used to be. Today probabably Libera.chat would be the best introduction if you haven't touched IRC before.
To be clear, while there is _specific_ language around DEI/gender identity, the actual language of parts of this goes far, far further, and essentially codifies giving political appointees explicit discretion over what gets funded and what conferences scientists with government funds can go to, and disallows any government money to go towards publishing research.
I agree there are serious concerns and drawbacks with giving appointees discretion. But the reason they did this is likely that agencies otherwise have a way of basically doing their own thing, and not complying with language. One example that isn’t about DEI. is Fauci working around restrictions on gain of function research, following the ban Obama put into place. You can have language around DEI or gender identity (or some issue on the other side) but people can find ways around it.
> and essentially codifies giving political appointees explicit discretion over what gets funded
I approve of this. The people who make the funding decisions should be politically accountable. If you have a mental model of unappointed civil servants as detached, neutral, non-political entities, I can understand why you wouldn't. But I see them as just people, and I don't know anybody like that. I'd like the folks who make bad choices with tax dollars to be votable out of office along with their boss, rather than protected from accountability by layers of boards, laws and unions.
When they released the Macintosh to the world, Andy Hertzfeld realized that people were renaming items in the Finder by accident; so he added the "return" key (already used to confirm actions) as an "arming" step[1].
Now, one might ask: wouldn't that interrupt people navigating via the keyboard? No, because the original Macintosh didn't have arrow keys on the keyboard. This was an intentional choice—or, perhaps, mandate from Jobs—as a way to get users to use the mouse as their primary input device, and to force developers to create mouse-driven interfaces. With no arrow keys, no typeahead search implemented, and a clean slate for designing an interface, I'm guessing using Return to open a file wasn't a strong consideration at the time.
Why wasn't it changed? Because Mac OS X was made for Mac users, and we all have muscle memory dating back decades :P
[1]: https://www.folklore.org/A_Floppy_named_lsadkfjalhkjh.html