Live data from Hacker News

Why we won’t be supporting Sign in with Apple

blog.anylist.com

181–190 of 485 posts

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

#181

Earlier quoted context omitted.

Progressive consent makes sense though: in starting out with an app that i have no previous trust relationship, "Hide my email" sounds like a good idea in a trial balloon. If after using the application it tells me that to better use its collaboration tools it would like me to consent in giving a more direct email address, I might change my mind given changes in trust relationship (I have been using this app for some…

I like this approach. And giving users that progresive consent is smart. If I open your app and am greeted with "You need to give us your email to get the most out of our app" then I'll be upset as that is user hostile. But If I click a share button and am told "In order to make it easier for people to send you things, would you provide your email" and being able to dismiss that and continue to use the app and all of…

That's something that bugged me about the article because it sounds like they do fallback to an "invite link" pattern when they don't know an email address, but it sounds like they've spent most of their UX optimization work on flowing people most directly from invite links into "Create Account" that they don't trust users not to create new accounts on receiving an invite link. (Maybe just stop assuming that people receiving invite links don't already have accounts and instead better your UX flows for existing users?)

(ETA: They make an okay follow up point that someone accepting an invite link sent to a different email sends a signal that they could just go ahead and link that email address directly to the account, and don't see why you wouldn't just give them that email in the first place. But in addition to being a squicky privacy faux pas to automatically link any email to an account without direct user consent, there are plenty of reasons to send emails to an address only indirectly linked to a person and/or that a user would not feel comfortable directly linking to an account. It's a somewhat flimsy argument below the surface, I think.)

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

#183
post #17

Earlier quoted context omitted.

It's good that you read Hey's blog post and are repeating it here, but it's not very accurate in this case. Specifically, if you implement Sign In with Apple, then they are still your customers as much as ever, they just might choose to hide their information from you because they don't trust you, which means that the power in the relationship is transferred to the user instead of the app developer.

everyone can create a second email address for precisely this purpose and it will be much more anonymous than anything apple promotes

Congratulations, now all of your email goes to a single different email address; your tracking profile is now associated with randomstring@email instead of john.doe@email.

If you wanted something truly private you could create an account at a provider like Fastmail or ProtonMail and create an alias for each account (or just wildcard a custom domain until you need to send from an address). I doubt any tracking system is based on the domain in your email address... not yet, at least.

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

#184

Earlier quoted context omitted.

Perhaps you don't use AnyList? It doesn't make sense to use with a private mail relay because they use email as an addressing system. And honestly, few users will go look up their per-app address and tell people to add them.

Ah, I wasn't aware that e-mail was used as an addressing system within AnyList. Do users not have any usernames associated with their e-mails? Still, I think in this day and age, having a requirement in your product that says "e-mail that is provided should be the one the user uses the most" is pretty naive. In general, it's true, but when it comes to 3rd party authentication providers like Facebook, Google, and now…

It is rather unusual, honestly. Even Venmo uses just an app-specific name. That's probably a lesson in product design: have your own usernames.

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

#186

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?

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

#187

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 really wish there were a way to know whether I already used Facebook, Google, or Apple to log into a site or app before"

You can. On each of the places you mention (Google and Facebook, certainly), somewhere in a settings page/window, you'll find your list of 'authorised apps'.

These will be a list the login systems to the third-party sites you've used to log in with.

You should then see a way to 'revoke' their access to your data.

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

#188

Earlier quoted context omitted.

Sign-In with Apple is a (mostly) standard OpenID Connect provider that works everywhere (and works just like sign in with FB, Google, et al from a technical implementation), including the Web and Android. It's an interesting miscommunication or misunderstanding (and I was not surprised to see it in this article) that applications and developers think the "Sign in with Apple" button should only show up on Apple device…

If I’m on Windows and see Sign-in with Apple how am I supposed to sign in? By typing in a generated email address? It’d not that it can’t work, it’s that it’s a miserable user experience.

If you are on Windows and see Sign-In with Apple, Apple asks you to sign into iCloud, on their servers, if you are not already. It's almost the exact same sign-in flow you would see on Windows iTunes or Windows version of iCloud. You use your normal iCloud account information and 2FA verification (authorize the login in one of your Apple devices). Apple's servers look up the generated app-specific email address for you, just like your Apple device would, and passes that on when it passes the authentication token to the requesting application (which would use the same application identifiers it uses on iOS).

It's no worse a user experience than Sign in with Facebook or Sign in with Google, and in most ways it is the exact same user experience: click the button, get an Apple sign in prompt on Apple servers, sign in, get automatically redirected back to whatever app needed the sign in.

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

#189
Is it just me or do these sites not realize that "We will never sell your email" does nothing for me? It's not that you'll sell it's that you will get hacked or lose a laptop or have an admin email everyone and then I will get spam. How do others at HN deal with this (disposable emails and prefix/suffix are a huge pain)

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

#190
post #187

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 really wish there were a way to know whether I already used Facebook, Google, or Apple to log into a site or app before" You can. On each of the places you mention (Google and Facebook, certainly), somewhere in a settings page/window, you'll find your list of 'authorised apps'. These will be a list the login systems to the third-party sites you've used to log in with. You should then see a way to 'revoke' their…

That doesn't solve the problem. You would have to go to every method to figure out which one it might be listed under. It needs to be in the browser/password manager to tell you which service was used.
Post reply on HN