It'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 will have to nag the user to touch the screen again. This already affects APIs like clipboard (want to copy something that takes async work to generate? tough luck), limits APIs like OffscreenCanvas (want to move your game engine to a worker? tough luck, you lose access to all user gestures), and this too. Hopefully Apple can consider aligning with Chrome on this.
Face ID and Touch ID for the Web
91–100 of 371 posts
Re: Face ID and Touch ID for the Web
#92I would never use this for anything sensitive. Bad actors can get your face and your fingerprint. Some of them already have it (governments, banks, Apple, Facebook, etc). And changing your face or fingerprint is practically impossible.
Apple has my face and fingerprint? I haven't heard this before and Google turns up nothing. Any source?
You put your fingerprint into a black box and that black box phones home to Apple servers. From a security standpoint, we must assume that they have your fingerprint unless there's a way to prove that they don't. iOS is closed source so we can't prove that.
From an epistemological point of view: I don't know if they have it.
From a security point of view: they have your fingerprint.
Re: Face ID and Touch ID for the Web
#93These 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.
Authentication and authorization If the machine can prove that you are indeed you through biometric authentication, why take another step for authorization?
This only makes sense if you have multiple personality disorder. if there are many alters that shares one body, after successful biometric authentication, the machine might need to request password for authorization to prevent unsolicited access from another alter in one body.
Re: Face ID and Touch ID for the Web
#94Cmon apple, just add NFC to macbooks already. Fido cards are the most obvious solution to this.
Re: Face ID and Touch ID for the Web
#95Earlier quoted context omitted.
> I would definitely stay away from any "Sign in with Apple". I would stay away from any "Sign in with.." service as a user and as a product owner. You're affectively giving away a major control of your users to a third party.
As a product owner, why wouldn't I want to piggyback on the millions of dollars of R&D + security that the big companies have put in? And as a user, why would I trust my password to the website that rolled their own authentication over the big companies?
> why would I trust my password...
Do you use the same password everywhere, by any chance? :)
Re: Face ID and Touch ID for the Web
#96I'm curious about "Apple Anonymous Attestation". Is Apple taking on any liability by providing this service or is this all done on hardware through private APIs?
When this was pre-announced awhile back I highlighted the lack of anonymity, due to the Apple secure element (T2 on laptop/desktop; whatever the name is on mobile) lacking attestation capability. That comment was downvoted by folks that presumably don't understand the problem at hand. In that pre-announce video Apple dared to insinuate that attestation by current devices is de-anonymizing, when that isn't universally…
> In that pre-announce video Apple dared to insinuate that attestation by current devices is de-anonymizing, when that isn't universally the case.
Most hardware devices use batch attestation, where some group of (say, 100 000) keys all get the same private key. This does still provide some data for correlating users based on make + model + batch of their authenticators.
ECDAA was meant to be an approach to solve this with pairing-friendly curves and crypto, but the industry stayed clear of this as an unproven algorithm.
Apple (and the rather similar SafetyNet approach by Google) use a service. The interaction between the device and this service is black-box and we do not yet know how much information is exchanged. By its nature, this service can change in the future and we will not know.
However, it _could_ be limited to an RSA or EC-based DAA attestation from the Secure Enclave, a curve point on P-256, and a SHA-256 hash value to embed. There's no reason Apple needs to know either the specific piece of hardware or the site a user is going to.
> Further, it's up to the site to decide whether to use an anonymous attestation or not. The user will not be informed either way.
Several browsers will give the user the option to not send attestation if a site asks for it, to the point where capturing attestations is a UX-impacting action. You could say the UX impact is intentional - not only do basic attestations leak some tracking information, but they limit user choice in how to authenticate.
Re: Face ID and Touch ID for the Web
#97You 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?
As far as Apple devices are concerned, biometric data never leaves the Secure Enclave, so risk of data leak is non-zero, but sufficiently low for everyday life. Compare that to the massive number of people who use password123 as their password for every account across the web, and yes, biometrics are far more secure. :) More secure than a random 30 character string? Probably not.
And if you’re targeted by individuals who are sufficiently motivated to steal your biometrics and the physical device, then neither the password nor the biometrics will be enough to protect you.
Re: Face ID and Touch ID for the Web
#98How does this work on laptop/desktop computers?
Most (all?) new apple laptops have touchid, but I agree this seems most useful on iPhone/Pad which kind of makes sense as the majority of 2fa keys (yubi, etc) still plug in.
That would surely be more awkward than using the already built in SEP and authentication system.
Re: Face ID and Touch ID for the Web
#99Earlier quoted context omitted.
> I would definitely stay away from any "Sign in with Apple". I would stay away from any "Sign in with.." service as a user and as a product owner. You're affectively giving away a major control of your users to a third party.
As a product owner, why wouldn't I want to piggyback on the millions of dollars of R&D + security that the big companies have put in? And as a user, why would I trust my password to the website that rolled their own authentication over the big companies?
this is a MASSIVE selling point, BUT, when your users contact support trying to gain access to their account and can't describe what their email address might be... trust me, there is pain in your future.
Re: Face ID and Touch ID for the Web
#100Earlier quoted context omitted.
> I would definitely stay away from any "Sign in with Apple". I would stay away from any "Sign in with.." service as a user and as a product owner. You're affectively giving away a major control of your users to a third party.
As a product owner, why wouldn't I want to piggyback on the millions of dollars of R&D + security that the big companies have put in? And as a user, why would I trust my password to the website that rolled their own authentication over the big companies?
As a product owner, because what if that service provider decides to (mis-?)interpret something you did as against their TOS and revoke your access to their sdk, thereby making it more difficult for many of your users to log in?
And as a user, what if Facebook/Google/Twitter/Apple decides you've violated their ToS, blocks you from your account, and now you can no longer log into any of the sites you've linked with one of those providers?
I know this is a bit extreme, and for many people, the risk is totally worth the reward, but I think that is one of the chief concerns many people have with trusting a third party for all their sign-ins. It's a single point of failure.