>> Third-party login systems like Sign in with Apple cause many user experience and customer support headaches.
It’s not. It’s perfectly slick , simple and powerful and even non technical user can use. Please enable.
Why we won’t be supporting Sign in with Apple
431–440 of 485 posts
Re: Why we won’t be supporting Sign in with Apple
#432Earlier quoted context omitted.
A party in OAuth authentication can request some obligatory information, and if email is part of it, you won't be able to deselect it. In general, sites use email as an indication of a unique, real person. I imagine most of them do not really care about it afterwards, which is why the SSO systems even work (though, they can demand an email too).
It was not that Facebook allowed the user to deselect the e-mail address from what would be shared. Rather, it allowed them to randomly generate an e-mail address to share with the other party. I think messages sent to this address were forwarded to the user's Facebook inbox. And to answer scarlac's question, yes, they removed this feature a very long time ago.
Ah, thanks for the correction! :)
Re: Why we won’t be supporting Sign in with Apple
#433Earlier quoted context omitted.
"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.
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.
So... I'm having a bit of a hard time as seeing this as not a problem with Apple more than this app company. Apple is obfuscating your email address by default (great!) but is then forwarding that obfuscated email address to an address that they select without asking the user.
It seems like this entire complaint would be solved if Apple prioritized "obfsucated email works for our paying users" (i.e. deliver mail to an address they select) over "create a strong incentive to use our email service if they want to get their precious emails".
I use obfuscated emails all the time, everywhere, by default. But I selected what email address they forward to when I set it up. How does an app maker get the blame for Apple not doing this?
Edit: Now, the app relying on un-obfuscated email addresses for finding contacts I have less sympathy for. There are many other good options for this, and they should work with obfuscated email address IMO. Seems like everyplace I use has no trouble with usernames...
Re: Why we won’t be supporting Sign in with Apple
#434Earlier quoted context omitted.
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 p…
Sorry, hostile was probably too much.
I understand after having read the explanation. However, my experience with chatbots is that they are unreliable, unhelpful and obnoxious, and I tend to go out of my way to avoid using them. I don't think a conversation is a right model for this. I also don't think it looks good when a website or app wants me to install a messaging app to create an account (though of course some people already use Telegram). It would have to be very enticing for me to overcome that friction.
The platform (Apple's, in this case) might be hostile to developers to some extent, but the whole web is hostile to users, in no small part thanks to websites slurping as much PI as possible and then leaking it one way or another. I get spam and phishing attempts every day, as do all of us, and I regularly see some of my burner emails show up on haveibeenpwned. Any service that helps me separate my accounts from me is some progress.
Re: Why we won’t be supporting Sign in with Apple
#435As 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…
TBF if single sign on is implemented correctly and you use the same email address across your accounts then it shouldn't matter which SSO you're using.
When you log in for the first time it should request permission to "see your email address". Then you authenticate with your provider and get redirected back at which point the website should create an account for you on behalf of that email address. If next time you log in again via a complete different provider which has the same email address then it should just work. I mean that is the whole point of this...
Re: Why we won’t be supporting Sign in with Apple
#436Worth noting that AnyList automatically subscribed me to a marketing list without double opt-in or any kind of consent, which is exactly the kind of behaviour that makes me not want apps to have my real email address.
> automatically subscribed me to a marketing list Side note, disabling 'load remote content' in email client stops all spam in a while, they think emails are not read.
Using Gmail at all seems to have the same effect as well since they pre-load and proxy almost all email content. Only when you use alternative mail clients might they see the images/remote content being loaded from a non-google IP.
Re: Why we won’t be supporting Sign in with Apple
#437Earlier quoted context omitted.
> If I need an email to verify I'm not a bot, that's fine. But if a trusted 3rd party can verify I'm not a bot, then the only reason you would want my email is to do something unethical with it: namely, use my data in a way that I never intended gave you permission to use it. This was addressed in the article. If the service provider does not have your email address, they are severely hampered with regards to custome…
> 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.
> No, they're not.
Did you read the article? It seemed very clear to me that they had significant issues with customer support past just verification.
And what would you suggest as an alternative way to identify the user, anyway? Any alternative method of authentication seems doomed to fail - using a real name runs into issues with duplication, requiring users to set a username would likely require significant changes to the platform to support it and lots of people would forget it when they couldn't get their preferred username, and having a customer support code inside the app wouldn't help when the user loses access to their account.
It seems like there are alternatives, but none that the average user who signs in with Apple and needs to contact support will be able to get past on a consistent basis.
Re: Why we won’t be supporting Sign in with Apple
#438Earlier quoted context omitted.
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.
What about when you lose access to the account and don't remember what string of numbers you had to use after your preferred username because it's not a universal identifier that only you can use? In the case of the support ID, you'd need to be able to access the account to even view it.
Re: Why we won’t be supporting Sign in with Apple
#439Earlier quoted context omitted.
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.
Can't they just ask the user to open the app and send them some identifying number they can find in the ui?
Not if they have no ability to reply to the user in the first place. The user may also be contacting support because they lost access to their account and not be able to access the identifying number.
Re: Why we won’t be supporting Sign in with Apple
#440Earlier quoted context omitted.
"by using the email account you registered with"
not GP but like, ok, why can’t that be sent from any other email (user-provided or otherwise)?
My guess is that it's being send to the email the user registered with. And requiring them to provide a separate email from the one they registered with completely defeats the purpose of obfuscating the email in the first place, so I think it'd be unreasonable to ask a developer to implement a whole second place to put an email just to work around Apple denying access to that information in the first place.
At the very least Sign in with Apple needs to support a request for the user to enter the real email they want to use to be contacted by the app after-the-fact for cases where someone obfuscates their email but then wants access to functionality that explicitly requires their real email.