That is not Apple’s stated design at all. If you read Apple’s passkeys security document, it claims that the private keys are synchronized with iCloud and are recoverable following the loss of all devices. Non-exportable passkeys using the TPM is an HN myth.
> When you point this out to advocates, you'll get an entirely different argument
This is a very common argumentation tactic, and it usually exposes that the first argument(s) are just a front for our actual axiomatic belief (which hasn't been disclosed). The core principle is often something that we know is much more controversial.
sudoedit and visudo are mandatory on a host machine given the tendency for sudoers parse failures. Defaults env_keep = "" ? Oops, I guess sudo no longer works.
That would be a great improvement for technical users. But also consider that the target for Authy is the average mobile user. I’m not unconvinced that the typical backup password looks like S3cr3tP@s$w0rd, which no amount of key stretching will fix.
Yes. Depending on the threat model, it may or may not be better. Many organizations won't be allowing remote passkey sign-in for employees. For people at home, the elimination of passwords will reduce rates of phishing and credential-stuffing attacks.
Sorry, that's only speculation, since I haven't had more time to analyze the database. If you read Apple's passkey security document, it claims that passkeys are distributed identically across devices. And that you can recover the passkeys even in the event that all associated devices are lost. It's also possible to share passkeys at any time.
passkeys.com:
> When a user sets up a passkey, a key is generated and synchronized to the cloud. When the user connects from another device in the same ecosystem, it will use the same key.
WebAuthn supports verified attestations for hardware-backed authenticators. Passkeys seem to be designed for normal consumers, who worry about losing authenticator devices.
Basically: For some subset of iCloud Keychain users, SMS is used in combination with the lost device's passcode (or a user-chosen password) to recover the keychain. Since the device is lost, you re-issue the phone number with a carrier. I think 2FA or ADP may require another device or a recovery key, but my memory is hazy on this.
Passkey objects on macOS are encrypted at rest within the iCloud Keychain sqlite database in Library/Keychains/*/. It shouldn't be too hard to adapt the keychain extraction tools that exist.
I don't know why you would want to though. Since (1) passkeys will rarely be a required nonreissuable credential, and (2) losing access to iCloud Keychain is extremely improbable. For many users, showing ID to a phone store clerk is sufficient for iCloud recovery. For others, it's using their laptop, a recovery key, or a recovery contact.
You authenticate to a cloud escrow provider using any of your account's other associated devices. If you have none, because Yellowstone erupted while you were away, and someone also yoinked your phone in the ensuing chaos, then you input either (A) your device's passcode and an SMS code, or (B) a recovery key. If you have neither, then you use an established recovery contact. If those steps didn't work, then it's not too late to visit Wyoming.
Cryptocurrencies are a spectacularly bad counterexample. If password-derived private keys had ever become commonplace, the ensuing theft would have absolutely dwarfed the losses from lost wallet keys. I'm not sure if there's even a comparable instance of successful widespread public-key cryptography adoption.
I suspect the vast majority of Authy backups use passwords trivially susceptible to brute-force attacks despite only 1000 (!!!) iterations of PBKDF2. If Authy wanted to do things right, it would generate local encryption keys instead of asking normies for file encryption passphrases.
How does this unknown Delaware company support 12 employees working on a free mobile app? There's zero verifiable information available about its history, and the founder seems to be heavily involved in cryptocurrency.
For one thing, it's common for enthusiasts to replace stock components. A serial number stamped onto the frame isn't useful all the time, especially if the frame itself is secondhand. If someone takes your >$2,000 carbon wheelset then you're SOL, likely no matter what.
Huh, thanks, I wrongly assumed that Passkeys inherited WebAuthn’s attestations for hardware-backed keys. I guess organizations will need to ban Passkeys internally.
Yes. When TOTP debuted, it was aimed at and designed by security engineers. Keeping secrets on-device was and is correct for serious uses.
Google Authenticator is a victim of its own popularity. Fortunately, the field moved on, and we now have WebAuthn and Passkeys for non-exportable private authentication keys.
Authy used to share its SDK TOTP codes with attackers via account recovery, and no backup password was needed. SMS hijacking led to authenticator takeover on Authy SDK-using sites like Coinbase. Which is partly why Authenticator and co. were originally designed to prohibit secret backup.
Things open source developers say because they don’t have experience with binary analysis. Not to say that Apple’s reviewers are going to be looking at IDA or Ghidra dumps, but they can see added capabilities, frameworks, symbols, or assembly and call graph changes.
Not that it matters, because they don’t have the time to manually review source code changes either. At best there’s likely some automated static analysis for undocumented API symbols and common malware signatures.
That is Apple's statement, but I'd be surprised if 50% of iOS/macOS users noticed any significant change with lockdown mode on. Unless you are using shared albums or answering unknown facetime calls, there isn't much impact. JIT, WebAssembly, etc. can be re-enabled per site.
When I first looked into this, free Apple developer accounts also could only use limited app entitlements: so no network extensions, VPN profiles, Apple push notifications, or other capabilities. NetworkExtension is basically the only reason I’m interested in iOS development at all, so a paid account was not optional.
I admit I’m completely out of my depth when it comes to this field — I don’t even typically care about AI — but Eliezer’s response looks really bad to anyone in research. Asking for a citable and thorough written argument is as basic a requirement as it gets.
To repudiate that request with “everyone has a different objection” is nearly unthinkable. And to David Chalmers no less!
I think podcast hosts, tweet authors, bloggers and live streamers sometimes forget that progress in academic fields comes from real contributions, and that public conversations (especially oral) don’t really do anything besides spread common awareness.
I assume my private messages are always public record, so I don’t get this mindset. My first thought when messaging someone is, “What if they screenshot or leak this conversation?” or “What if their message history is subpoenaed?” It never makes sense to assume confidentiality with other coworkers.
macOS already does all of that for all programs. I think the main problem here is that macOS only protects certain directories and not others. Programs can request access to Documents or Downloads, or they can request full-disk access (e.g. to read Library/Messages).
For unprotected directories like Library/Keychains, programs can just copy the encrypted database. Since the malware obtains the keychain password with a fake password prompt, it can decrypt the database.
Custom keychains are also available if you worry about malware dumping unlocked keychain data via kernel privilege escalation (to bypass ACLs). For critical items that you decrypt once a year, it doesn't make much sense to use the resident login and iCloud keychains.
ACLs shouldn't be overlooked though: manual keychain items use the default ACL configuration and require user confirmation, which means you need to authenticate N times to access N items.
GitLab initially copied GitHub’s UI, virtually identically, and the CEO advertised GitLab in every thread that involved GH for over a year. It didn’t seem that many people on HN cared, because GitLab was “open source” and ethics didn’t apply.
> So, Mono is alive and well inside every version of .NET since 5.
The official mono project is no longer under active development since the acquisition of Xamarin and the reassignment of core Mono team members to .NET Core.
Microsoft’s zombification of Mono by lifting code into .NET doesn’t suddenly make it alive. We’re not going to someday get a .NET 8 reimplementation inside Mono.
> .NET Core ( dotnet at the CLI ) has replaced .NET Framework and ( by implication ) has replaced Mono as well. That is what I think the post above is trying to say.
dotnet build (from the modern .NET CLI) can compile .NET SDK projects that target legacy Framework versions. A csproj with a .NET.Sdk reference can use a TargetFramework of net48 or lower.
dotnet build times are an order of magnitude faster than Mono’s msbuild command, and migrated projects also receive the recent dotnet toolchain improvements (like automatic nuget restore, among many others).
Unity projects sometimes use dotnet's csc, even when the compiled libraries are executed with the Mono .NET (Framework!) 4.x runtime.
Sorry! I shouldn't have assumed that it was a retort. Mono's latest supported .NET framework (v4.8) is four years old, or even older if you include the general movement to .NET Core, and it only supports C# versions <= 9.0 (via Roslyn), also 2-3 years old.
msbuild, the toolchain still used by Mono, has also been widely replaced by dotnet (CLI).
It's still (decreasingly) common to use Mono for cross-platform development, especially for Unity, which hasn't yet transitioned to .NET >= 7.0.
Yes, and this is tantamount to suggesting that Python developers should be satisfied with Python 2.0 (arguably 1.0 if you do F# development). Mono is effectively dead and abandoned, and it only exists now for historical reasons.
If anyone thinks this, I sincerely hope you re-evaluate. The difference between doing sports and exercise and doing none is often being disabled or in pain in your 30s and 40s, versus being in near peak physical shape. I meet too many people who assume that debilitation comes with being aged 38-50.