Live data from Hacker News

Face ID and Touch ID for the Web

webkit.org

221–230 of 371 posts

Re: Face ID and Touch ID for the Web

#221

Earlier quoted context omitted.

What's stopping you from linking more than just one physical FIDO-enabled device to a particular site/service? Most MFA implementations I've seen already allow this, and it seems especially important if you want to minimize the pain of losing/damaging that one sacred card.

I don't carry any keys so those massive dongles would be pain. Plus must is not ALL which breaks everything.

Mobile phones can be FIDO enabled. (see https://developers.google.com/identity/fido/android/native-a... )

Re: Face ID and Touch ID for the Web

#222
post #33
post #13

So 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.)

Note that Epic claimed that "Sign in with Apple" was going to get terminated, but Apple says that wasn't true:

https://www.theverge.com/2020/9/10/21431396/epic-sign-in-wit...

And IIRC it all still works anyway, so this sounds like Epic either being confused about itself or lying to make Apple look like the bad guy (more).

And bear in mind that anyone using any third-party auth (like Twitter, Facebook or Google OAuth) could have their developer accounts terminated for violating the rules, same as Apple. I guess the key takeaway here is "if you're relying on someone else's services, don't flagrantly disregard the service's rules publicly in order to start a lawsuit and then try the case in the court of public opinion", but I think that's good advice for any service.

Re: Face ID and Touch ID for the Web

#223

Earlier quoted context omitted.

Your face can easily be mimicked. Biometric data is not stored in the phone, it is stored in you. See: https://www.macrumors.com/2018/12/16/3d-printed-head-android...

> The final model took a few days to generate at the cost of just over £300. "easily"

£300 is chump change in most any organization's budget.

Re: Face ID and Touch ID for the Web

#224

Earlier quoted context omitted.

> You could say that about anything -- nothing is completely static 1. Contracts are a thing. You can draft a contract with your vendor that guarantees certain terms for a certain duration. 2. You should be wary of wandering into commitments (including de facto commitments e.g. "vendor lock-in")--there are plenty of good reasons to do so, but one should make sure to properly consider the cost. The problem is that doi…

It is more of an monopsony[1] than a monopoly. If you are looking to buy a smartphone there are still options. If you are looking to sell software for smart phones, Apple is by far the most lucrative platform and they have a lock on publishing software for iOS. It is very difficult in the US to survive as a software developer for Android only. The anti-trust frameworks in the US are based largely on monopolies and th…

Apple sits between users and developers. If it's a monopsony on one side, it's a monopoly on the other side.

Re: Face ID and Touch ID for the Web

#225

Any bullying or power abuse situation may easily exploit biometric authentication against the victim. Kids bullying other kids, domestic abuse, authorities etc. Now, if biometric authentication becomes the norm, how will a wife suffering domestic abuse justify using a password?

I agree with you, but am not sure a password works too well in such situations either - the abuser would presumably just beat the victim until they enter their password?

Yes, I don’t see it helping in situations where the attacker has a long term relationship with victim.

https://xkcd.com/538/

However, I think touchID is susceptible to being robbed since if you have your bank account or Apple Pay enabled to transfer cash with touchID as authentication, then you can be robbed while you’re passed out drunk or roofied or whatever.

Re: Face ID and Touch ID for the Web

#226
post #208

Earlier quoted context omitted.

It isn’t productive to establish defense against an arbitrary future that turns on you. Spend those brain cycles focusing on your user and building a great product. Choosing Sign in with Apple is great for Apple users.

> It isn’t productive to establish defense against an arbitrary future that turns on you. It isn't? Isn't that like, the hallmark of intelligence?

Against an arbitrary future? No. Against a likely future? Yes.

It is not the hallmark of intelligence to come up with every possible thing that could go wrong and build defenses against it just in case someone somewhere does something counter to their wellbeing.

If you use any third-party login system, think about how you can migrate users between accounts, or validate that they are who they say they are, that's perfectly normal. What if Twitter OAuth goes down? What if your Google dev account is suspended by some automated system for some reason? You should definitely have some kind of plan for that.

Spinning off contingencies in case Apple changes its developer policies out from under you and suddenly no one on iOS can log in? Too specific and arbitrary.

Re: Face ID and Touch ID for the Web

#227
post #99
post #71

Earlier quoted context omitted.

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.

Users can just tell the vendor what their real email address is when they want support, until Apple bans vendors who ask for contact info.

Re: Face ID and Touch ID for the Web

#228
post #60
post #50

Earlier 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.

I think "Sign in with Apple" is unique that Apple allows the users to hide their email address https://support.apple.com/en-us/HT210425 which makes it extremely hard to migrate away, unlike other federated login system where you can at least get users' email addresses, allowing you to create a proper email+password login later on.

How is that? It's the developer's choice of they want to let me add a second login to the same account.

Re: Face ID and Touch ID for the Web

#229
post #137

Earlier quoted context omitted.

> Since I have zero need to deliberately violate Apple's App Story policy, I don't worry about this overmuch. That may be true today, but their policies are a moving target. Who knows what they'll be like in a year's time?

> That may be true today, but their policies are a moving target. Who knows what they'll be like in a year's time? Likewise Google, Facebook, or any site/ API that a developer deals with on a daily basis. I wouldn’t bet my company on any sign in with _____ service. I just feel the trade-offs with Apple’s sign in versus Google/ Facebook to be less bad. With any of the services, I might do something that causes me issu…

This is why (as a customer) I always prefer "yet another web account" vs. "sign-in with ____" - yes, it's a hassle to manage a different account for every different thing I use (although not much of one with a decent password manager), but I get the advantage of not risking losing access to _everything_ because .

Single-sign-on means single point of failure.

Re: Face ID and Touch ID for the Web

#230
post #50

Earlier 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.

This is always a business decision, imo. It's similar to publishing on medium (or Huffpost, from a few years ago) as opposed to your blog. You'll get more reach in the former case, but have much less control. For that matter, it's similar to serverless vs code everything and host it in a server on a rack somewhere. Engineering is all about the tradeoffs. So, how would I make that call? I'd think about how much it mat…

It's extremely cheap to syndicate to Medium plus other venues. Not so for Sign In With.
Post reply on HN