Face ID and Touch ID for the Web
341–350 of 371 posts
Re: Face ID and Touch ID for the Web
#342Honest question, Why I feel I have to be an advanced programmer to understand all of that? I see a lot of confusion in the comments, so it is not just me. Why the article couldn't be simpler? Maybe I am just stupid, I don't know.
I love technical content that does not shy away from from going in depth
Re: Face ID and Touch ID for the Web
#343Earlier quoted context omitted.
It would be helpful if you could let us know how you managed to send that e-mail.
You can see the email that Apple generates: https://support.apple.com/en-us/HT210426
You subscribe with `private-XXXX@apple-id.com` which relays to `foo@gmail.com`. Customer support asks you to chat with them from the same ID you signed up. Your e-mail client sends email from `foo@gmail.com`. How can you quickly respond to the customer support from `private-XXXX@apple-id.com`?
Re: Face ID and Touch ID for the Web
#344It's a shame they have a messy pile of API-specific hacks to propagate the "user gesture". Chrome solved this problem with a change to the spec (which they called "User activation v2" [1]). It's basically two flags and a short timeout, and it covers basically all cases. Safari's approach means you have very specific codepaths, and if you do something async outside of that, tough luck, you can't use the feature and wi…
If Safari had changed the spec that comment would probably have begun with "It's a shame they had to change the spec..."
> Safari's approach means you have very specific codepaths, and if you do something async...tough luck
I'm no expert on it but this sounds more secure, no?
> APIs like clipboard (want to copy something
On a side note, I really wish non-explicit copy/pasting/clipboard snooping would die.
iOS 14 has exposed a bunch of apps that read your clipboard without any explicit paste action. It's creepy and we can only hope that it's not malicious. A bunch of big names including Discord are guilty of this.
Re: Face ID and Touch ID for the Web
#345Re: Face ID and Touch ID for the Web
#346You can change a password but you can't change your fingerprint / palm / etc. Am I missing something? How is Face / Touch ID more secure that user + pass? What happens when biometric data is leaked?
Re: Face ID and Touch ID for the Web
#347Re: Face ID and Touch ID for the Web
#348So happy Apple decided to go with an open standard here rather than something proprietary. This is good news for the FIDO2 ecosystem and I hope this leads to far greater support for FIDO2 authenticators of all types. There is another world in which Apple just pushed 'Sign in with Apple' and created yet another federated identity provider rather than true, 'secure element'-based FIDO2 authentication.
"Sign in with Apple" requires a developer account with Apple. Having saw Epic's developer account terminated by Apple, I would definitely stay away from any "Sign in with Apple". (FWIW, the only 2fa with "Sign in with Apple", if you don't own any Apple hardware, is SMS.)
Re: Face ID and Touch ID for the Web
#349Earlier quoted context omitted.
Please please please be true. TouchID is objectively superior to FaceId, by a long shot. It is my soap box... but TouchID RARELY failed and could be activated BEFORE you had the phone in front of you. FaceID fails constantly and MUST be in view to start the unlock process. TouchID has a single failure mode (and a half) that isn't that common. Wet / dampness. Solution, dry your finger, try again. Gloves are the 'half'…
TouchID has another interesting failure mode for me that's probably quite rare: after I go climbing, my skin is so worn that it doesn't recognize any of my fingerprints.
These are definitely failure modes, but I would put them in the niche bucket.
Re: Face ID and Touch ID for the Web
#350These all seem to be examples that use faceID/touchID as a password. That’s not what biometrics should be though, they should be the username. I hope that this is supported as a flow as well. Identify who you are with biometrics, and prove your access with a correlated password.
What you’re describing is essentially using a fingerprint instead of a private key or password for logging into a server via ssh.
The way this works is more akin to using a private key to login via SSH, but that private key is protected by a fingerprint instead of a password.
Ultimately the security comes from not sharing your private key, rather than the mechanism used to protect that key.