Live data from Hacker News

Why we won’t be supporting Sign in with Apple

blog.anylist.com

341–350 of 485 posts

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

#341
Well, though titty. Honestly, as a user, I don’t give a damn about the pains this can cause to developers. The amount of spam and unsolicited email crap this is gonna save me from is worth it 100% for the users. And as a developer, I honestly think that Third party sign ins are lazy solutions that empower data-hungry companies way more than they deserve. If your business model relies on people giving you their data or reselling their email or using it for unsolicited purposes (these are the only reasons you would be affected financially by a privacy-driven solution like SIWA) then your business model is bullshit. Suck it up.

EDIT: I really love the downvotes from developers that are perfectly aware this is how the things are.

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

#342
post #280

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…

Perform an audit on yourself. Both Facebook [1] and Google [2] have pages where you can check third-party apps that you have connected with. You might be surprised what you find. [1] https://www.facebook.com/settings?tab=applications&ref=setti... [2] https://myaccount.google.com/security

[deleted]

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

#343
post #171

Earlier quoted context omitted.

Time to create a new service to unify all your SSO accounts! One single SSO!

If only there was a decentralized option that has already solved this... We could call it OpenID or something like that... Oh, wait..

You also have IndieAuth that is slowly gaining more adoption.

https://en.wikipedia.org/wiki/IndieAuth

https://indieauth.net/

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

#344

Earlier quoted context omitted.

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.

It's convenient right up to the point where I need to get back into an account but forgot if I used it or not - which is exactly the point of the parent. I too have struggled to remember which third party sign-on I used (or if I used a native sign in), so now I avoid them every time, too. They're literally only convenient if I want to have an account that I'm happy to 'throw away' or, to accidentally create duplicate…

Spotify is a PITA for this. And there is no easy way to migrate to a "non facebook" account your playlists and stuff.

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

#345

Earlier quoted context omitted.

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.

I'd personally for for the method used by Blizzard and Discord where a randomly generated ID is the actual unique value, while the username is just a display setting.

I get all the advantages of that but for some reason it's so hard when you get into a game and you're trying to get everyone there into a discord.

Riot does this with Valorant too and the implementation is a nightmare.

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

#346
post #277

Earlier quoted context omitted.

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.

I agree with the sibling in that defaults are powerful. However, I've never built anything directly used "by the public", nor am I very familiar with how Apple Sign in works. So I'm wondering, as the developer of a trustworthy app, what's the drawback in the user giving an obfuscated address? Is it not possible for you to contact the user using this address? Does the user have to manually allow getting mail to this a…

As explained in the article a lot of people use the iCloud mail for their apple account and they don’t check it because they use another provider main mail address. Furthermore if they contact them from their email for support they have no way to associate it with the mail registered in the system, so they can’t help them. If you ask me they seem both very valid points.

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

#347
> your email address, it is never sold, shared, or used to invade your privacy.

This is ambiguous. "..to invade your privacy". They should have stopped at "sold, shared. The "to invade your privacy" is a bit doublespeak. One can say "we do not invade privacy, we merely inform of new products and services (aka marketing).

I know I am being pedantic, but hey.. it doesn't write "never" it writes "never for A".. we never wrote "never for B", so B is allowed by our T&C (which I haven't read so I may stand corrected).

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

#348

Earlier quoted context omitted.

I agree with the sibling in that defaults are powerful. However, I've never built anything directly used "by the public", nor am I very familiar with how Apple Sign in works. So I'm wondering, as the developer of a trustworthy app, what's the drawback in the user giving an obfuscated address? Is it not possible for you to contact the user using this address? Does the user have to manually allow getting mail to this a…

As explained in the article a lot of people use the iCloud mail for their apple account and they don’t check it because they use another provider main mail address. Furthermore if they contact them from their email for support they have no way to associate it with the mail registered in the system, so they can’t help them. If you ask me they seem both very valid points.

Do you have a number for “a lot of people”? I am very skeptical of this data point.

This email address is used for a lot of communication with Apple, e.g. receipts from App Store.

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

#349
post #18

Earlier quoted context omitted.

I've never seen an app that required a FB or Google login. It was always possible to use email+password.

Lucky you! I've run into lot of these apps offering only FB/Google sign in. Or offering mobile number only login. For e.g. I like playing scrabble and Scrabble Go only support FB login so I'm playing only as Guest user for months now. Mobile number login is even worse! Why do I need to share my mobile number for something where you don't need to have it!

Mobile number login is common for apps from China as large number of Internet user there only have a mobile phone, no desktop and no email. Its the only way to verify account.

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

#350
There are 3 major problems with this kind of sign-in from the user perspective they apparently omit: whenever you sign-up for a service B with an account at A (usually Google, probably applies to Apple, Facebook and the rest as well) 1. A will block your account at B at any time as soon as its (A's) algorithms realize they don't like you for some stupid reason they won't even tell you (which is icky but understandable given how many users they serve) 2. A tracks your usage of B (obviously). 3. The most overlooked - A discloses many additional details about you (like your contacts, your location, your birth date, your real name etc.) to B. Sign up to some shitty website once and they immediately have enough data on you to apply a wide range of social engineering / identity theft attacks with ease.

I actually can consciously accept the 2 in many specific cases but 1 and 3, each alone, are enough for me to avoid using this kind of sign-in.

Post reply on HN