Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why we won’t be supporting Sign in with Apple

blog.anylist.com

Post reply on HN
Print view View original

371–380 of 485 posts

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

#371

Post by draven »

lstamour wrote: post #148
tech-historian wrote: post #120

Earlier quoted context omitted.

Sure, except there is no documentation for it. From the article: "For example, Apple vaguely states that you can implement Sign in with Apple on Android, but there is no direct documentation on how to do it. We understand that Apple probably doesn’t care much for Android, but if they are going to provide a login system, and are going to force developers of multi-platform apps to adopt it, then providing no real suppo…

https://developer.apple.com/documentation/sign_in_with_apple... is more “direct” than most of the documentation I’ve seen on how to implement “OAuth” with other providers. (Trying to figure out how to integrate with “Microsoft 365” is particularly painful...) Eventually you might realize it’s based on an open standard https://openid.net/2019/09/30/apple-successfully-implements-... and that it’s relatively similar to…

It was way worse when I had to implement it a few months back.

It's still incomplete, their implementation deviates from the standard or use some lesser used mechanism like the form_post response_type, requiring custom code.

Implementing this was not a pleasant experience.

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

#372

Post by fomine3 »

IggleSniggle wrote: post #295
duxup wrote: post #218

Earlier quoted context omitted.

I think the problem is that once you want to be found, like for a grocery shopping app, most folks think you search and just find them and when it doesn't work....they don't know to go find some settings and figure it out.

Yeah but I dont want to be found. That's why I don't share my email. If I want to share with someone, I don't want the use that app to establish a link between us, because I don't want the app to know anything about us except what it must to do it's job. "Go find some setting and figure it out" is a UX fail. When I share eg a Dropbox link or a Google Photos link, you can get to it whether you have an established acco…

My anecdote: About 4 years ago, I looked a shared google spreadsheet with logged with my account. I thought that my account isn't shown to document owner but it seems not. I don't know whether I clicked something like share-account button.

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

#373

Post by ThePhysicist »

We've implemented a bunch of third-party login solutions on our platform, but in retrospect I think it was not worth it for us. I think integrating third-party logins makes sense if you know that most of your target users come from a given platform or your application wants to interact with a specific platform (e.g. a Github integration).

Otherwise the points the author makes seem painfully correct from our experience. Adding third-party sign-in immediately complicates the frontend as you need to support OAuth/OpenID-Connect workflows that are much more complicated than sending a password & e-mail combination (and possibly an OTP token) to a backend and reading the result. In addition, even though OAuth/OpenID-Connect are standardized it seems that almost every provider has decided to add its own quirks to it, so you can almost never just reuse the same code for integrating e.g. Github and Gitlab sign-ins.

What we currently do is to always add an e-mail using the third-party provider and use that to allow a password reset or password creation. You have to be quite careful with this as well though unless you want to open new security isues. Incorrectly implemented sign-in workflows via third-party providers can open avenues for account takeovers if you implement e-mail validation or account reconciliation incorrectly (e.g. an adversary might register an account with the victim's e-mail on a third-party platform and try to use that to sign into the victim's account; if the sign-in flow is configured incorrectly [happens a lot] the system will recognize the e-mail and sign the attacker into the victim's account).

Also, don't trust any validated information from third-party providers (especially e-mail addresses), as this can provide another attack vector. Always do your own validation.

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

#374

Post by m_eiman »

no_wizard wrote: post #12

A lot of the points they make here are real points, and I think AnyList has validity in their actions. I also think it’s not as unmanageable as it seems. Let’s analyze this quote, from the article, as it highlights what I imagine are a big crux of this issue: > with the “Hide My Email” option, your spouse or friends obviously won’t know your privaterelay.appleid.com email address, so when they enter your email addres…

> with the “Hide My Email” option, your spouse or friends obviously won’t know your privaterelay.appleid.com email address, so when they enter your email address, our systems will believe that you don’t have an account

Just create an invitation or "share list" link and let the user send it in any way they prefer, be it AirDrop, email or SMS.

The recipient clicks the link, and the service can connect the two accounts as needed (allowing the potentially new user to create an account as needed).

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

#375

Post by GoblinSlayer »

JAlexoid wrote: post #308
TheArcane wrote: post #271

Earlier quoted context omitted.

It's ironic because anylist cites that as a reason to stop supporting that very feature. That would only reduce my desire to Sign Up for that app.

As a reminder - us privacy aware technical people aren't remotely relevant anymore. So... You're not their target audience.

Apparently Apple makes privacy by default their PR strategy. So it's kinda relevant, at least in Apple garden.

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

#376

Post by [deleted] »

ThePhysicist wrote: post #373

We've implemented a bunch of third-party login solutions on our platform, but in retrospect I think it was not worth it for us. I think integrating third-party logins makes sense if you know that most of your target users come from a given platform or your application wants to interact with a specific platform (e.g. a Github integration). Otherwise the points the author makes seem painfully correct from our experienc…

[deleted]

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

#377

Post by mojuba »

3rd party logins have the advantage that sharing content from within your app on those social platforms becomes less of a friction unfortunately - if that's what your app relies on.

Email-only logins work fine with technical users, but non-technical ones absolutely suck at maintaining their logins and passwords. You lose users because they can't login for whatever stupid reason - one of the thousand stupid reasons - and they turn away to never come back, or they register afresh. This is the reality and yes, 3rd party auth is beneficial for popular (non-techie) services.

As for Apple Sign-in, haven't tried it on the development side yet but I can imagine it reduces friction even further and makes the user experience even nicer. This may be such a big bonus for your service that you may ignore the fact that you can't always collect your users' real email addersses. Find other ways to communicate: in-app messaging for example. If the user deletes your app then retargeting via email won't help much anyway - they will mark you as spam and overall it will probably do more harm than good, I think.

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

#378

Post by rorykoehler »

kergonath wrote: post #78
rorykoehler wrote: post #41

I’ve got a new sign in flow I’ll be using for all my indie apps. It solves 2 problems I have with Apple. 1) no PWA support for notifications 2) forcing stuff like this on everyone I use a telegram chat bot. After signing up via the bot that sends you a link to set your password, you then also request a short expiry sign in link everytime you wish to sign in. The chatbot doubles as a notifications channel. I’m thinkin…

I am pretty sure I would never create an account on a website that wants me to chat with a bot on Telegram. This sounds particularly user-hostile.

Why is it user hostile? Maybe you're misunderstanding what it is but for signup it's just a wizard and for login it sends you a link. Pretty seamless experience. To signup you click a deeplink button into the chatbot follow some simple steps and then get logged into the app. Otherwise the notifications work just the same as you're used to except it leverages the chat platform instead of the developer hostile native platform.

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

#379

Post by rorykoehler »

sharp11 wrote: post #55
rorykoehler wrote: post #41

I’ve got a new sign in flow I’ll be using for all my indie apps. It solves 2 problems I have with Apple. 1) no PWA support for notifications 2) forcing stuff like this on everyone I use a telegram chat bot. After signing up via the bot that sends you a link to set your password, you then also request a short expiry sign in link everytime you wish to sign in. The chatbot doubles as a notifications channel. I’m thinkin…

Could you elaborate? Doesn’t this require users to have telegram installed?

Yes. I’ll probably add more chat platforms as I go so you can use whatever one you already have installed

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

#380

Post by chrischen »

sudoit wrote: post #277
AnonC wrote: post #228

Earlier quoted context omitted.

Obfuscation of the email address is an explicit choice by the user when using Sign in with Apple. It’s not something forced by the service. If users are choosing to do that, it says something about the lack of trust the users have with whatever they’re signing up for.

Not necessarily. I have an app with 1,000 users, and about 99% of them choose to obfuscate. My app isn’t untrustworthy at all either. It’s an experimental app which attempts to let users create an iOS app on iOS. My suspicion is that people choose to obfuscate because it’s what’s selected by default.

Yes i obfuscate by default but as a user it’s also not immediately apparent to me that this would cause unintended side-effects. It’s really up to both the app developer and Apple to enable good user experience by designing around human behavior, rather than trusting the user can always make those decisions.
Post reply on HN