The obvious difference is that you have to create that other user (as opposed to denying the ~/Documents request). Also when you curl|bash you normally want to install under current user -- not something you're supposed to do on Linux.
I don't actually believe that macOS protects me here, as I granted this permission to the terminal five years ago...
I thought the point of storing secrets in hardware TPM and not giving them out into userspace (i.e. passkeys instead of passwords) is protecting against malware as well.
And they claim that for Chrome on Windows:
> Unlike a legitimate user flow that requires user interaction and device unlock, this attack shows how malware can obtain the required signature silently, without user consent, biometrics, device unlock or elevated privileges.
The reason why the attack works without “biometrics or device unlock” is because it only works on passkeys that were issued without requiring user verification:
> The Pass-ta-key attack is effective when the relying party does not strictly require user verification. Many relying parties configure WebAuthn’s userVerification parameter as preferred rather than required to support diverse devices and user experiences, making them susceptible to this attack.
So it’s possible for a relying party to mitigate this attack by requiring user verification and checking that the proper bit was set.
Later on, the article outlines an issue with the way that Chrome interacts with Windows Hello during passkey registration and another issue where Chrome dumps the TPM’s master key in process memory, but these are endpoint concerns and have since been patched
While you are technically correct, I know for sure that an RP might be unaware that not requiring user verification means Chrome is free to let malware steal the passkey... (Our Keycloak is (mis)configured like that.)
Do you happen to know if this is because Google had to implement sync in userspace, or is it an inherent limitation that could also affect Apple?
>I thought the point of storing secrets in hardware TPM and not giving them out into userspace (i.e. passkeys instead of passwords) is protecting against malware as well.
This was never a design goal of passkeys as far as I'm aware, and normally passkeys are not generated or stored in a TPM. The primary design goal of passkeys was to make a phishing-resistant primary factor that could compete with the user experience and convenience of passwords, so that folks would actually be interested in using them.
I think you are thinking of security keys, which generate key material in e.g. a YubiKey which offer similar protections to a TPM.
YubiKeys can also be used to generate/store passkeys, but when they are used for passkeys typically they'd be referred to as "device-bound passkeys" rather than just "passkeys".
Sure, not giving out the secrets to userspace was the design goal of security keys and later TPM+Secure enclave. Passkeys happen to enable the use of such hardware for authentication on the web.
I thought it was maybe a case of convenience trumping security, as by definition you can't sync device-bound passkeys. But it's not clear why synced passkeys must be available for malware to steal (especially without user interaction).
I'm not sure now if the Apple's implementation has similar flaws with stealer malware on macOS: you don't see passkeys explicitly mentioned in mac stealer reports, but I couldn't quickly find a confirmation they are safe either...
I was curious what non-fatal condition would make the parents so desperate (to participate in a first-in-human trial):
> Mei was diagnosed with global developmental delay .. some of Mei’s behaviors .. were associated with autism.
> CHD3 mutations produce a condition called Snijders Blok-Campeau syndrome
> people with the mutation often have a normal life expectancy, but their symptoms vary widely. Most have slightly larger than normal heads, and about two-thirds have intellectual deficits. Moderate to severe cases may be nonverbal, suffer from seizures and heart problems, and have fluid-filled voids in their heads.
The maintainer works on mlx-vlm so he does have pedigree in the scene, I'm don't know if this is just going to end up as unmaintained slop. I haven't tried this but I would personally just recommend oMLX for a currently more complete and fleshed out package - loads of features, provides the same MLX support and changelogs + commits are actually detailed.
I use oMLX and I'm tentatively going to be giving this a shot. oMLX keeps driving me up a wall with odd papercuts, bugs, and silent failures and fallbacks that are only visible buried deep inside logs when they should be announced out loud.
The maintainer of mlx-vlm being behind this as well is the main thing kicking me over into trying it, even if it is incredibly young. I'm confused and unenthused to see it chomping on a whole GB of disk, but the Swift makes it feel much more refined even if it's not yet as feature rich. It automatically picked up the existing models I was using with mlx_vm directly, which was nifty.
I thought this was a long solved problem: the server syncs encrypted data, and the user provides the decryption key from another device (via QR codes, BLE, …)
Don't let the hype turn you into a cynic. You're replying to a Rust core team member, who explicitly says the issues are mostly minor, across Rust ecosystem and not in Rust itself, and that they're filing them manually to avoid dumping unreviewed AI output on people.
https://software.codidact.com/ was created after one of the many SO dramas. It doesn't come up in searches though and I didn't have reason to use it...
reply