Live data from Hacker News

Why we won’t be supporting Sign in with Apple

blog.anylist.com

191–200 of 485 posts

Re: Why we won’t be supporting Sign in with Apple

#191
The larger problem is trying to get the average Facebook and Instagram user to care about security (if they cared about those things they wouldn’t be on a Facebook product but I digress).

I applaud Apple’s intentions but as this article proves, if the user isn’t driving the push to be more private then initiatives like Sign In With Apple cause little more than support headaches.

Re: Why we won’t be supporting Sign in with Apple

#192

As they point out at the very bottom, all their arguments apply to all third-party sign-ons, so they're removing Facebook as well. So there's nothing specifically against Apple, despite the title seeming to imply it -- just that they're taking the move right now because of Apple's new policy coming into effect. I've got to say, I really wish there were a way to know whether I already used Facebook, Google, or Apple t…

I cope with this confusion by avoiding third-party login whenever possible. Why volunteer additional information about myself to Google or Facebook?

Because you can frequently avoid account creation, setting a new password etc if you click “sign in with google.” It’s a tradeoff but if you don’t see any value in it you maybe haven’t used it- it’s convenient.

Re: Why we won’t be supporting Sign in with Apple

#193

Earlier quoted context omitted.

It seems sufficient to me? https://developer.apple.com/documentation/sign_in_with_apple...

Absolutely not. Compare the native ios documentation[1] with their "other platforms" documentation[2]. Their native documentation has code snippets, helpful links, and explains in depth what is happening. The "other platforms" documentation is "make this request, store some data, follow redirects". No code, no helpful links on how you might accomplish these things, nothing. You get the bare minimum. I'm not saying it…

The nature of "other" platforms means that example code could be in any language at all.

The fact that their iOS documentation is so much better than average doesn't mean their "other platforms" documentation is inadequate. It just means there's plenty of room for third parties like indie bloggers to documentation their own approaches in JavaScript, Python, Ruby, Rust, or whatever.

Re: Why we won’t be supporting Sign in with Apple

#194

As they point out at the very bottom, all their arguments apply to all third-party sign-ons, so they're removing Facebook as well. So there's nothing specifically against Apple, despite the title seeming to imply it -- just that they're taking the move right now because of Apple's new policy coming into effect. I've got to say, I really wish there were a way to know whether I already used Facebook, Google, or Apple t…

"all their arguments apply to all third-party sign-ons"

No they don't. Other sign-on options don't obfuscate the email address.

They are likely removing FB login as otherwise their next app update will be rejected by Apple for supporting third party login but not Apple login.

Re: Why we won’t be supporting Sign in with Apple

#195

As they point out at the very bottom, all their arguments apply to all third-party sign-ons, so they're removing Facebook as well. So there's nothing specifically against Apple, despite the title seeming to imply it -- just that they're taking the move right now because of Apple's new policy coming into effect. I've got to say, I really wish there were a way to know whether I already used Facebook, Google, or Apple t…

> I've got to say, I really wish there were a way to know whether I already used Facebook, Google, or Apple to log into a site or app before.

Bookwalker (from Japan) draws a big red box around the login you used last on a given device. Presumably they store a cookie/sharedpreferences with it. It doesn't look pretty, but it helps.

Re: Why we won’t be supporting Sign in with Apple

#196

As they point out at the very bottom, all their arguments apply to all third-party sign-ons, so they're removing Facebook as well. So there's nothing specifically against Apple, despite the title seeming to imply it -- just that they're taking the move right now because of Apple's new policy coming into effect. I've got to say, I really wish there were a way to know whether I already used Facebook, Google, or Apple t…

>My password manager is usually pretty good at letting me know if I've got a "normal" account with user/password, but it doesn't do anything to remind me if I ought to log in with one of the other services.

Doesn't it somewhat defeat the purpose of using a password manager if you use one account to sign into multiple sites?

Sign on services from main accounts seem like security flaws. If you use one main account resonsible for all your 'main things' to sign in to all the 'other things' that gives one vector of attack to enter or compromise 'all the things'.

Password managers exist to make the management of many things as easy as one thing, not to adapt to using one thing for everything, that's pretty much the opposite of what a password manager does.

Sign on services don't exist for convenience, despite being marketed that way, they exist to increase data collection abilities. Password managers exist to make using multiple accounts as easy as using a sign on service, that's the point. They should be separate from existing providers. They are an alternative to them.

Re: Why we won’t be supporting Sign in with Apple

#197

This seems to be a common problem, made more visible when using third-party authentication, that your application has taken the concepts of "Account" and "Authentication Method" as if they were the same thing. It appears that the "account ID", "preferred contact method+address" and "authentication ID" are all the same here - which then creates the "account management code into a rat’s nest" scenario they describe in…

I think the problem is that many apps, use the same form for login/signup. So a user thinks they're logging in, but they're actually creating a new account with a new authentication method...

Re: Why we won’t be supporting Sign in with Apple

#199

Another issue with Sign in with Apple is the fact that their private relay has a pre-set allow-list per app for sending email to relay addresses. This means that you must either prove ownership of domains, or pre-add email addresses to Apple's systems. I understand why they have done this, it will reduce spam considerably, but the private relay system is already designed to empower users to do this and this extra ste…

That's a good point, but I'd be surprised if Apple doesn't have (or is building) a mechanism to allow certain well-known domains to be trusted sender, in the circumstances you note. Like, have "enter your custom domain", but also "checkboxes for fedex.com, etc".

Re: Why we won’t be supporting Sign in with Apple

#200

As they point out at the very bottom, all their arguments apply to all third-party sign-ons, so they're removing Facebook as well. So there's nothing specifically against Apple, despite the title seeming to imply it -- just that they're taking the move right now because of Apple's new policy coming into effect. I've got to say, I really wish there were a way to know whether I already used Facebook, Google, or Apple t…

>My password manager is usually pretty good at letting me know if I've got a "normal" account with user/password, but it doesn't do anything to remind me if I ought to log in with one of the other services. Doesn't it somewhat defeat the purpose of using a password manager if you use one account to sign into multiple sites? Sign on services from main accounts seem like security flaws. If you use one main account reso…

> Doesn't it somewhat defeat the purpose of using a password manager if you use one account to sign into multiple sites?

Yes. Password managers exist to solve the problem of credential reuse; third-party login exists to implement credential reuse. They are fundamentally opposed.

Post reply on HN