Live data from Hacker News

Why we won’t be supporting Sign in with Apple

blog.anylist.com

421–430 of 485 posts

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

#421

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…

Having had this same problem multiple times, I actually made it a point to save a “login” for those sites that when I autofill it reminds me which auth service I’ve used. Username: Log in with FB Password:

I do something similar with a generic password manager.

I've tried pinging the developers to support the idea directly, but I've been met with incomprehension.

Not sure if I'm explaining it wrong, or if it's way more work than I'm anticipating.

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

#422
> We’re a small company that makes money when people like our app and pay for it. We do not make money with creepy tracking or by selling your information. When you provide us with your email address, it is never sold, shared, or used to invade your privacy.

You're the only one, then.

What's happening here is another revolution. Email spam got so bad, that Congress actually passed a law. Which, of course, did almost nothing. People got so tired of spam, that they avoided email, and allow the services to silently remove 90% of the crap.

This has now spilled over into voice calls, where it got so bad, so quickly, actual legislation was considered again. But people quickly realized that their phone contained a curated whitelist. Now, I never answer unless the number is recognized, and I think most people are doing the same.

Texting is also similarly whitelisted.

At this point, email systems and clients need to start with the assumption of whitelisting. Instead of just a "spam" folder with obvious crap, and controls to flag or unflag messages in that folder, we also need a "questionable" folder, with controls to mark as "known" or "unknown", as well as "spam". Emails shouldn't make it to my inbox unless they pass BOTH the whitelist AND the spam check.

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

#423
post #412

Earlier quoted context omitted.

> If the service provider does not have your email address, they are severely hampered with regards to customer support. No, they're not. They're just relying on email as a user verification methods as it's the easiest approach. Other methods are possible.

Verification is only one part of the problem. The other is communication. If I can't contact my customers, how do I support them (e.g. report a security problem)? If my customers can't communicate which account is theirs, how do we help solve problems? Email addresses and/or phone numbers make this a lot easier.

Simple, have them create a user id, and/or expose a "support id" somewhere in the system that lets you tell the support person which account record is yours.

I never want "communication" from an app developer unless I initiate it.

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

#424

Earlier quoted context omitted.

Surely you can’t hide your email from apple itself.

You can't; the design behind Sign in with Apple is that you've already trusted them with your email as you're using it to buy apps from the App Store.

Trusting them to protect your arbitrary data is a completely different scenario; there’s just more concentrated risk (i.e. your identity is just gone when Apple gets taken).

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

#425

Earlier quoted context omitted.

For the first point, the app can explicitly tell the user what their login is, or otherwise assign some unique identifier the user can use when contacting support. The app can also offer to contact support for them, which can pre-fill the user identifier. For the second, that’s entirely the user’s choice. Your app can also allow them to associate a new email address for this purpose (which strikes me as exactly what…

And when you're using the web app on a desktop? There's no easy sharing mechanism there.

Email, Telegram, WhatsApp, etc, etc. Lots of them.

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

#426
post #421

Earlier quoted context omitted.

Having had this same problem multiple times, I actually made it a point to save a “login” for those sites that when I autofill it reminds me which auth service I’ve used. Username: Log in with FB Password:

I do something similar with a generic password manager. I've tried pinging the developers to support the idea directly, but I've been met with incomprehension. Not sure if I'm explaining it wrong, or if it's way more work than I'm anticipating.

Try linking them to this thread? I feel like it sums everything up in a way that a dev would understand.

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

#427

Earlier quoted context omitted.

The credentials are at least not in multiple databases and stand some chance of being more secure, so it’s not as bad as with direct credential reuse, but yes, if you do compromise that one identity provider you’re in big trouble.

With Social SSO, you essentially are passing the trust from some random company getting hacked and revealing your re-used password, onto the shoulders of internet giants like Facebook, Google, Twitter, Apple, etc and putting the trust on them, that they know what they are doing in terms of security. I still agree that they are variants of the same fundamental problem (a single credential protects all of your logins)…

Aren't password managers, especially cloud-based ones like LastPass, also the same thing: they hide all your passwords behind a single master password (and a MFA optionally).

Granted, their only job is to secure your passwords, but it's effectively equivalent to a single SSO service from a protection standpoint (if all your accounts would accept that SSO login).

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

#428
post #64

Earlier quoted context omitted.

Why should Apple be allowed to dictate if an app asks for an email address? They should not become the defacto law makers of our society

I'm not sure they should be able to, but I assume they could disable Sign in with Apple for a given site if they wished.

This applies to any SSO.

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

#429
post #45

Earlier quoted context omitted.

I wonder if Apple would be ok with asking them to give up their email? Apple clearly likes the idea of the hide option... personally I would expect a less than positive reception from Apple. I get where both AnyList (if they asked) and Apple (if they didn't like it) would be coming from here. It does seem to be a shortcoming here where outside of a user one time sign up situation... you don't want to have to burden t…

Why should Apple be allowed to dictate if an app asks for an email address? They should not become the defacto law makers of our society

They don't, the user controls this. When the user authorizes the client, they have the option to share their actual Apple ID email or use an obfuscated one.

Apple isn't forcing anything here.

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

#430

Earlier quoted context omitted.

I'm going to be fascinated to see what this does for conversions. My company built the Neil Young Archives, when doing so we initially launched with Social log ins and at one point Neil decided Facebook and Google were evil and wanted to remove the access. According to our logs a full 2/3s of all users were registering with a social account and we were having great success getting folks to log into a free service (We…

I just gotta say I both love and hate the Neil Young archives. I hate them because the website is genuinely awful, and a chore to navigate around. However, I love that I have access to a load of stuff I haven't heard before. At any rate, thanks for the hard work you put into it and I've used this site a lot.

Yeah we didn't design it. Just did the best we could to make it all work. The design is actually a bit of a legacy as the original version was actually an interactive blu-ray set[1]

I kind of ended up with a love hate thing as well, it breaks pretty much every responsive, UX, accessibility rule out there, but at the same time it was Neil's vision. It's at least somewhat intentional that you have to dig at it a bit.

All that being said my first meeting with Neil I told him "This won't work on mobile" and his exact words were "Fuck Mobile ..."

[1] https://www.amazon.com/Neil-Young-Archives-One-Blu-ray/dp/B0...

Post reply on HN