Why we won’t be supporting Sign in with Apple(blog.anylist.com)
blog.anylist.com
Why we won’t be supporting Sign in with Apple
https://blog.anylist.com/2020/06/sign-in-with-apple/
483 comments
"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.
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.
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.
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.
It's also likely that 99% of users have no reason to share their email with you. Also, your app is extremely untrustworthy. It sounds like a random app you find by searching for key words. You're not Microsoft or Google, you have no reputation or credibility. They have no relationship with you, they don't know you, they likely have never interacted with your company before this.
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.
Being default probably helps, because most people don't know they're doing with software and just accept the defaults assuming they're best practices. If the default were to share the email, you might see more people sharing email, but I would argue it's because people don't know they can and should obfuscate it.
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.
Being default probably helps, because most people don't know they're doing with software and just accept the defaults assuming they're best practices. If the default were to share the email, you might see more people sharing email, but I would argue it's because people don't know they can and should obfuscate it.
> 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 customer support.
This was addressed in the article. If the service provider does not have your email address, they are severely hampered with regards to customer support.
> 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. 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.
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.
A simple "let me email a 6 digit alphanumeric code to your icloud email" 2fa style identification would cover anybody who is able to open their mailbox. Not perfect, but gets around some of the problem.
I actually think the customer experience of "I switched from apple to android and now I dont know any of my usernames" is a bigger issue. If apple wants Sign in with Apple to work, it needs to behave a bit more like an agnostic 3rd party password manager, work on every platform, and have ways to interact with it on any device. They should release Keychain as an Android app and Chrome extension, and allow you to use it to see your Sign in with Apple data.
I actually think the customer experience of "I switched from apple to android and now I dont know any of my usernames" is a bigger issue. If apple wants Sign in with Apple to work, it needs to behave a bit more like an agnostic 3rd party password manager, work on every platform, and have ways to interact with it on any device. They should release Keychain as an Android app and Chrome extension, and allow you to use it to see your Sign in with Apple data.
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.
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.
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.
tl;dr email isn't needed, people are just used to it.
It's a fair point, and perhaps its one that the likes of Apple SignIn should solve. On the one hand, even Microsoft and Apple send me heaps of spam under the guise of "communication" and I don't want them to have my email address if I can avoid it. The OP says they have trouble with support, but they can (and it sounds like do) tell people to just check their Apple email. Most places that I contact for support require me to put in a contact email for that ticket because people use throw-aways anyway. As for security problems, well I'm glad you're one of the few companies to actually disclose security breaches. But if the information on the website is actually sensitive, then there should be additional checks to begin with. If it's CC info, you should contact the CC company, there should be 2FA, there should be more than an SSO service, which already prevents the biggest and worst security breach of leaked passwords. In short, I doubt the need to contact a customer unsolicited is so great, common, or difficult as to require that a user disclose a non-obfuscated email address, which people already commonly have throwaways for. And the reason they have throwaway accounts is because 99% of the time, when I give someone a ...@spamgourmet account or whatever, that address gets spammed, even though I told them not to put them on the mailing list (because they share the email with third parties, or just plain ignore it).
The tradeoff is a bad one. I do not have sensitive information on Reddit that is not public. A private investigator could probably deduce who I am by looking at my Reddit posts, figuring out where I live, where I went to school, what family members I have, what my job is. They don't need to contact me urgently about a security breach. You can say when I sign on and lock my account until I acknowledge it, but it's not urgent. Even a website that might need sensitive information and, for some reason, doesn't want to require I actually verify my identity for real to upload that sensitive information, that doesn't mean I'm using the website in that capacity and should give up identifying information in case I need to give up identifying information later and you need to contact me that my information has been leaked.
The perspective is worth thinking about, but I'm unmoved that it amounts to pushing the needle to "you need my real, primary email address." I believe the tiny, tiny minority of companies that actually need that and shouldn't just rejigger their system to better security and privacy practices to start with can find reasonable workarounds or resort to mild inconveniences like requiring a callback number on support.
It's a fair point, and perhaps its one that the likes of Apple SignIn should solve. On the one hand, even Microsoft and Apple send me heaps of spam under the guise of "communication" and I don't want them to have my email address if I can avoid it. The OP says they have trouble with support, but they can (and it sounds like do) tell people to just check their Apple email. Most places that I contact for support require me to put in a contact email for that ticket because people use throw-aways anyway. As for security problems, well I'm glad you're one of the few companies to actually disclose security breaches. But if the information on the website is actually sensitive, then there should be additional checks to begin with. If it's CC info, you should contact the CC company, there should be 2FA, there should be more than an SSO service, which already prevents the biggest and worst security breach of leaked passwords. In short, I doubt the need to contact a customer unsolicited is so great, common, or difficult as to require that a user disclose a non-obfuscated email address, which people already commonly have throwaways for. And the reason they have throwaway accounts is because 99% of the time, when I give someone a ...@spamgourmet account or whatever, that address gets spammed, even though I told them not to put them on the mailing list (because they share the email with third parties, or just plain ignore it).
The tradeoff is a bad one. I do not have sensitive information on Reddit that is not public. A private investigator could probably deduce who I am by looking at my Reddit posts, figuring out where I live, where I went to school, what family members I have, what my job is. They don't need to contact me urgently about a security breach. You can say when I sign on and lock my account until I acknowledge it, but it's not urgent. Even a website that might need sensitive information and, for some reason, doesn't want to require I actually verify my identity for real to upload that sensitive information, that doesn't mean I'm using the website in that capacity and should give up identifying information in case I need to give up identifying information later and you need to contact me that my information has been leaked.
The perspective is worth thinking about, but I'm unmoved that it amounts to pushing the needle to "you need my real, primary email address." I believe the tiny, tiny minority of companies that actually need that and shouldn't just rejigger their system to better security and privacy practices to start with can find reasonable workarounds or resort to mild inconveniences like requiring a callback number on support.
Call us back when you get the entire internet to stop using emails and phone numbers for communication. There really isn't a reasonable other option right now.
This is anecdotal but if I could chose not to share my email with things I sign up for, I wouldn’t have a gmail address used solely for signing up to things. I can’t think of a single thing that I’ve ever signed up for that I actually wanted to have my email.
So sure, it’s default, but unless I’m unique some people will see the default and go “why isn’t every 3rd party login like that?”.
So sure, it’s default, but unless I’m unique some people will see the default and go “why isn’t every 3rd party login like that?”.
My recollection is the first time I used Sign In With Apple it forced me to choose (no default), and after that it defaulted to my last choice.
I expect 99% are obfuscating because that’s the sensible choice to make. Giving an app my real email should only be done if there’s an explicit need for this, such as being able to log in from non-Apple devices.
I expect 99% are obfuscating because that’s the sensible choice to make. Giving an app my real email should only be done if there’s an explicit need for this, such as being able to log in from non-Apple devices.
You make a good point, and in general I agree, but it introduces additional headaches if I think about logging in from a non-Apple device later.
You actually can support Sign In With Apple from arbitrary platforms, using the JS API.
https://developer.apple.com/documentation/sign_in_with_apple...
This is obviously the most useful for websites, but Apple’s developer site links to this with the descriptor “for web and apps on other platforms” so clearly they’re ok with Android apps using it too.
https://developer.apple.com/documentation/sign_in_with_apple...
This is obviously the most useful for websites, but Apple’s developer site links to this with the descriptor “for web and apps on other platforms” so clearly they’re ok with Android apps using it too.
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 address or somehow jump through some hoops to read it?
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 address or somehow jump through some hoops to read it?
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.
If the user emails them they can certainly reply. It's just a matter of showing their email somewhere. The ID can be shown before the user logs in. That would not be less secure then relying on the email to reset the password. If someone is able to access the user's unlocked phone, they probably can access their email account too.
> 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.
Thanks for the clarification, I didn't think of this scenario.
This looks like a pretty big problem, as I can imagine a situation where the user doesn't have access at all to the app and may not have kept the initial email with any identifying info.
Isn't there an easy way for the user to know which obfuscated address was used for which app?
Thanks for the clarification, I didn't think of this scenario.
This looks like a pretty big problem, as I can imagine a situation where the user doesn't have access at all to the app and may not have kept the initial email with any identifying info.
Isn't there an easy way for the user to know which obfuscated address was used for which app?
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.
This email address is used for a lot of communication with Apple, e.g. receipts from App Store.
Receipts from the app store go to my gmail account.
I bought my iMac on the Apple store, and the receipt was also sent to my personal account.
I bought my iMac on the Apple store, and the receipt was also sent to my personal account.
Why do you need my email address? I wouldn't give it to you just so you can have bad database security and then have my email dumped somewhere.
Why is it a problem for you?
Isn’t a problem. I chose to use Apple sign in because I didn’t need email other than for having a way to later setup billable accounts. I plan to introduce a subscription option in a month or 2 and thought there’d be less friction if people already signed up.
update: I've now removed the login entirely until it's absolutely needed. This change will go live in the next few weeks
Most likely. Never underestimate the power of defaults
>My app isn’t untrustworthy at all either.
That's up to the user to decide. For me trustworthy = something like Basecamp, Amazon, etc, not some random small app.
That's up to the user to decide. For me trustworthy = something like Basecamp, Amazon, etc, not some random small app.
> That's up to the user to decide.
> trustworthy = [...] Amazon
Good point, because your example includes one of the few companies I don't trust at all.
> trustworthy = [...] Amazon
Good point, because your example includes one of the few companies I don't trust at all.
different types of trust.
Trust not to misuse.
Trust not to leak in a breach.
Realistically, my email address is something I trust Amazon with both of, because email isnt how they spam me, they are smart enough they can identify me without my email address, and I expect their security to be more hardened and battle tested.
Trust not to misuse.
Trust not to leak in a breach.
Realistically, my email address is something I trust Amazon with both of, because email isnt how they spam me, they are smart enough they can identify me without my email address, and I expect their security to be more hardened and battle tested.
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.
I choose to obfuscate because I don't want every app I download to have my email address.
"My app isn’t untrustworthy at all either. It’s an experimental ..."
There is a big contradiction in there...
Everything experimental is by definition untrustworthy.
There is a big contradiction in there...
Everything experimental is by definition untrustworthy.
There's two kinds of "obfuscation" at play with Sign In With Apple.
One is true obfuscation - "hide my email". That would be a poor choice for use with any app you hope to have an ongoing relationship with, I'd think.
The other is just the use of iCloud email addresses, detailed in the post, which seemed like a very good and concerning point. It's also much less likely to be a problem with FB or Google login.
One is true obfuscation - "hide my email". That would be a poor choice for use with any app you hope to have an ongoing relationship with, I'd think.
The other is just the use of iCloud email addresses, detailed in the post, which seemed like a very good and concerning point. It's also much less likely to be a problem with FB or Google login.
I can have an ongoing relationship with an app without that app’s developer having an ongoing relationship with my inbox.
Sure you can. But they explain why it's not applicable for their use case.
And I would literally blow up at Apple, if they forced this on TripIt... Sharing trip information is done using registered email. And iCloud email is crap.
And I would literally blow up at Apple, if they forced this on TripIt... Sharing trip information is done using registered email. And iCloud email is crap.
Sharing trip information is done using registered email.
Could you provide any details? How is such "registered" email different than any other email?
Could you provide any details? How is such "registered" email different than any other email?
"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.
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.
If I understand the model of the hypothetical app referenced above, they send email containing confidential (already, this seems problematic, but let's ignore that) "trip" information to some email address. Within that structure, then sure it's problematic to have to require two different email addresses. Except, you don't have to do that. Don't require an email address to start using the app. Let users enter whatever confidential trip info they want, keep a reference to the resulting DB records in a cookie, and only require an email address when the user wants to, uhh, get an email sent.
Having typed the foregoing, I realize now I'm basically just saying "don't use any third-party sign-in, including SIWA". Maybe it's fine that the ecosystem doesn't always cater to apps of questionable utility...
Having typed the foregoing, I realize now I'm basically just saying "don't use any third-party sign-in, including SIWA". Maybe it's fine that the ecosystem doesn't always cater to apps of questionable utility...
When you share a Trip with Tripit, or add a traveller, you enter their registration email. [email protected] or something.
> My guess is that it's being send to the email the user registered with
I assumed otherwise because they specifically wrote "sharing". Still, I'm not sure agree with:
> 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
I can't use most apps without providing an email, whether they need it or not. That's a much worse situation than not being able to use some features without providing one (which still assumes me having no access to or knowledge of my own iCloud email).
I assumed otherwise because they specifically wrote "sharing". Still, I'm not sure agree with:
> 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
I can't use most apps without providing an email, whether they need it or not. That's a much worse situation than not being able to use some features without providing one (which still assumes me having no access to or knowledge of my own iCloud email).
When you send an email, there's typically 2 email addresses.
But if you share a trip to a person who's on Tripit - they just get a notice and a record in their webapp.
But if you share a trip to a person who's on Tripit - they just get a notice and a record in their webapp.
Your primary iCloud email address is meant to just be your main email address, including non-Apple email addresses.
"Meant to" doesn't mean "is", and even if 99% of people do what they are "meant to", that still leaves millions of people doing it the "wrong" way.
Yep. I rarely run into people who use their iCloud email, and that goes for both the technically inclined and the average users.
Locking things down like this seems to have some serious negatives that Apple needs to reconsider their approach for.
Locking things down like this seems to have some serious negatives that Apple needs to reconsider their approach for.
But you don't need to have your iCloud mail set as the primary mail for your AppleID. You don't even need to create an iCloud mail when you create an iCloud/AppleID account, it's an optional step. I recently created another iCloud test account and it's also not shoved in your face or anything, it's a small little button called "Don't have an email address?" somewhere.
So I don't even really understand how people get into this situation.
So I don't even really understand how people get into this situation.
The biggest problem is that Apple insists on tying the fake email with your iCloud email, which the vast majority of people don’t use.
If they tied it instead to what people’s normal mail was, a lot of issues would be averted.
If they tied it instead to what people’s normal mail was, a lot of issues would be averted.
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...
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...
I dunno about that. I literally choose it every time, because why not? It's my default.
That may be a reason in the future, but they did specifically mention a couple really good reasons to dump Facebook login now:
> "That’s become even more true as time goes on, since Facebook constantly seems to be upping the ante with creepy privacy practices. We use the Facebook SDK to provide login functionality, and every new release of the SDK seems to add new tracking options that are turned on by default, which we have to take action to disable. Furthermore, the Facebook SDK has quality problems, and recently caused a huge number of iOS apps to crash due to a misconfigured server."
> "That’s become even more true as time goes on, since Facebook constantly seems to be upping the ante with creepy privacy practices. We use the Facebook SDK to provide login functionality, and every new release of the SDK seems to add new tracking options that are turned on by default, which we have to take action to disable. Furthermore, the Facebook SDK has quality problems, and recently caused a huge number of iOS apps to crash due to a misconfigured server."
As a user I can't see why any random app needs to know my true email address.
From the article:
> If a customer contacts us asking for support, and we need to look up something in their account, typically we can just ask them for the email address on their account. But with “Hide My Email” that wouldn’t be easily possible, because the customer would have to figure out the privaterelay.appleid.com email address used for their account.
> Furthermore, if there are platforms where AnyList doesn’t support Sign in with Apple, like Android, and someone wants to log into their account, they’d have to know their privaterelay.appleid.com email address. (And that certainly won’t be easy to find if you no longer have an iOS device.) And then they’d have to create a password with us, since they wouldn’t be able to sign in using Sign in with Apple.
> Finally, for a service like AnyList, which is heavily focused on sharing lists with other people, the “Hide My Email” option greatly complicates collaboration. Typically, customers share a list by typing in the email address of the person they want to share with. If that person already has an account, the list is instantly shared. But 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. At that point, you’ll get an email from us asking you to create an account. If you accidentally create a new account, it won’t include the work you’ve done in your existing account created via Sign in with Apple. And if you manage not to make that mistake, then there would be a link between your email address and the account you created with Sign in with Apple, negating the value of hiding your email address.
> If a customer contacts us asking for support, and we need to look up something in their account, typically we can just ask them for the email address on their account. But with “Hide My Email” that wouldn’t be easily possible, because the customer would have to figure out the privaterelay.appleid.com email address used for their account.
> Furthermore, if there are platforms where AnyList doesn’t support Sign in with Apple, like Android, and someone wants to log into their account, they’d have to know their privaterelay.appleid.com email address. (And that certainly won’t be easy to find if you no longer have an iOS device.) And then they’d have to create a password with us, since they wouldn’t be able to sign in using Sign in with Apple.
> Finally, for a service like AnyList, which is heavily focused on sharing lists with other people, the “Hide My Email” option greatly complicates collaboration. Typically, customers share a list by typing in the email address of the person they want to share with. If that person already has an account, the list is instantly shared. But 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. At that point, you’ll get an email from us asking you to create an account. If you accidentally create a new account, it won’t include the work you’ve done in your existing account created via Sign in with Apple. And if you manage not to make that mistake, then there would be a link between your email address and the account you created with Sign in with Apple, negating the value of hiding your email address.
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 you actually want since the real unstated motivation here is getting the user’s email).
For the third, don’t make me type in someone’s email. The exact same issue as described happens if they have multiple email addresses too. Just let me use my OS’s sharing mechanism to send a special link that they can open to establish the sharing connection. An invite to share, as it were. Not only does that solve the problem, it’s significantly more user-friendly.
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 you actually want since the real unstated motivation here is getting the user’s email).
For the third, don’t make me type in someone’s email. The exact same issue as described happens if they have multiple email addresses too. Just let me use my OS’s sharing mechanism to send a special link that they can open to establish the sharing connection. An invite to share, as it were. Not only does that solve the problem, it’s significantly more user-friendly.
> 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 you actually want since the real unstated motivation here is getting the user’s email).
So the solution here is for a developer to add a bunch of code to their codebase on at least 4 platforms just to get to the same exact functionality and level of privacy, but with a worse user experience?
> For the third, don’t make me type in someone’s email. The exact same issue as described happens if they have multiple email addresses too. Just let me use my OS’s sharing mechanism to send a special link that they can open to establish the sharing connection. An invite to share, as it were. Not only does that solve the problem, it’s significantly more user-friendly.
As a user, I find that functionality to be incredibly clunky by comparison (on all platforms). It may be moderately better on iOS than Android, but even then Anylist and others are running multiplatform apps. If I'm using a computer and I need to manually copy a link, open my email client, compose a new email, type the subject and a message, paste the link, and hit send, that feels dramatically more cumbersome than just entering an email address and hitting "share". It also takes a good amount of new code to implement something like that on an existing system that uses email-based sharing, which I don't think developers should have to deal with just because Apple built a lousy login system.
So the solution here is for a developer to add a bunch of code to their codebase on at least 4 platforms just to get to the same exact functionality and level of privacy, but with a worse user experience?
> For the third, don’t make me type in someone’s email. The exact same issue as described happens if they have multiple email addresses too. Just let me use my OS’s sharing mechanism to send a special link that they can open to establish the sharing connection. An invite to share, as it were. Not only does that solve the problem, it’s significantly more user-friendly.
As a user, I find that functionality to be incredibly clunky by comparison (on all platforms). It may be moderately better on iOS than Android, but even then Anylist and others are running multiplatform apps. If I'm using a computer and I need to manually copy a link, open my email client, compose a new email, type the subject and a message, paste the link, and hit send, that feels dramatically more cumbersome than just entering an email address and hitting "share". It also takes a good amount of new code to implement something like that on an existing system that uses email-based sharing, which I don't think developers should have to deal with just because Apple built a lousy login system.
> So the solution here is for a developer to add a bunch of code to their codebase on at least 4 platforms just to get to the same exact functionality and level of privacy, but with a worse user experience?
You need to support letting the user change their email address anyway. Letting them change it from the privacy forwarding email to something else is no different. And that shouldn’t even interfere with using Sign In With Apple going forward because surely you’re using the user’s unique identifier from Apple to associate the sign-in with your service’s user.
Also FWIW you can use the Sign In With Apple JS approach on non-Apple platforms. This is obviously useful for web, but Apple’s developer site says it’s “for web and apps on other platforms” so you could use this from Android too, it will just take some more work.
> As a user, I find that functionality to be incredibly clunky by comparison (on all platforms).
As a user, I have never connected with someone on a service by typing in their email address. Not only do people routinely have multiple email addresses (e.g. work and personal), but people also often use unique addresses for services (e.g. plus addresses), so it’s not at all a reliable mechanism.
> If I'm using a computer and I need to manually copy a link, open my email client, compose a new email, type the subject and a message, paste the link, and hit send
Why would you do all this? The service can offer a mailto: link that pre-fills the body, so all you have to do is click it, type in the recipient’s email address, and hit Send. And this lets you customize the message as appropriate. Better yet, on Apple platforms you can use the built-in share functionality, including on web with the Web Share API[1].
And if you really don’t want to do all of that, you could have me enter an email that you send a special link to rather than looking up in your user database. That’s still not great for me as a user because it means I’m giving you someone else’s email address, which I don’t want to do, but it’s better than nothing.
The simple fact is, if your sharing mechanism requires me to know the email address someone else has already used to sign up for your service, it’s a crappy sharing mechanism.
[1] https://caniuse.com/#feat=web-share
You need to support letting the user change their email address anyway. Letting them change it from the privacy forwarding email to something else is no different. And that shouldn’t even interfere with using Sign In With Apple going forward because surely you’re using the user’s unique identifier from Apple to associate the sign-in with your service’s user.
Also FWIW you can use the Sign In With Apple JS approach on non-Apple platforms. This is obviously useful for web, but Apple’s developer site says it’s “for web and apps on other platforms” so you could use this from Android too, it will just take some more work.
> As a user, I find that functionality to be incredibly clunky by comparison (on all platforms).
As a user, I have never connected with someone on a service by typing in their email address. Not only do people routinely have multiple email addresses (e.g. work and personal), but people also often use unique addresses for services (e.g. plus addresses), so it’s not at all a reliable mechanism.
> If I'm using a computer and I need to manually copy a link, open my email client, compose a new email, type the subject and a message, paste the link, and hit send
Why would you do all this? The service can offer a mailto: link that pre-fills the body, so all you have to do is click it, type in the recipient’s email address, and hit Send. And this lets you customize the message as appropriate. Better yet, on Apple platforms you can use the built-in share functionality, including on web with the Web Share API[1].
And if you really don’t want to do all of that, you could have me enter an email that you send a special link to rather than looking up in your user database. That’s still not great for me as a user because it means I’m giving you someone else’s email address, which I don’t want to do, but it’s better than nothing.
The simple fact is, if your sharing mechanism requires me to know the email address someone else has already used to sign up for your service, it’s a crappy sharing mechanism.
[1] https://caniuse.com/#feat=web-share
What kind of solution should apple have made then, that would protect user privacy to the same degree?
> 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.
as thomaslord said, this is an enormous overhead, where a lot can go wrong.
> 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 you actually want since the real unstated motivation here is getting the user’s email).
Even more overhead, and more data to manage.
> For the third, don’t make me type in someone’s email. The exact same issue as described happens if they have multiple email addresses too. Just let me use my OS’s sharing mechanism to send a special link that they can open to establish the sharing connection. An invite to share, as it were. Not only does that solve the problem, it’s significantly more user-friendly.
For native only apps, this would also add an additional overhead, as you need to develop a server to handle this.
The point is simple: if you want to protect your email address, that's on you. I personally use a different email address for each service, because it's important for me. But I don't expect everyone will bend over backwards to accommodate me, and neither should you.
as thomaslord said, this is an enormous overhead, where a lot can go wrong.
> 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 you actually want since the real unstated motivation here is getting the user’s email).
Even more overhead, and more data to manage.
> For the third, don’t make me type in someone’s email. The exact same issue as described happens if they have multiple email addresses too. Just let me use my OS’s sharing mechanism to send a special link that they can open to establish the sharing connection. An invite to share, as it were. Not only does that solve the problem, it’s significantly more user-friendly.
For native only apps, this would also add an additional overhead, as you need to develop a server to handle this.
The point is simple: if you want to protect your email address, that's on you. I personally use a different email address for each service, because it's important for me. But I don't expect everyone will bend over backwards to accommodate me, and neither should you.
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.
Because it's your identity. Login systems have moved away from the 'username' concept that we used to use, because it was another thing we could forget. Email addresses are inherently unique and allow identifying a person for support calls or login or whatever.
I'm not saying this is necessarily a good thing, but this is how things work and I don't have a better suggestion.
I'm not saying this is necessarily a good thing, but this is how things work and I don't have a better suggestion.
It used to be true that during a Facebook Connect session the user was asked if they wanted to share their email or not. I faintly remember you could even choose a proxy fb e-mail aka "fake email". Did they remove that feature?
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).
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.
And to answer scarlac's question, yes, they removed this feature a very long time ago.
Ah, thanks for the correction! :)
They don't obfuscate the email address you use with them.
I don't share my "real" email address with Facebook.
My Google account isn't my main account, it's a throwaway I use for things that require email to sign up.
This is a general problem for all OAuth IdPs.
I don't share my "real" email address with Facebook.
My Google account isn't my main account, it's a throwaway I use for things that require email to sign up.
This is a general problem for all OAuth IdPs.
> I don't share my "real" email address with Facebook.
Don't worry, they know it anyway.
Don't worry, they know it anyway.
My gf googled a Mexican restaurant neither of us had been too on her phone and when we got in my truck literally 5 minutes later android auto maps on my phone suggested it as a destination. If they can do this, they can get your other email addresses.
Wait, why? If both of you have your location info turned on then this seems like a trivial correlation to make, especially since both of these are Google's own services.
You don't find this creepy at all? She googles something on her phone. Gets near me, and my phone suggests driving to the location she googled? We aren't on the same account or anything. Google just assumed that I wanted to go where she wanted to go and shared her private searches with me. What if she had gotten in the car and planned parenthood had come up as suggestion?
Esp so since Android Auto is just your phone on your car's screen.
Also other login providers haven't done massively stupid things like not authenticate the actual email address when issuing tokens... like common who in their right mind would want to adopt a new service with a piss poor security reputation for a critical security sensitive leg of their stack?!
Nor do they demand you implement their SSO system if you use any SSO or your app would not be available.
That's a pretty big argument specifically against Apple!
That's a pretty big argument specifically against Apple!
Additionally many other 3rd party login systems have been around much longer than Sign in with Apple, which was another strike against Apple for the author.
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).
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: <blank>
Username: Log in with FB
Password: <blank>
Neat trick. Some websites don't even bother giving you any choice for traditional username/password input though.
It's just a further example of the software / online experience being so...fluctuating as a whole. Which has its pros and cons. Pros being freedom of visual and interactive expression. Cons being lack of expectation.
My router doesn't accept a username at all, which actually makes a bit of sense since there's only one 'account' on it. Unfortunately, this means that neither the browser nor LastPass will save the password. My previous router allowed me to change both the username and the password, then pre-populated the username field with whatever I'd entered (but didn't disable the field), which I always thought was odd...
In that case, I just click the icon for my pw manager (1Password in this case), and the modal shows me the same message.
Some places require no additional info from you.
There are good use cases where third party logins are good enough.
There are good use cases where third party logins are good enough.
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.
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.
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
[1] https://www.facebook.com/settings?tab=applications&ref=setti...
[2] https://myaccount.google.com/security
[deleted]
> 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.
Nope, some of them also apply to Facebook, and Facebook has the additional destruction of privacy concern. They have to remove Facebook or support Apple too because of the policy and have chose neither instead of both.
Some of their concerns specifically don’t apply to Facebook/Google/anything directly tied to your real email that you’d otherwise choose to sign up with. You add a bit of complexity to your database to record different login types, but you can easily reconcile them to an existing user if the emails match, and provide the features they want like searching for a user by email.
Nope, some of them also apply to Facebook, and Facebook has the additional destruction of privacy concern. They have to remove Facebook or support Apple too because of the policy and have chose neither instead of both.
Some of their concerns specifically don’t apply to Facebook/Google/anything directly tied to your real email that you’d otherwise choose to sign up with. You add a bit of complexity to your database to record different login types, but you can easily reconcile them to an existing user if the emails match, and provide the features they want like searching for a user by email.
I cope with this confusion by avoiding third-party login whenever possible. Why volunteer additional information about myself to Google or Facebook?
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.
With a password manager though, I avoid having tradeoffs in the first place. I get some amount of anonymity by separating my accounts, and it's trivial to login to sites with the same amount of clicks as with third party sso.
Registering a new site on PC browser with password manager is fine but on mobile with password manager is bother. It won't register new ID/password automatically.
Chrome on Android is persistently annoying about wanting to save new IDs, and will also try to save logins for apps. That gets turned off fairly quickly, as I use Bitwarden, which _also_ prompts to add new accounts when I sign up or log in.
It's not foolproof, but given I'm generating the password in Bitwarden anyway, it's not the end of the world if it doesn't catch it.
It's not foolproof, but given I'm generating the password in Bitwarden anyway, it's not the end of the world if it doesn't catch it.
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 accounts for the service.
For anything where I'm actually paying, they're a nightmare. Oh, did I sign into this with one of my google accounts? Was I crazy enough to use facebook? Or which of my emails did I use?
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 accounts for the service.
For anything where I'm actually paying, they're a nightmare. Oh, did I sign into this with one of my google accounts? Was I crazy enough to use facebook? Or which of my emails did I use?
I don't have any metrics to back this up, but I would assume most websites that use these third-party login systems, still pull down your email address and create an account for you based on that. So it stands to reason, you if you used the same email for all Facebook, Google, Apple, you could sign in with any of them and maintain one account.
I suppose that's a huge assumption, but that's how I would do it if I was developing against them. That said, it doesn't help w/ the "Hide my Email" or the default icloud.com email addresses people don't realize they're using.
I suppose that's a huge assumption, but that's how I would do it if I was developing against them. That said, it doesn't help w/ the "Hide my Email" or the default icloud.com email addresses people don't realize they're using.
Spotify is a PITA for this. And there is no easy way to migrate to a "non facebook" account your playlists and stuff.
That is why my mom and my grandma use "sign in with facebook".
But if you have a Password Manager, then it is literally a single signon solution in and of itself, without the sacrifice of privacy.
But if you have a Password Manager, then it is literally a single signon solution in and of itself, without the sacrifice of privacy.
Also there are services that log you out after some time. You aren't doing anything wrong, you're simply using the service, but at some point you open it and see a login form. Now, I don't understand why do sessions have to have a lifetime at all, this is terrible UX, but clicking one button to log back in instead of actually typing stuff on the keyboard is much more convenient.
Isn't that what a password manager is for?
I guess a lot of times it’s for security or to minimize storage over time. Sometimes you are only logged in for the browser session, so if you close it, it removes your session. Most smaller sites do have the remember me button to opt in for longer sessions and do not implement a session renew feature.
> Sometimes you are only logged in for the browser session, so if you close it, it removes your session.
Probably, and this shouldn't be a thing. Except maybe for banks, but even then, it's debatable. Here's a handy list of cases when I want to be logged out:
1. I click the log out button.
Which I don't ever do either, because it's my personal device.
Probably, and this shouldn't be a thing. Except maybe for banks, but even then, it's debatable. Here's a handy list of cases when I want to be logged out:
1. I click the log out button.
Which I don't ever do either, because it's my personal device.
I use third party identity providers for all webservices I offer. Not that many because I am not web dev. People love it but I wouldn't use it myself. Of course the identity provider could extract information about the services you use, I wouldn't like that for most platforms to be honest not for the net as a whole.
Account creation sucks, but I prefer it to letting an ID provider know about it. Although I would trust real third party ones like auth0 more than Facebook or Apple, even if they have a more focused business model.
Account creation sucks, but I prefer it to letting an ID provider know about it. Although I would trust real third party ones like auth0 more than Facebook or Apple, even if they have a more focused business model.
I've had services ask me to create a username and password after I "log in with Google". I usually give up at that point.
I think that's the entire point of the parent's (and my as well) position: the so-called convenience of not having to type a few more things to set up an account is not worth giving more data and control to FB/Google/whomever.
They're likely just answering the question you posed... An explanation for _why_
Yes! Especially once you start juggling multiple accounts for different companies and projects. Becomes a guessing game, and each wrong guess creates another account magically. Infuriating
Time to create a new service to unify all your SSO accounts! One single SSO!
OpenID would have done it, but Facebook and Google neutered it in favour of OAuth so they could cement themselves as primary players.
It's been some time last I checked, but isn't OpenID Connect provided anymore by Goog/Fb? Why wouldn't that be a reasonable choice if you wanted a protocol that, from the dev side of things, allowed you to uniformly target external auth providers, or your own?
OoenID Connect is different. Its basically just OAuth2, and google/fb require the ap developer to register their app with google/fb in order to authenticate users.
Whcih is pretty bad for both developers and users, as a user I cant run my own identity provided and as a developer I have to spend time setting up accounts with ever identity provider i wish to integrate.
Original OpenID just let me as a user use a URL as my identity, so I could use any identity provider I wanted, including running one myself.
EDIT: There is a specification for dynamic client registration but nobody implements it as far as I've been able to tell.
Whcih is pretty bad for both developers and users, as a user I cant run my own identity provided and as a developer I have to spend time setting up accounts with ever identity provider i wish to integrate.
Original OpenID just let me as a user use a URL as my identity, so I could use any identity provider I wanted, including running one myself.
EDIT: There is a specification for dynamic client registration but nobody implements it as far as I've been able to tell.
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/
https://en.wikipedia.org/wiki/IndieAuth
https://indieauth.net/
Cool, that looks awesome, thanks!
Yes! and then I just sign in once into my single SSO signon!
And if you create an account accidentally, there’s often no way to undo that.
Next, if you don’t add a second-factor with to it, it becomes a ticking countdown until the account is compromised.
Next, if you don’t add a second-factor with to it, it becomes a ticking countdown until the account is compromised.
> So there's nothing specifically against Apple, despite the title seeming to imply it
From the article...
> In addition to these customer experience problems that are common to all third-party login systems, Sign in with Apple introduces several more that are unique to it.
From the article...
> In addition to these customer experience problems that are common to all third-party login systems, Sign in with Apple introduces several more that are unique to it.
I create dummy logins in my password manager for sites that use external auth. Username of just “LOGIN WITH GOOGLE”. Hacky but it makes me smile every time it gets filled in.
> So there's nothing specifically against Apple
The one thing that is specifically against Apple is the new App Store policy that if an app uses google/Facebook sign in, the app _must_ also use Apple Sign In.
The one thing that is specifically against Apple is the new App Store policy that if an app uses google/Facebook sign in, the app _must_ also use Apple Sign In.
>My password manager is usually pretty good at letting me know if I've got a "normal" account with user/password, but it doesn't do anything to remind me if I ought to log in with one of the other services.
Doesn't it somewhat defeat the purpose of using a password manager if you use one account to sign into multiple sites?
Sign on services from main accounts seem like security flaws. If you use one main account resonsible for all your 'main things' to sign in to all the 'other things' that gives one vector of attack to enter or compromise 'all the things'.
Password managers exist to make the management of many things as easy as one thing, not to adapt to using one thing for everything, that's pretty much the opposite of what a password manager does.
Sign on services don't exist for convenience, despite being marketed that way, they exist to increase data collection abilities. Password managers exist to make using multiple accounts as easy as using a sign on service, that's the point. They should be separate from existing providers. They are an alternative to them.
Doesn't it somewhat defeat the purpose of using a password manager if you use one account to sign into multiple sites?
Sign on services from main accounts seem like security flaws. If you use one main account resonsible for all your 'main things' to sign in to all the 'other things' that gives one vector of attack to enter or compromise 'all the things'.
Password managers exist to make the management of many things as easy as one thing, not to adapt to using one thing for everything, that's pretty much the opposite of what a password manager does.
Sign on services don't exist for convenience, despite being marketed that way, they exist to increase data collection abilities. Password managers exist to make using multiple accounts as easy as using a sign on service, that's the point. They should be separate from existing providers. They are an alternative to them.
First of all, you need a password manager no matter what even if you use Facebook etc., because not everybody supports Facebook etc.
Second, it often still takes a lot of work to create a new account on a site, even with a password manager. Selecting a username, discovering it's taken, selecting another one, generating a random password, pasting it into a second field to confirm the password, unchecking "send me updates", going to my email to find the confirm link, blah blah blah.
If I just want to do something quick on a site (like see a Quora answer or Medium post), it can be far easier to just click "log in with Google" and see the content in 5 seconds rather than 5 minutes while you wait for the damned account confirmation email.
Second, it often still takes a lot of work to create a new account on a site, even with a password manager. Selecting a username, discovering it's taken, selecting another one, generating a random password, pasting it into a second field to confirm the password, unchecking "send me updates", going to my email to find the confirm link, blah blah blah.
If I just want to do something quick on a site (like see a Quora answer or Medium post), it can be far easier to just click "log in with Google" and see the content in 5 seconds rather than 5 minutes while you wait for the damned account confirmation email.
The username dance is why I often use a random string as a username. I was delighted to discover that my first name was an available username at my bank, until my login kept getting locked due to too many failed login attempts. I had a 15-character random password, so no danger there, but repeatedly calling to have my account unlocked was a pain. I changed my username to a different 15-character random string, no problems since.
Tangent: I signed up for a US TD account recently (in person). They had me write down the username I wanted, so I used LastPass on my phone to generate another random username. They obligingly made me an account with username "ajdgsbrjcobsdhfwvfk" - and password "tdbank123". Yes, I was required to change it on first login, but no, there was no attempt to verify that I was the one doing the changing (birthdate, SIN, etc).
Tangent: I signed up for a US TD account recently (in person). They had me write down the username I wanted, so I used LastPass on my phone to generate another random username. They obligingly made me an account with username "ajdgsbrjcobsdhfwvfk" - and password "tdbank123". Yes, I was required to change it on first login, but no, there was no attempt to verify that I was the one doing the changing (birthdate, SIN, etc).
> Doesn't it somewhat defeat the purpose of using a password manager if you use one account to sign into multiple sites?
Yes. Password managers exist to solve the problem of credential reuse; third-party login exists to implement credential reuse. They are fundamentally opposed.
Yes. Password managers exist to solve the problem of credential reuse; third-party login exists to implement credential reuse. They are fundamentally opposed.
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) and that Password Managers are a vastly superior solution to this problem.
But it is worth pointing out that for the layman, using Sign in With Facebook/Apple/Google, is better than single credential re-use.
When I say "layman", I mean people like my mom and grandma. I have tried to get my mom to use a password manager (went as far as to set it up for her, and pay for it) but she just reverts to a simpler solution (which is Social SSO). If she weren't using Social SSO, she would be using her same Facebook password for every site on the internet. So as much as I personally loathe Facebook, I do trust Facebook for securing my Mom's credentials far more than the random scrapbooking website she is creating an account for. In this case, I am grateful that she is using Sign In With Facebook, even though I would never consider such an action for myself. So it is a small step in the right direction.
I still agree that they are variants of the same fundamental problem (a single credential protects all of your logins) and that Password Managers are a vastly superior solution to this problem.
But it is worth pointing out that for the layman, using Sign in With Facebook/Apple/Google, is better than single credential re-use.
When I say "layman", I mean people like my mom and grandma. I have tried to get my mom to use a password manager (went as far as to set it up for her, and pay for it) but she just reverts to a simpler solution (which is Social SSO). If she weren't using Social SSO, she would be using her same Facebook password for every site on the internet. So as much as I personally loathe Facebook, I do trust Facebook for securing my Mom's credentials far more than the random scrapbooking website she is creating an account for. In this case, I am grateful that she is using Sign In With Facebook, even though I would never consider such an action for myself. So it is a small step in the right direction.
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).
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).
Did you actually bother to read the post? The post specifically explains the headaches associated with Apple sign in. In particular -
"Another issue is Sign in with Apple’s “Hide My Email” feature. With this feature, if you create an account with us, Apple will generate a special email address just for that account. So rather than your email address being [email protected], we will see your email address as something like [email protected]. While this is an intriguing idea that provides a measure of privacy, in practice it creates numerous support and user experience headaches..."
"Another issue is Sign in with Apple’s “Hide My Email” feature. With this feature, if you create an account with us, Apple will generate a special email address just for that account. So rather than your email address being [email protected], we will see your email address as something like [email protected]. While this is an intriguing idea that provides a measure of privacy, in practice it creates numerous support and user experience headaches..."
> I've got to say, 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.
Bookwalker (from Japan) draws a big red box around the login you used last on a given device. Presumably they store a cookie/sharedpreferences with it. It doesn't look pretty, but it helps.
Bookwalker (from Japan) draws a big red box around the login you used last on a given device. Presumably they store a cookie/sharedpreferences with it. It doesn't look pretty, but it helps.
That's useful, but on any device of mine I'm usually logged in anyways. What would be really useful is knowing this when I log into a new computer.
This happened to me recently where, in a hurry and distracted, I logged in with one or another third party auth service then realised that wasn’t the correct login as it displayed a new account.
Not all.
1. Apple obfuscate email - this complicates the support system, and as per them Apple hadn't thought about it thoroughly. Collaboration is obstructed. Password recovery is not an easy process. 2. Cross Platform - The post states that Apple vaguely says that sign in on Android is possible, but doesn't state how it is to be done.
1. Apple obfuscate email - this complicates the support system, and as per them Apple hadn't thought about it thoroughly. Collaboration is obstructed. Password recovery is not an easy process. 2. Cross Platform - The post states that Apple vaguely says that sign in on Android is possible, but doesn't state how it is to be done.
>Apple vaguely says that sign in on Android is possible, but doesn't state how it is to be done.
They do?
https://developer.apple.com/documentation/sign_in_with_apple...
They do?
https://developer.apple.com/documentation/sign_in_with_apple...
> all their arguments apply to all third-party sign-ons
What about the argument that users check their gmail addresses regularly but rarely check their icloud email addresses?
What about the argument that users check their gmail addresses regularly but rarely check their icloud email addresses?
> "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.
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.
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.
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...
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...
> 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.
Nope, not all their arguments. Only some.
Nope, not all their arguments. Only some.
This is as close as we got trying to do it from the app itself: https://www.lukew.com/ff/entry.asp?1906
I absolutely agree that password managers could remember this stuff. Single-signon is pretty easy to identify and you could setup the relationship.
I absolutely agree that password managers could remember this stuff. Single-signon is pretty easy to identify and you could setup the relationship.
As I would liked your approach in other times, wouldn't it be a bad one in today"s privacy matters/GDPR and being able to enumerate your database?
Paperspace has this with their Google integration. And I've implemented this pattern before in web dev.
You return to the site and if you have logged in with social media site before, and it detected you are still logged in, it will auto login for you.
You return to the site and if you have logged in with social media site before, and it detected you are still logged in, it will auto login for you.
I worked on a product that can do that (Google Smartlock for Passwords) but these “identity provider” hints were extremely confusing to both users and developers. The UX definitely could have been better but overall I just don’t think it works.
[deleted]
I don't support social login anymore. It's better for the customer.
> 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.
That section of the post was surprising. If they're not supporting Sign in with Apple, then obviously they're going to remove support for all other third-party sign-ons, because those third-party sign-ons are what trigger the obligation to support Sign in with Apple.
Ending their post about "why we won't be supporting Sign in with Apple" with a note that they're also ending Sign in with Facebook on the merits of third-party sign-in is quite disingenuous. It doesn't matter at all what they think about the merits of Sign in with Facebook; those thoughts are completely irrelevant to their decision.
That section of the post was surprising. If they're not supporting Sign in with Apple, then obviously they're going to remove support for all other third-party sign-ons, because those third-party sign-ons are what trigger the obligation to support Sign in with Apple.
Ending their post about "why we won't be supporting Sign in with Apple" with a note that they're also ending Sign in with Facebook on the merits of third-party sign-in is quite disingenuous. It doesn't matter at all what they think about the merits of Sign in with Facebook; those thoughts are completely irrelevant to their decision.
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 address, our systems will believe that you don’t have an account
Since you know this to be the case, why not have an onboard if flow they Sign In with Apple where you have them A) choose a visibility email used for sharing/communication etc. and B) allow for this email to be their backup email? So if they forget their login or whatever you could just transfer the account to this email instead? Of course this should be opt-in but you can always Under good faith explain benefits there in.
It’s more work, but I don’t believe that it’s going to run issue with Apple and provides end users with flexibility.
Of course this may not be worth it, at all. This is just a consideration worth thinking about as an app developer
edit: Of course another alternative here is they just make users aware of what their sharing email is and allow users to optionally change that, if they want to. This most definitely wouldn’t run counter to this I’d think
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 address, our systems will believe that you don’t have an account
Since you know this to be the case, why not have an onboard if flow they Sign In with Apple where you have them A) choose a visibility email used for sharing/communication etc. and B) allow for this email to be their backup email? So if they forget their login or whatever you could just transfer the account to this email instead? Of course this should be opt-in but you can always Under good faith explain benefits there in.
It’s more work, but I don’t believe that it’s going to run issue with Apple and provides end users with flexibility.
Of course this may not be worth it, at all. This is just a consideration worth thinking about as an app developer
edit: Of course another alternative here is they just make users aware of what their sharing email is and allow users to optionally change that, if they want to. This most definitely wouldn’t run counter to this I’d think
> Since you know this to be the case, why not have an onboard if flow they Sign In with Apple where you have them A) choose a visibility email used for sharing/communication etc. and B) allow for this email to be their backup email? So if they forget their login or whatever you could just transfer the account to this email instead?
I'm fairly certain that detecting someone hiding their e-mail from you and then making them pick a different e-mail goes against the spirit, if not the rules, of Sign In with Apple.
That said, it would be extremely beneficial to pop up a screen saying "Hey, is this the e-mail you want to use for communications?" and let the user decide.
That said, removing third-party sign-in is also a fine solution, almost definitely a better one, and simplifies things immensely for everyone involved (assuming their sign-in form in the app supports saving passwords to the keychain).
I'm fairly certain that detecting someone hiding their e-mail from you and then making them pick a different e-mail goes against the spirit, if not the rules, of Sign In with Apple.
That said, it would be extremely beneficial to pop up a screen saying "Hey, is this the e-mail you want to use for communications?" and let the user decide.
That said, removing third-party sign-in is also a fine solution, almost definitely a better one, and simplifies things immensely for everyone involved (assuming their sign-in form in the app supports saving passwords to the keychain).
> making them pick a different e-mail
I think it's more about _letting_ them pick a different email. While I can understand that AnyList (or any other app for that matter) would want to, on occasion, send marketing emails to users, I don't think any app would, in their right mind, _require_ the user to provide a 2nd email address.
But by allowing them to optionally give that 2nd address, they can provide a path forwards with people being able to use Sign In With Apple (of course, that means some users may opt out of marketing emails entirely by refusing to provide a 2nd address).
This does probably go against the spirit of the feature, but if it actually is against Apple's rules to be doing this (anyone know the answer to this?), then it would definitely veer on the side of user hostility on Apple's part, since I would expect many apps to be taking a stance similar to the one taken by AnyList here.
I think it's more about _letting_ them pick a different email. While I can understand that AnyList (or any other app for that matter) would want to, on occasion, send marketing emails to users, I don't think any app would, in their right mind, _require_ the user to provide a 2nd email address.
But by allowing them to optionally give that 2nd address, they can provide a path forwards with people being able to use Sign In With Apple (of course, that means some users may opt out of marketing emails entirely by refusing to provide a 2nd address).
This does probably go against the spirit of the feature, but if it actually is against Apple's rules to be doing this (anyone know the answer to this?), then it would definitely veer on the side of user hostility on Apple's part, since I would expect many apps to be taking a stance similar to the one taken by AnyList here.
So someone explicitly chose to hide their email, and then on logging into an app is asked to share their real email.
Anyone in that position would think the app is shady AF and user hostile.
Anyone in that position would think the app is shady AF and user hostile.
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 time and I trust it more now) and/or greater context for why the app is interested in a more direct email address ("make collaboration easier").
It's not necessarily shady or user hostile when done right, and there are plenty of opportunity to add trust relationship building as a part of the consent process (links to privacy policies; details about marketing policies; etc).
It's also not that different from how many iOS applications (at least) are encouraged (in App Store best practices) to handle consent models for location tracking and notifications: ask the user as they become familiar with the application, not up front, and provide as much context as you can.
It's not necessarily shady or user hostile when done right, and there are plenty of opportunity to add trust relationship building as a part of the consent process (links to privacy policies; details about marketing policies; etc).
It's also not that different from how many iOS applications (at least) are encouraged (in App Store best practices) to handle consent models for location tracking and notifications: ask the user as they become familiar with the application, not up front, and provide as much context as you can.
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 its features, I'll be significantly happier.
That said though, I don't see why the app couldnt just change their sharing model to an "invite link" based pattern. If I want to share something with a friend, why do I need to provide their private information to the app to do it? Why can't I generate an invite link and send that through my already established channels of communication? I don't think the "but your friends don't know your Apple privacy email" reason is very compelling. That might not work in their current system, but it is definitely not an insurmountable problem.
That said though, I don't see why the app couldnt just change their sharing model to an "invite link" based pattern. If I want to share something with a friend, why do I need to provide their private information to the app to do it? Why can't I generate an invite link and send that through my already established channels of communication? I don't think the "but your friends don't know your Apple privacy email" reason is very compelling. That might not work in their current system, but it is definitely not an insurmountable problem.
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.)
(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.)
While I can understand that AnyList (or any other app for that matter) would want to, on occasion, send marketing emails to users
I am not an AnyList user but do they ask when signing up if users would like to opt in to such marketing messages? It’s become such a pet peeve buying something from an online purveyor and not even having the choice to opt in or not on marketing emails and any other form of communication I did not explicitly ask for beyond completing a purchase.
seems like another reason for progressive consent and ASKING your users how they would like to be contacted and honoring those preferences
I am not an AnyList user but do they ask when signing up if users would like to opt in to such marketing messages? It’s become such a pet peeve buying something from an online purveyor and not even having the choice to opt in or not on marketing emails and any other form of communication I did not explicitly ask for beyond completing a purchase.
seems like another reason for progressive consent and ASKING your users how they would like to be contacted and honoring those preferences
For this use case there is no need to collect real email address. The obfuscated email that apple provides can be used to send emails to the user.
You don't have to ask for the email at all, if you don't want to. Pinterest apparently does not, so for them SIWA is just an authenticator.
In a perfect world people would share things with you without entering your private email address in other people's systems. I don't want to be in the database of whatever app or system my friends decided to join, nor I want to receive spam from these companies.
Many of the objections come from wanting to do things the old way, without privacy and responsible handling of private data.
Many of the objections come from wanting to do things the old way, without privacy and responsible handling of private data.
> Many of the objections come from wanting to do things the old way, without privacy and responsible handling of private data.
No, they come from the fact that privacy comes at a cost. In this case, it's much harder to receive support, find your account if you lose it, and get proper communication. Everything is a trade off, and anyone who thinks the reason things have been done this way is only to scoop up as much data as possible is either brainwashed or naive. These changes are adding a whole new layer of complexity, which may be worth it in some cases, but in others it just is a net negative for the customer.
No, they come from the fact that privacy comes at a cost. In this case, it's much harder to receive support, find your account if you lose it, and get proper communication. Everything is a trade off, and anyone who thinks the reason things have been done this way is only to scoop up as much data as possible is either brainwashed or naive. These changes are adding a whole new layer of complexity, which may be worth it in some cases, but in others it just is a net negative for the customer.
Can you elaborate on "private email address"? I'd be offended if someone were careless with a more intimate identifier like my personal cell phone number, but I've always considered arms-length interactions with businesses and institutions I'm not fully on board with to be the whole point of email.
I have a private email address and a catch all address for a variety of websites.
{app_name}@example.com goes to the same place, but it is easy for me to see if they sell/lose my email. And if it gets lost I'm done with them I can just block that specific address.
The added benefit is no one can assume that {my_name}@example.com is my bank email address or my email login.
I used to have a standard {username}@gmail.com for a while, but now it is on 20+ breached site lists. Best case? Copious amounts of spam. Worst case? I may have been reusing a password prior to switching to a password manager.
Now, I can just block the email from receiving anything. Two, if I accidentally reuse a password the username is at least different.
{app_name}@example.com goes to the same place, but it is easy for me to see if they sell/lose my email. And if it gets lost I'm done with them I can just block that specific address.
The added benefit is no one can assume that {my_name}@example.com is my bank email address or my email login.
I used to have a standard {username}@gmail.com for a while, but now it is on 20+ breached site lists. Best case? Copious amounts of spam. Worst case? I may have been reusing a password prior to switching to a password manager.
Now, I can just block the email from receiving anything. Two, if I accidentally reuse a password the username is at least different.
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 the user with coming up with silly names and codes to use social like features that require someone else knowing an identifier for you that isn't email.
I don't want to go back to a time where we have to remember / pass along everyone's ICQ number. ...
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 the user with coming up with silly names and codes to use social like features that require someone else knowing an identifier for you that isn't email.
I don't want to go back to a time where we have to remember / pass along everyone's ICQ number. ...
I think it would come down to user hostility here.
If I sign in with Apple and opt out of giving my email only to be faced with a prompt demanding I give up my email address, I'll be upset. I JUST told the app (via checking the box in Apple) that I don't want to give my mail, so why is it now suddenly required?
However if the app allows me to sign in and only asks for my email when I try to interact with a feature that would be more usable had I given my email, then I would be more accepting of it. Though I would still fully expect to be able to use the app in its entirety even if I opt out.
Now what Apple will say to this, I have no idea. But as a privacy conscious user, I would be happier with this.
As for having to come up with silly names, I don't understand why I need to be discoverable within an app. We have established social media and communication platforms, use them. Let me send a link to a friend to connect with them in your random app. I don't need to be able to add them within the dang app.
If I sign in with Apple and opt out of giving my email only to be faced with a prompt demanding I give up my email address, I'll be upset. I JUST told the app (via checking the box in Apple) that I don't want to give my mail, so why is it now suddenly required?
However if the app allows me to sign in and only asks for my email when I try to interact with a feature that would be more usable had I given my email, then I would be more accepting of it. Though I would still fully expect to be able to use the app in its entirety even if I opt out.
Now what Apple will say to this, I have no idea. But as a privacy conscious user, I would be happier with this.
As for having to come up with silly names, I don't understand why I need to be discoverable within an app. We have established social media and communication platforms, use them. Let me send a link to a friend to connect with them in your random app. I don't need to be able to add them within the dang app.
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 account or not. If there's something special about an app that requires an account before interaction is possible, then you can still make it a one-time share.
Yes, it does make user support more complicated. Yes, that's what I want and expect. I hope when I come asking for help, you can't help me because you have no clue who I am and have no way to get in touch with me because I used some email obscuring service. That's on me.
"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 account or not. If there's something special about an app that requires an account before interaction is possible, then you can still make it a one-time share.
Yes, it does make user support more complicated. Yes, that's what I want and expect. I hope when I come asking for help, you can't help me because you have no clue who I am and have no way to get in touch with me because I used some email obscuring service. That's on me.
I get your use case.
But in this case the company is someone who claims to be "The best way to create and share a grocery shopping list and organize your recipes."
Sharing is part of the deal with them and a sign in process that from the start complicates it is understandably a no go / introduces all sorts of complications that they detail in the article.
But in this case the company is someone who claims to be "The best way to create and share a grocery shopping list and organize your recipes."
Sharing is part of the deal with them and a sign in process that from the start complicates it is understandably a no go / introduces all sorts of complications that they detail in the article.
I get that sharing is a core thing for this app. I just don't think sharing should have anything to do with my identity. It can be a hash that is shared across any communications platform (even by meat-space, vocally!).
If the goal for the app is for itself to be a tool for identity management, then knowing my email is especially not needed...after all, all identity context is already in the app!
UX should center around ease of sharing some hash value across some other medium, not "searching by identity."
I do honestly empathize with the app creators. But anybody choosing an obscuring email by definition does not want to be identified by email.
If the goal for the app is for itself to be a tool for identity management, then knowing my email is especially not needed...after all, all identity context is already in the app!
UX should center around ease of sharing some hash value across some other medium, not "searching by identity."
I do honestly empathize with the app creators. But anybody choosing an obscuring email by definition does not want to be identified by email.
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.
I don't think Apple would care about asking for email for legitimate use. I thought the point of Sign in with Apple is that it decouples giving away your email from signing up. Not that it bans apps from collecting emails in any way.
I hope so.
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
That ship sailed long ago. Apple basically has apps and app-developers by the balls, not to mention the 30% extortion money they try to get not just for app purchases but any transaction done within the app, so much as even banning an app from telling the user that they can do the transaction elsewhere.
It makes my blood boil but from the discussions I see on HN about it, most people here seem to be more or less ok with it.
It makes my blood boil but from the discussions I see on HN about it, most people here seem to be more or less ok with it.
It’s not any transaction. It’s any digital transaction. You can sell physical goods and services either without giving Apple any cut, or by using Apple Pay and Apple just gets your standard credit card processing fee.
Does Walmart let you sell your product in their store and say you can look at it there but get it cheaper from Amazon?
Does Walmart let you sell your product in their store and say you can look at it there but get it cheaper from Amazon?
My app is not the App Store. The user has already paid to download my app from the App Store and Apple has gotten 30% of the cut. What users do on my App after that is none of Apple's business, though of course Apple would like to claim otherwise.
Similarly, once I have bought something from Walmart I can use it as I wish. Our business transaction ends there, so your analogy isn't really apt.
> Does Walmart let you sell your product in their store and say you can look at it there but get it cheaper from Amazon?
Funny you say that, because Walmart and many other brick-and-mortal retailers will happily price-match Amazon and each other. You know why? Because they are not a monopoly or pseudo-monopoly and so need to do good by their users to compete.
Of course you can justify Apple's behavior any way because you can claim that I am on an iPhone so I am on their property or something and so they are my overlords but that is precisely what users here are trying to argue against.
Or to be honest, you don't even need to justify it that way. The magical market justifies it because the fact that these apps are on the Apple ecosystem means that staying on it is better for them than staying off it. And no other justification is necessary. And you would not be wrong.
But people have a moral intuition about these things based on how they see the world work, and so they have an intuitive sense for when something seems 'off', even if the market seems like it's working. That's why they complain against things like exorbitant pay-day loans despite them too being an example of a market that seems to be working.
Last I checked, I did not get an iPhone on lease from Apple. This attitude where just because I am on an iPhone means I owe Apple in perpetuity needs to die.
Similarly, once I have bought something from Walmart I can use it as I wish. Our business transaction ends there, so your analogy isn't really apt.
> Does Walmart let you sell your product in their store and say you can look at it there but get it cheaper from Amazon?
Funny you say that, because Walmart and many other brick-and-mortal retailers will happily price-match Amazon and each other. You know why? Because they are not a monopoly or pseudo-monopoly and so need to do good by their users to compete.
Of course you can justify Apple's behavior any way because you can claim that I am on an iPhone so I am on their property or something and so they are my overlords but that is precisely what users here are trying to argue against.
Or to be honest, you don't even need to justify it that way. The magical market justifies it because the fact that these apps are on the Apple ecosystem means that staying on it is better for them than staying off it. And no other justification is necessary. And you would not be wrong.
But people have a moral intuition about these things based on how they see the world work, and so they have an intuitive sense for when something seems 'off', even if the market seems like it's working. That's why they complain against things like exorbitant pay-day loans despite them too being an example of a market that seems to be working.
Last I checked, I did not get an iPhone on lease from Apple. This attitude where just because I am on an iPhone means I owe Apple in perpetuity needs to die.
> My app is not the App Store. The user has already paid to download my app from the App Store and Apple has gotten 30% of the cut. What users do on my App after that is none of Apple's business, though of course Apple would like to claim otherwise.
It seems like you are the one who would like to claim otherwise, since to get your app in the store you have already agreed both to the terms of the developer program and to follow Apple's guidelines.
It seems like you are the one who would like to claim otherwise, since to get your app in the store you have already agreed both to the terms of the developer program and to follow Apple's guidelines.
Not agreeing with what are arbitrary rules on the App Store and with the percentage that Apple takes as a cut, but this paragraph opens up many issues with running a platform:
> The user has already paid to download my app from the App Store and Apple has gotten 30% of the cut. What users do on my App after that is none of Apple's business, though of course Apple would like to claim otherwise.
If the App Store runs the way you describe, then everybody would offer their apps for free to avoid the 30% cut and also not have any in-app purchases (since those also have a cut). The result would be the user installing the app and having to go to a website (even if it’s embedded in the app in a web view) to create yet another account, finish the signup process, go through a separate (and usually lengthy) payment process to actually buy the app and managing those payments in cases where those are subscriptions.
One can argue on the merits and demerits of Apple’s current system (which needs an overhaul, IMO), but the other option isn’t without demerits as far as users and user experience are concerned.
> The user has already paid to download my app from the App Store and Apple has gotten 30% of the cut. What users do on my App after that is none of Apple's business, though of course Apple would like to claim otherwise.
If the App Store runs the way you describe, then everybody would offer their apps for free to avoid the 30% cut and also not have any in-app purchases (since those also have a cut). The result would be the user installing the app and having to go to a website (even if it’s embedded in the app in a web view) to create yet another account, finish the signup process, go through a separate (and usually lengthy) payment process to actually buy the app and managing those payments in cases where those are subscriptions.
One can argue on the merits and demerits of Apple’s current system (which needs an overhaul, IMO), but the other option isn’t without demerits as far as users and user experience are concerned.
> once I have bought something from Walmart I can use it as I wish.
Not if it's a movie, music, or video game. I.e. anything with digital content.
Not if it's a movie, music, or video game. I.e. anything with digital content.
Providers of digital content seem to be absolutely all over the place with this stuff
Comcast of all people offers the ability to buy movies on demand. Not just rent but outright purchase. If you leave Comcast as a customer, you can have every purchase mailed to you as either a DVD (SD) or Blu Ray (HD) purchase
Steam has provisions in place that if its service ever gets terminated to allow users to continue to use games they've purchased on the platform. They also allow users to continue to download and play games either removed from the store or no longer sold (Alan Wake and Deadpool being two examples in my own library)
Conversely Microsoft's Xbox will de-list titles and make them excruciatingly hard to download, such as Marble Blast Ultra. Requiring you to find the game in your account history and then use that to navigate to a download page
Sony's Playstation is downright malicious with their digital store. Konami's "P.T" was offered as a free download as a teaser for an upcoming Silent Hill game
Once Konami changed their mind however, the game was not only removed from the store but actively wiped from the users console! If you connected to Playstation Network the game would be forcefully deleted from your device
Comcast of all people offers the ability to buy movies on demand. Not just rent but outright purchase. If you leave Comcast as a customer, you can have every purchase mailed to you as either a DVD (SD) or Blu Ray (HD) purchase
Steam has provisions in place that if its service ever gets terminated to allow users to continue to use games they've purchased on the platform. They also allow users to continue to download and play games either removed from the store or no longer sold (Alan Wake and Deadpool being two examples in my own library)
Conversely Microsoft's Xbox will de-list titles and make them excruciatingly hard to download, such as Marble Blast Ultra. Requiring you to find the game in your account history and then use that to navigate to a download page
Sony's Playstation is downright malicious with their digital store. Konami's "P.T" was offered as a free download as a teaser for an upcoming Silent Hill game
Once Konami changed their mind however, the game was not only removed from the store but actively wiped from the users console! If you connected to Playstation Network the game would be forcefully deleted from your device
You don’t own any of these things, you own a license to the content and the physical disc.
It’s completely different to owning something.
Steams provisions are helpful in practice but ultimately meaningless because you don’t own any of the actual games, you merely have a license to run the code under their terms.
It’s completely different to owning something.
Steams provisions are helpful in practice but ultimately meaningless because you don’t own any of the actual games, you merely have a license to run the code under their terms.
Funny you say that, because Walmart and many other brick-and-mortal retailers will happily price-match Amazon and each other. You know why? Because they are not a monopoly or pseudo-monopoly and so need to do good by their users to compete.
Many stores get around that by having special SKUs that are only available in their store.
Also, Android has a slightly larger share in the US and a much larger share worldwide. Apple is no more of a “monopoly” than the console makers.
Many stores get around that by having special SKUs that are only available in their store.
Also, Android has a slightly larger share in the US and a much larger share worldwide. Apple is no more of a “monopoly” than the console makers.
Actually, you're free to add "check out our online store" in the packaging of the product sold at Walmart or Amazon.
So Apple is being extra controlling here. They consider all Apple users property of Apple, so they take a cut off all digital transactions.
So Apple is being extra controlling here. They consider all Apple users property of Apple, so they take a cut off all digital transactions.
I have never seen a product at Walmart advertising that you should buy the product online at another retailer to avoid the “Walmart tax”.
It hasn't sailed yet. We'll have to see what comes out of the antitrust litigations in the EU and, if I'm not mistaken, also in the US.
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.
Apple isn't forcing anything here.
> 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).
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).
Do you know if this is allowed within the scope of Sign In with Apple policies? A company I work with is implementing Sign In with Apple and said they can't do this. Not sure if they're right or if this is their weird interpretation.
I couldn’t find anything in an admittedly shallow search of the requirements or documentation.
Of course another alternative here is they just make users aware of what their sharing email is and allow users to optionally change that, if they want to.
I think their perfectly valid to do what they’re doing but I also don’t buy into this being an overly complicated logistical hurdle either
Of course another alternative here is they just make users aware of what their sharing email is and allow users to optionally change that, if they want to.
I think their perfectly valid to do what they’re doing but I also don’t buy into this being an overly complicated logistical hurdle either
Having a user name solve this. Github collaboration works the same way.
> Furthermore, if there are platforms where AnyList doesn’t support Sign in with Apple, like Android, and someone wants to log into their account, they’d have to know their privaterelay.appleid.com email address. (And that certainly won’t be easy to find if you no longer have an iOS device.) And then they’d have to create a password with us, since they wouldn’t be able to sign in using Sign in with Apple.
The easy answer is: they should just support "Sign in with Apple" on every platform. (That absolutely works. Sign in with Apple is a [mostly] standard OpenID Connect provider and has a web frontend that should work on every non-Apple platform just fine, just like FB/Google/etc.)
You wouldn't think to only support "Sign in with Google" only on Android devices? Maybe "Sign in with Facebook" should only apply to web browsers?
It's an interesting misconception or miscommunication that so many developers think "Sign in with Apple" should only show up on Apple devices.
The easy answer is: they should just support "Sign in with Apple" on every platform. (That absolutely works. Sign in with Apple is a [mostly] standard OpenID Connect provider and has a web frontend that should work on every non-Apple platform just fine, just like FB/Google/etc.)
You wouldn't think to only support "Sign in with Google" only on Android devices? Maybe "Sign in with Facebook" should only apply to web browsers?
It's an interesting misconception or miscommunication that so many developers think "Sign in with Apple" should only show up on Apple devices.
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 support for a major platform that these multi-platform apps run on is not acceptable."
"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 support for a major platform that these multi-platform apps run on is not acceptable."
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 other such standards, except with the option to mask your email, etc.
As an geeky end user, the only way I trust these services for login is if I can link more than one, or even more than one email from the same provider. That way I know I’ll have a backup in case I lose access to the social network or email address that I signed in with... it’s annoying when I can’t add a password or set an email just because I also want to login without a password sometimes...
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 other such standards, except with the option to mask your email, etc.
As an geeky end user, the only way I trust these services for login is if I can link more than one, or even more than one email from the same provider. That way I know I’ll have a backup in case I lose access to the social network or email address that I signed in with... it’s annoying when I can’t add a password or set an email just because I also want to login without a password sometimes...
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.
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.
Wow you're not kidding that's actually surprisingly clear documentation and it should be very easy to implement.
Apple has provided documentation, it seems like the article describes a lack of attempt at trying?
On the Getting Started [1] page it lists three options: Apple platforms [use AuthenticationServices], Unity [use the asset from the Unity Asset Store], and "Web and Other Platforms" [use Apple JS/REST]. That "Web and Other Platforms" link provides a wealth of useful documentation [2].
Tbf, the exact word "Android" is missing, but this is an elementary school-level process of elimination that maybe Android is inferred in the words "other platforms".
[1] https://developer.apple.com/sign-in-with-apple/get-started/
[2] https://developer.apple.com/documentation/sign_in_with_apple...
On the Getting Started [1] page it lists three options: Apple platforms [use AuthenticationServices], Unity [use the asset from the Unity Asset Store], and "Web and Other Platforms" [use Apple JS/REST]. That "Web and Other Platforms" link provides a wealth of useful documentation [2].
Tbf, the exact word "Android" is missing, but this is an elementary school-level process of elimination that maybe Android is inferred in the words "other platforms".
[1] https://developer.apple.com/sign-in-with-apple/get-started/
[2] https://developer.apple.com/documentation/sign_in_with_apple...
Also, even if they support it, it does not look like Apple has released an app or SDK for Android.
So there would be no apple account registered on the phone.
So each app wanting to implement apple login would have to :
- pretty much implement it from scratch
- still have a very subpar experience compared to any other login mechanism (even way worse than email + password) since they would have to ask users to find their obfuscated apple email address.
So there would be no apple account registered on the phone.
So each app wanting to implement apple login would have to :
- pretty much implement it from scratch
- still have a very subpar experience compared to any other login mechanism (even way worse than email + password) since they would have to ask users to find their obfuscated apple email address.
Sign in with Apple asks for your normal iCloud email address. It's Apple's servers that look up your app-specific obfuscated relay email address if you've used one for the app.
duh ! I blame my sleepiness for missing that.
Still pretty meh that it is the only solution of its kind without an sdk
Still pretty meh that it is the only solution of its kind without an sdk
They don’t need an SDK if they’re using protocol-compliant OpenID Connect.
Any OpenID Connect (or OAUTH2) library of the devs choice is the SDK.
The Facebook/google SDKs are simply there to add trackers and bloat.
Any OpenID Connect (or OAUTH2) library of the devs choice is the SDK.
The Facebook/google SDKs are simply there to add trackers and bloat.
A good sdk means that it is both quick to implement and that it can integrate with the OS account feature (meaning users only have to authentify once for their apple account)
They directly address this point. In the article they say they considered adding sign in with Apple everywhere. Besides the fact that it's more code to write and test, they say the documentation is very poor for other platforms, as it's not even great for iOS.
It seems sufficient to me?
https://developer.apple.com/documentation/sign_in_with_apple...
https://developer.apple.com/documentation/sign_in_with_apple...
Absolutely not. Compare the native ios documentation[1] with their "other platforms" documentation[2]. Their native documentation has code snippets, helpful links, and explains in depth what is happening.
The "other platforms" documentation is "make this request, store some data, follow redirects". No code, no helpful links on how you might accomplish these things, nothing. You get the bare minimum.
I'm not saying its impossible, and neither is the article. I'm saying that Apple clearly doesn't care about supporting a platform as huge as Android, and that clearly signals to multi-platform developers that they are on their own.
[1] https://developer.apple.com/documentation/authenticationserv...
[2] https://developer.apple.com/documentation/sign_in_with_apple...
The "other platforms" documentation is "make this request, store some data, follow redirects". No code, no helpful links on how you might accomplish these things, nothing. You get the bare minimum.
I'm not saying its impossible, and neither is the article. I'm saying that Apple clearly doesn't care about supporting a platform as huge as Android, and that clearly signals to multi-platform developers that they are on their own.
[1] https://developer.apple.com/documentation/authenticationserv...
[2] https://developer.apple.com/documentation/sign_in_with_apple...
The nature of "other" platforms means that example code could be in any language at all.
The fact that their iOS documentation is so much better than average doesn't mean their "other platforms" documentation is inadequate. It just means there's plenty of room for third parties like indie bloggers to documentation their own approaches in JavaScript, Python, Ruby, Rust, or whatever.
The fact that their iOS documentation is so much better than average doesn't mean their "other platforms" documentation is inadequate. It just means there's plenty of room for third parties like indie bloggers to documentation their own approaches in JavaScript, Python, Ruby, Rust, or whatever.
I think you're missing the point.
Part of the problem is that android is an "other platform" in the first place. Sign in with apple is supposed to be a cross platform feature, but Apple can't be bothered to even write out some decent documentation for a platform with over 2 billion devices. Compare, for example, the Google sign in for iOS[1]. They provide a working example project and full documentation.
If you are a developer supporting a cross platform app, you're not getting much help from Apple. That's what the article is saying: integrating this feature is going to be more work and more risk than it's worth. That's the point.
> It just means there's plenty of room for third parties like indie bloggers to documentation their own approaches in JavaScript, Python, Ruby, Rust, or whatever.
We are talking about signing in. This is one of the most fundamental features you need to have. This is not something that you just copy paste from some half baked blog post. It is amazing to me you think that's acceptable.
[1] https://developers.google.com/identity/sign-in/ios/start
Part of the problem is that android is an "other platform" in the first place. Sign in with apple is supposed to be a cross platform feature, but Apple can't be bothered to even write out some decent documentation for a platform with over 2 billion devices. Compare, for example, the Google sign in for iOS[1]. They provide a working example project and full documentation.
If you are a developer supporting a cross platform app, you're not getting much help from Apple. That's what the article is saying: integrating this feature is going to be more work and more risk than it's worth. That's the point.
> It just means there's plenty of room for third parties like indie bloggers to documentation their own approaches in JavaScript, Python, Ruby, Rust, or whatever.
We are talking about signing in. This is one of the most fundamental features you need to have. This is not something that you just copy paste from some half baked blog post. It is amazing to me you think that's acceptable.
[1] https://developers.google.com/identity/sign-in/ios/start
> This is not something that you just copy paste from some half baked blog post. It is amazing to me you think that's acceptable.
Have you ever actually implemented a proper sign-in process e.g. with OIDC, JWT, SSO etc ?
Because half baked blog posts is the industry standard.
Have you ever actually implemented a proper sign-in process e.g. with OIDC, JWT, SSO etc ?
Because half baked blog posts is the industry standard.
Hardly a surprise that they're so crap, then.
Not surprised the documentation that highlights the Apple Platform is better, however, give.
That said, it’s a REST API you query and you get a well defined payload:
> A successful response contains the following parameters: code A single-use authorization code that is valid for five minutes. id_token A JSON web token containing the user’s identity information. state The state contained in the Authorize URL. user A JSON string containing the data requested in the scope property. The returned data is in the following format: { "name": { "firstName": string, "lastName": string }, "email": string }
I could implement this using curl really it’s that straightforward. If you have any experience consuming REST APIs
That said, it’s a REST API you query and you get a well defined payload:
> A successful response contains the following parameters: code A single-use authorization code that is valid for five minutes. id_token A JSON web token containing the user’s identity information. state The state contained in the Authorize URL. user A JSON string containing the data requested in the scope property. The returned data is in the following format: { "name": { "firstName": string, "lastName": string }, "email": string }
I could implement this using curl really it’s that straightforward. If you have any experience consuming REST APIs
To repeat myself, I know that this is more than possible to implement. But you're also hiding a lot of complexity about redirecting from your app to a browser, managing state, custom url schemes, etc. If you want to turn your curl request into an actual app, there's some nontrivial code you have to write and test yourself. And this code is important - if a user can't sign in, your entire app is broken.
And to what benefit? This is the point of the article. Sign in for apple is extra work and extra complexity for no benefit (to the developer, at least). It's an immature project and the fact that Apple is putting in the bare minimum effort into the docs does not encourage me to adopt this feature.
Google, in comparison, has a working sample project and step by step guide for implementing Google sign in on iOS[1]. Google sign in is just as much a "curl request" as apple sign in, but they put in the effort to give a high quality, well integrated, and native example.
Apple can't be bothered, which discourages people like OP from adopting the feature.
[1] https://developers.google.com/identity/sign-in/ios/start
And to what benefit? This is the point of the article. Sign in for apple is extra work and extra complexity for no benefit (to the developer, at least). It's an immature project and the fact that Apple is putting in the bare minimum effort into the docs does not encourage me to adopt this feature.
Google, in comparison, has a working sample project and step by step guide for implementing Google sign in on iOS[1]. Google sign in is just as much a "curl request" as apple sign in, but they put in the effort to give a high quality, well integrated, and native example.
Apple can't be bothered, which discourages people like OP from adopting the feature.
[1] https://developers.google.com/identity/sign-in/ios/start
And even with that - they are not going to use Google.
Even though there is way more value in supporting Google, than Apple. Google SSO is widely used in small businesses, unlike Apple ID.
Even though there is way more value in supporting Google, than Apple. Google SSO is widely used in small businesses, unlike Apple ID.
I agree in principal, but in practice this isn't as easy as one would hope. Each IdP has slightly different requirements and parameters for connecting clients. There may be significant code non-overlap across providers, not to mention across platforms.
Facebook, for instance, doesn't actually implement OpenID Connect, but has a custom layer on top of OAuth. Their recommended method of connecting is a client SDK for each platform.
Facebook, for instance, doesn't actually implement OpenID Connect, but has a custom layer on top of OAuth. Their recommended method of connecting is a client SDK for each platform.
That’s what I was thinking as well. Why not just treat it like any other OpenID provider and show it for all platforms?
Heck, I've been happily using "Sign in with Apple" on linux anywhere I can.
> Apple reserves the right to disable Sign in with Apple on a website or app for any reason at any time.
Holy cow, how is this acceptable to any app developer or software company? This is reason enough for me to never use Apple/Facebook/Google sign-on as a developer -- huh, or even as a user. Apple/Facebook/Google could lock out all your users and literally destroy your business in a split second for an arbitrary policy violation, without explaining why, with no way to contact a human being. Haven't we seen enough HN headlines where an independent developer or a small software company is begging for help because <LargeCorporation> canceled their account or locked them out of something with no recourse?
EDIT: I know that AnyList is dependent on Apple's app store. This is still no reason to give Apple (or Google or Facebook) even more power over you.
Holy cow, how is this acceptable to any app developer or software company? This is reason enough for me to never use Apple/Facebook/Google sign-on as a developer -- huh, or even as a user. Apple/Facebook/Google could lock out all your users and literally destroy your business in a split second for an arbitrary policy violation, without explaining why, with no way to contact a human being. Haven't we seen enough HN headlines where an independent developer or a small software company is begging for help because <LargeCorporation> canceled their account or locked them out of something with no recourse?
EDIT: I know that AnyList is dependent on Apple's app store. This is still no reason to give Apple (or Google or Facebook) even more power over you.
It's not like other popular login systems can't also arbitrarily terminate your account, but the really problematic thing here is “Sign in with Apple”'s email hiding, which removes the lifeline of emailing your customers when you lose your sign-in provider.
This seems like the only bummer rule of all. I really would like to use this service on my next project but this dictator rule cannot be tolerated.
You know the reason. It's on the front page of HN today even. Apple will support Sign in with Apple until it is co-opted by "white nationalists" or other scary characters, at which point they will disassociate with that website or app and prevent their services from working with them.
Which is their right of course, but at the end of the day it means we get changes like these in the fine print. Gatekeepers like Apple and Google gain more control over what is allowed on their platforms, and subsequently what is allowed for the majority of the population to see.
Which is their right of course, but at the end of the day it means we get changes like these in the fine print. Gatekeepers like Apple and Google gain more control over what is allowed on their platforms, and subsequently what is allowed for the majority of the population to see.
Why have you put that term in scare-quotes?
Buries the lede. They’ve chosen to drop support for Facebook login rather than also support Apple login. So working as intended!
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 had 250k sign ups over the first weekend, we thought Auth0 might turn us off as we started on a tier capped around 40k)
We assumed this success would quickly taper off if it wasn't "one click" to sign up with your Google/Faceboook account an talked Neil off the ledge.
We assumed this success would quickly taper off if it wasn't "one click" to sign up with your Google/Faceboook account an talked Neil off the ledge.
This escenario seems an clear candidate for A/B testing since I would be conflicted by wanting to provide privacy but understanding it might impact user signups.
Seeing some actual numbers would help me in making that decision.
Seeing some actual numbers would help me in making that decision.
A/B testing auth methods is tricky. It's fine for "can we get better sign up rates" but it wreaks havoc on "can my previous users still sign in". At best you can AU/NA test - show different pre-auth treatments in different, very distant geographies that nevertheless have roughly similar user characteristics.
I don't disagree with you and it was proposed. However we didn't have A/B infrastructure in place then and on a project that may never make money it just wasn't a high enough priority to justify the spend.
Fair enough, sometimes you have to make a decision with what you have. A/B testing adds complexity and specially when doing contract/agency work you don’t have either the time nor the budget to pull it off. Been there myself.
Personally I would have considered to hack something on my own time just out of curiosity :D
Personally I would have considered to hack something on my own time just out of curiosity :D
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.
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...
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...
But you didn’t try anything to confirm/infirm this hypothesis?
Bingo ! This is Apple’s really hard bargain here. Implement us or get rid of all the other garbage sign-in.
I love it. With password managers becoming better and by owning your domain, it almost feels like a self-sovereign identity system. It would be great if services would implement better support for browser form auto-fill, and ask the minimum amount of information during signup. That way it would be very little hassle to signup for a service.
And Apple has integration points with third party password managers.
Only ~1-2 apps of the several dozen I use support them. For folk that aren't super tech savvy, still a struggle
And get rid of all the other non-garbage sign-ins too, correct?
It is very unclear to me why removing user options is a good thing. I use sign in with Google/Facebook.
aren't they going to be asking for the real email though?
email remains the best and free-est login identifier. Most people who are not complete internet plebs have a second email for things they dont trust.
email remains the best and free-est login identifier. Most people who are not complete internet plebs have a second email for things they dont trust.
> Most people who are not complete internet plebs have a second email for things they dont trust.
The vast majority of people don’t have a second email for things they don’t trust. You’re living in a nerd-bubble, but the rest of the world is on the internet too.
The vast majority of people don’t have a second email for things they don’t trust. You’re living in a nerd-bubble, but the rest of the world is on the internet too.
Either the changes are only for the mobile app or they forgot to remove Facebook Sign In in the web [1][2].
[1] https://www.anylist.com/auth/sign-in
[2] https://i.imgur.com/3uC0E9G.png
[1] https://www.anylist.com/auth/sign-in
[2] https://i.imgur.com/3uC0E9G.png
From the OP: "You can expect to see an AnyList app update soon that removes Facebook Login."
This makes perfect sense from their standpoint - especially since they've had similar problems to what they outline with Facebook sign-in and are now dropping that as well. This is also a win for Apple & end-user privacy, as there's one less app using FB's login feature now.
I think Sign in with Apple is a great step forward even if all it does is eliminate apps that require Facebook and/or Google accounts to log in. I hate that - I actually ran into a feature on my mesh router system that required a FB/G login, which made it a useless feature for me. Fortunately I didn't need it..
I think Sign in with Apple is a great step forward even if all it does is eliminate apps that require Facebook and/or Google accounts to log in. I hate that - I actually ran into a feature on my mesh router system that required a FB/G login, which made it a useless feature for me. Fortunately I didn't need it..
For my last two companies (both B2B), I implemented login via Google accounts only. Google login has a number of advantages:
1) Identity is an email address. If I wanted to rip out Google, or Google kicked me off the platform, all I need to do is add passwords and put a "forgot my password" link and my customers continue business as usual.
2) It's not a google-specific email address. You can create Google accounts for any email address.
3) Google login effectively lets other businesses federate their auth system with ours. When they terminate their ex-employee's @example.com account, the employee loses access to their resources at my company.
I don't think you could get away with this for a consumer company; too many people have strong feelings about FB/G/Apple/whatever. But it's fantastic for B2B.
1) Identity is an email address. If I wanted to rip out Google, or Google kicked me off the platform, all I need to do is add passwords and put a "forgot my password" link and my customers continue business as usual.
2) It's not a google-specific email address. You can create Google accounts for any email address.
3) Google login effectively lets other businesses federate their auth system with ours. When they terminate their ex-employee's @example.com account, the employee loses access to their resources at my company.
I don't think you could get away with this for a consumer company; too many people have strong feelings about FB/G/Apple/whatever. But it's fantastic for B2B.
For #2. You can use any email address for an iCloud account also.
point 3 is only true for G Suite customers - if someone is on O365 and signs up for Google normally with their company account, they can access that email after their company turns off access to the email unless they also specifically reset the Google password.
To be fair - you end up with G Suite, Okta or O365 endpoints for B2B. Apple isn't even on the radar there.
#1 is only sort-of true. You can get access to their current email, yes, but the email can change and you should be keying by the Google account ID really.
Can you educate me on what you mean by Google accounts only? I thought Google auth was just OAuth.
They have chosen to have their site or app only allow login with Google accounts, they don't support any other form of authentication.
It's a choice they made, nothing specific to Google or OAuth.
It's a choice they made, nothing specific to Google or OAuth.
I use the Google sign in javascript:
https://developers.google.com/identity/sign-in/web
There may be other options if you want to mess with oauth yourself, but this one is pretty near zero effort.
https://developers.google.com/identity/sign-in/web
There may be other options if you want to mess with oauth yourself, but this one is pretty near zero effort.
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 even worse! Why do I need to share my mobile number for something where you don't need to have it!
I think a lot of services use mobile number login as a way of bot-limiting; harder to create lots of phony email addresses than phone numbers. But it's still a pain in the butt :(
> harder to create lots of phony email addresses than phone numbers
I think you got this the wrong way around.
I think you got this the wrong way around.
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.
Tinder’s.
Their whole point was that you could be confident the people were real because they were tied to a real Facebook account.
Their whole point was that you could be confident the people were real because they were tied to a real Facebook account.
https://tailscale.com/ requires it, as do many other apps that explicitly "don't want to become identity providers and would rather offload that burden to someone else".
Tailscale supports other SSO providers, too. https://tailscale.com/kb/1013/sso-providers
Yup, FWIW I think their selection is great, I was just using them as an example of a company that chose not to provide any in-house email+password option.
For a time I believe Spotify required a FB login. I recall not using it early on because I couldn’t create an account without connecting it to FB.
Pokemon Go's account own doesn't work. Even if you manage to create that account, it won't log you in. With Google account it works as expected. I tried to create two Pokemon Go accounts, gave up and created a Pokemon Go only Google account for child's playing. It has worked a few years.
When did you have this issue? My account is tied to my Google account because on launch the Go servers were completely inundated and the account creation was just constantly failing but using a Google account allowed you to skip that step and start playing.
This was the first month of Pokemon Go years ago. I haven't heard of it being an issue lately but I also haven't needed to create an account in a very long time.
This was the first month of Pokemon Go years ago. I haven't heard of it being an issue lately but I also haven't needed to create an account in a very long time.
I think the first time was around the spring 2017. I could create an account, use the credentials to log in, but trying on several days the game never started. There was some "please wait" kind of screen and waiting for hours didn't help. With a Google account things worked right away.
And a bit over a year the same thing happened. New Pokemon Go account -> log in -> no game. With Google account has been working since.
So, my experience is two tries in the span of two years it did not work.
And a bit over a year the same thing happened. New Pokemon Go account -> log in -> no game. With Google account has been working since.
So, my experience is two tries in the span of two years it did not work.
Pokemon Trainer Club accounts (what you thing of as "Pokémon Go accounts", even though they're used for other Pokémon services) in the past were more buggy than Google accounts, but for at least the past two years I have had no more trouble with my account than my friends who have Google accounts. Additionally, they created a feature where you can link Google/FB to your PTC login so if it does go down in the future you can log in with those other services if you wish.
CalTopo[0] doesn't support email+password. It's one of the few websites I use that doesn't support it, but an unfortunate number of mobile apps don't either.
[0]: https://caltopo.com/map.html
[0]: https://caltopo.com/map.html
Many (> 5-ish?) years ago, Spotify required Facebook login
Yep, that in specific made me hold off on deleting my Facebook for a couple of years. About 2 years ago I noticed you could just click ‘forgot password’ and unbind them.
I’ve gotten rid of Facebook, but now my account name is just a bunch of numbers.
I’ve gotten rid of Facebook, but now my account name is just a bunch of numbers.
[deleted]
[deleted]
DnDBeyond only has these types of logins and does not allow email+password
PUBG mobile requires either FB or G+.
No option for email+pass.
I mean it can be better for privacy if you think about Google/Facebook loging. But it will prevent adding all third party login services, potentially even ones that are more privacy respecting than Apple.
Also there are cases where a "sign in with <particular provider>" is the only option that makes sense because you really want to integrate with the API of this provider. Take for example a "sign in with GitHub". Or in case of services correlated, take for example Instagram where you obviously can sign up with a Facebook account.
I'm more for letting the developer choose what it prefers for authenticating the user and not having a authentication system that gets imposed by Apple.
Also there are cases where a "sign in with <particular provider>" is the only option that makes sense because you really want to integrate with the API of this provider. Take for example a "sign in with GitHub". Or in case of services correlated, take for example Instagram where you obviously can sign up with a Facebook account.
I'm more for letting the developer choose what it prefers for authenticating the user and not having a authentication system that gets imposed by Apple.
I think Apple does allow apps to limit social sign in options where it makes sense. So for example, an email app could have sign in with Google, Microsoft, and Yahoo! but not Apple.
Worth 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.
They mention customer support so many times in that article, but it's a grocery list app! When is the last time I asked for support for the sticky note attached to my refrigerator? I don't doubt that there are indeed customers who need support from time to time, but surely it's a small minority.
These seem to just be contrived arguments to protect their customer data selling bottom line.
These seem to just be contrived arguments to protect their customer data selling bottom line.
Yep, my feelings exactly after reading.
All this whining happens only when your business is very dependent on specific information that gets taken from you.
Definitely picked up the same intentions from the post.
Seems out of place to complain about not having email addresses for "support" reasons.
If they truly cannot help users without asking for their email address, maybe they should not have users (login) then.
Seems out of place to complain about not having email addresses for "support" reasons.
If they truly cannot help users without asking for their email address, maybe they should not have users (login) then.
This.
The blog post was long and winded. And it brought up some very desperate arguments, like the bug bounty offered to hackers when they report security vulnerabilities.
They want people's email addresses, period.
They say that no email breaks the sharing feature. True. But that's something that can be offered later when someone actually does share something with you. They say that the emails will go to the a seldom checked account. True. But users can change email addresses. They say it breaks support service for looking up accounts without email addresses. Again true. But what's another way of looking up accounts? Username. What is another? Apple ID.
They are email network harvesters. Plain and simple. And this is their business model.
The blog post was long and winded. And it brought up some very desperate arguments, like the bug bounty offered to hackers when they report security vulnerabilities.
They want people's email addresses, period.
They say that no email breaks the sharing feature. True. But that's something that can be offered later when someone actually does share something with you. They say that the emails will go to the a seldom checked account. True. But users can change email addresses. They say it breaks support service for looking up accounts without email addresses. Again true. But what's another way of looking up accounts? Username. What is another? Apple ID.
They are email network harvesters. Plain and simple. And this is their business model.
[deleted]
And their whining about not getting email addresses is exactly why I would not want to give mine.
That's exactly what I'm thinking! Further I can't find the EULA of the app on the internet - maybe I'll find it later. But I could bet that they sell the data for marketing purposes. And I could also bet that they removed Facebook not because they don't want to use it but because they had to implement Sign in with Apple which would result in the Data being not so valuable because the standard option is to obfuscate the mail address.
Having any kind of subscription payment massively increases complexity and support requirements in your app.
The article says "When you provide us with your email address, it is never sold, shared, or used to invade your privacy." So, one of you is lying. I don't have the means to determine who, but I don't see what your motivation for lying would be, but can see what theirs may be.
And to extend that, if they are a spammy company, that would be exactly why they would be complaining about SIWAI.
And to extend that, if they are a spammy company, that would be exactly why they would be complaining about SIWAI.
It wasn't sold or shared, the emails came from them. But they were pure marketing, not transactional, and I certainly didn't agree to it or want it.
> 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.
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.
This seems to be a common problem, made more visible when using third-party authentication, that your application has taken the concepts of "Account" and "Authentication Method" as if they were the same thing.
It appears that the "account ID", "preferred contact method+address" and "authentication ID" are all the same here - which then creates the "account management code into a rat’s nest" scenario they describe in the post.
If an Account is, by design, it's own entity - you should be able to have 100 different authentication methods linked to that same account without impacting any other flow or part of the application.
Turn on and off authentication methods would also allow for seamless transition for users, without worrying about when one method is about to be killed.
It appears that the "account ID", "preferred contact method+address" and "authentication ID" are all the same here - which then creates the "account management code into a rat’s nest" scenario they describe in the post.
If an Account is, by design, it's own entity - you should be able to have 100 different authentication methods linked to that same account without impacting any other flow or part of the application.
Turn on and off authentication methods would also allow for seamless transition for users, without worrying about when one method is about to be killed.
I feel like they address this in the article. What you say makes sense in a technical UML diagram point of view, but that's not how people work.
The examples they give are getting support and sharing things with another person with an account. As a user, both of those things are easier for me if there is an email associated with the account.
Said another way, the Account needs some human friendly global identifier. The email you use to log in is an obvious choice, and anything else would require extra work from the user to set up. You could have usernames, for example, but that complicates the signup process and still makes sharing things hard. I know my friends emails already, but I don't know what username they ended up with on this site.
The examples they give are getting support and sharing things with another person with an account. As a user, both of those things are easier for me if there is an email associated with the account.
Said another way, the Account needs some human friendly global identifier. The email you use to log in is an obvious choice, and anything else would require extra work from the user to set up. You could have usernames, for example, but that complicates the signup process and still makes sharing things hard. I know my friends emails already, but I don't know what username they ended up with on this site.
I'd argue that this makes more sense in the real world than in a diagram, after being burnt in multiple real life experiences :)
The assumption both you and AnyList are making is that an email is "THE obvious choice". From a user experience perspective perhaps this "global sharing identifier" should be defined by them.
You'll notice that different generations have different online behaviors. For some, email is their main id. For others, it's their phone number (they don't know most of their friends' e-mail, but know their phone). For others, it's either online handles or nothing at all - think about the device set up for grandma with her daily To Do list.
Of course, having this approach would add some upfront dev work to them but allow them to navigate this much easier later on. And for anyone starting to develop their new app/site/product thinking about this early on can reduce a lot of future headaches.
The assumption both you and AnyList are making is that an email is "THE obvious choice". From a user experience perspective perhaps this "global sharing identifier" should be defined by them.
You'll notice that different generations have different online behaviors. For some, email is their main id. For others, it's their phone number (they don't know most of their friends' e-mail, but know their phone). For others, it's either online handles or nothing at all - think about the device set up for grandma with her daily To Do list.
Of course, having this approach would add some upfront dev work to them but allow them to navigate this much easier later on. And for anyone starting to develop their new app/site/product thinking about this early on can reduce a lot of future headaches.
That's a very idealistic opinion.
People don't care about usernames and other crap. They want an easy option - enter email, communicate over email and be found using email. This isn't their banking app or anything that important.
People don't care about usernames and other crap. They want an easy option - enter email, communicate over email and be found using email. This isn't their banking app or anything that important.
Nobody "wants to use their email". They just want to start using whatever app or service they're trying to connect to as quickly as possible - why exactly do you think "Sign in with X" became so popular in the first place?
+1 Any authentication method that I have enabled for my email should work -- there shouldn't be a need to remember which one is associated with a particular service...
With rare specialized exceptions, pretty much nobody needs all this complexity. Certainly not a simple app like AnyList. All this flexibility is not free, it comes at the cost of obviousness, as they described. It's not worth it much of the time.
The real problem is Apple shoving their proprietary, poorly designed services down everyone's throats.
No, I don't want to use icloud email, I already have an email address. No, I don't want to provide a "real" email address after I provided an obfuscated one. No it's not my fault that messages sent to the obfuscated one will go to some icloud inbox that I didn't create and I don't read. No, it's also not my fault that when I contact support I do it from my normal email address and not from the obfuscated one (how would I even do that). It's not the support's fault that they can't connect the two.
It's not the user's fault, and it's not the developer's fault. Apple is the sole designer of this mess. There is no excuse.
The real problem is Apple shoving their proprietary, poorly designed services down everyone's throats.
No, I don't want to use icloud email, I already have an email address. No, I don't want to provide a "real" email address after I provided an obfuscated one. No it's not my fault that messages sent to the obfuscated one will go to some icloud inbox that I didn't create and I don't read. No, it's also not my fault that when I contact support I do it from my normal email address and not from the obfuscated one (how would I even do that). It's not the support's fault that they can't connect the two.
It's not the user's fault, and it's not the developer's fault. Apple is the sole designer of this mess. There is no excuse.
You can create an iCloud account with your own email address. That avoids getting another email address.
When using Apple login, Apple offers the choice of providing an anonymous email to the third party or your actual email. It's up to you. Its about user choice. More privacy or less. Apple wants you to have a choice. Use it or not.
When using Apple login, Apple offers the choice of providing an anonymous email to the third party or your actual email. It's up to you. Its about user choice. More privacy or less. Apple wants you to have a choice. Use it or not.
Then why do most of my non-tech relatives have an @icloud.com address that they never needed and never read?
Blame the user all you want, but their "choice" was guided by Apple designed UI and Apple provided defaults. Whatever it is, it's producing optimal outcomes for Apple and no one else.
Blame the user all you want, but their "choice" was guided by Apple designed UI and Apple provided defaults. Whatever it is, it's producing optimal outcomes for Apple and no one else.
I have one too (which I've since swapped for an email I actually use). I'm not one hundred percent sure, but I think it was the only option for a while (inherited from MobileMe, perhaps), or at least it wasn't clear that you could/should add another email.
Either way, Apple could definitely do something with regards to make it easier/more obvious to replace it with a useful email address, especially now as it becomes a federated identity provider.
Either way, Apple could definitely do something with regards to make it easier/more obvious to replace it with a useful email address, especially now as it becomes a federated identity provider.
I can't answer that. However, if you go to appleid.apple.com to create a new AppleID, you must use an existing email address.
When I create a new user account on the mac, it asks the new user if they want to create an AppleID. The default is to use their existing email address. You must specifically select an option to get an iCloud account. If you purchase an Apple device, you again have the option of an iCloud account or using your existing email address for your AppleID. Apple is not using some deceptive UI to get you to create an iCloud email address.
However, I guess you still feel it is somehow evil that Apple does allow you to get a free email account where the provider does NOT read your email content and use it to target ads at you. Suboptimal for Apple from a pure profit perspective.
When I create a new user account on the mac, it asks the new user if they want to create an AppleID. The default is to use their existing email address. You must specifically select an option to get an iCloud account. If you purchase an Apple device, you again have the option of an iCloud account or using your existing email address for your AppleID. Apple is not using some deceptive UI to get you to create an iCloud email address.
However, I guess you still feel it is somehow evil that Apple does allow you to get a free email account where the provider does NOT read your email content and use it to target ads at you. Suboptimal for Apple from a pure profit perspective.
Whatever the UI is now, doesn't speak for what it used to be over the years. The cumulative effect matters.
There are tons of people with @icloud.com email addresses that they never use who will fall into the login / customer support traps described in the article.
But sure let's not even acknowledge those very real problems, deny Apple's role in this, and blame users. That will surely solve the issues.
There are tons of people with @icloud.com email addresses that they never use who will fall into the login / customer support traps described in the article.
But sure let's not even acknowledge those very real problems, deny Apple's role in this, and blame users. That will surely solve the issues.
I think you are missing the point and are perhaps letting this app vendor create an impression of a large problem based on anecdotal evidence. Perhaps they are just whining because they don't want to lose all that data. I have no idea that that is the case, but we can't rule it out.
Tons of people falling into these alleged traps? Really? What is that based on?
Apple is saying they want their platform to support personal privacy. If an app on their platform offers third party sign-ons that are known to abuse personal privacy, that app must offer Apple's solution that respects personal privacy. Despite it being an imperfect solution, I personally am thrilled that I have that option and I'm happy with Apple taking a stand on one of the most important issues today and going forward.
Some occasional customer support issues vs. providing customers with a real solution to significant privacy issues. From a user perspective the value of having such a choice is high.
Nobody is blaming users. Frankly, I think users are smarter than we typically assume. The support situation is really pretty trivial. If you save the onboarding email sent to the anonymized email address, you've got all you need to interact with an app customer support. People will quickly learn this and get on board if they want the privacy benefit. Its just not a big deal.
Apple's role is about increasing privacy and respecting their user's right to privacy. I fully acknowledge that. Does this create some hassle for app vendors? Yes, but I don't care about that in relation to the greater gain.
Tons of people falling into these alleged traps? Really? What is that based on?
Apple is saying they want their platform to support personal privacy. If an app on their platform offers third party sign-ons that are known to abuse personal privacy, that app must offer Apple's solution that respects personal privacy. Despite it being an imperfect solution, I personally am thrilled that I have that option and I'm happy with Apple taking a stand on one of the most important issues today and going forward.
Some occasional customer support issues vs. providing customers with a real solution to significant privacy issues. From a user perspective the value of having such a choice is high.
Nobody is blaming users. Frankly, I think users are smarter than we typically assume. The support situation is really pretty trivial. If you save the onboarding email sent to the anonymized email address, you've got all you need to interact with an app customer support. People will quickly learn this and get on board if they want the privacy benefit. Its just not a big deal.
Apple's role is about increasing privacy and respecting their user's right to privacy. I fully acknowledge that. Does this create some hassle for app vendors? Yes, but I don't care about that in relation to the greater gain.
I don’t see any technical reason this couldn’t be done, but it would be more work for both the app developers and the user.
Time and value are not "technical", though they can be measured.
Technically you can build an app that's purely a AR sticky notes specifically on your fridge... but the value of that app is approximately 0.
Technically you can build an app that's purely a AR sticky notes specifically on your fridge... but the value of that app is approximately 0.
I think the problem is that many apps, use the same form for login/signup. So a user thinks they're logging in, but they're actually creating a new account with a new authentication method...
In my experience the “Sign on with Apple“ option makes it totally risk free to click and I don’t even think twice before clicking to create an account whereas a typical registration page will definitely raise the possibility of me bouncing.
Sign-in With Apple is perfect for those accounts that you basically never wanted to have anyway. If it’s something where I want a “real” login, especially one that I might want to share, then I’ll go through the trouble of actually registering and picking a shared secret that my wife and I know.
But for the average app that needs a way to keep a user profile for me, it’s just right, and from a UI perspective on iPhone it really is magic. Two taps and I’m just in with zero mental baggage and an email relay to eliminate the possibility of spam.
Sign-in With Apple is perfect for those accounts that you basically never wanted to have anyway. If it’s something where I want a “real” login, especially one that I might want to share, then I’ll go through the trouble of actually registering and picking a shared secret that my wife and I know.
But for the average app that needs a way to keep a user profile for me, it’s just right, and from a UI perspective on iPhone it really is magic. Two taps and I’m just in with zero mental baggage and an email relay to eliminate the possibility of spam.
> Another issue is Sign in with Apple’s “Hide My Email” feature. With this feature, if you create an account with us, Apple will generate a special email address just for that account. So rather than your email address being [email protected], we will see your email address as something like [email protected].
Ironically, this is also why I use Sign Up with Apple at every opportunity I can
Ironically, this is also why I use Sign Up with Apple at every opportunity I can
How is this ironic? It is by design and obviously they know why people do it because the very next sentence says that. Why on Earth would you'd want to use a list-sharing app that uses email as the addressing system and then not share your email.
The anonymous e-mail that Sign-In with Apple generates forwards to the e-mail used to set up your Apple ID. So it's not like it's a random e-mail that acts as a /dev/null.
This is by far the biggest selling point of Sign-In with Apple for me and I will continue to use it, and continue to not use apps that don't support it. I have plenty of e-mail aliases, but having an alias auto-generated for you is very convenient, and not having to generate a secure password is also very convenient.
The day AnyList gets hacked (not saying it will - but it's highly likely, the way security has taken a backseat due to "features") then at least my personal e-mail and password won't be there for every hacker on Earth to see and try to spam passwords to get into all of my other accounts.
This is by far the biggest selling point of Sign-In with Apple for me and I will continue to use it, and continue to not use apps that don't support it. I have plenty of e-mail aliases, but having an alias auto-generated for you is very convenient, and not having to generate a secure password is also very convenient.
The day AnyList gets hacked (not saying it will - but it's highly likely, the way security has taken a backseat due to "features") then at least my personal e-mail and password won't be there for every hacker on Earth to see and try to spam passwords to get into all of my other accounts.
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.
This is where their article lost credibility with me. Their decision to base their sharing and addressing system on email was their mistake, and Apple is just the first to force them to face their mistake.
I don't want to share my spam email with all my friends to get them to share with me. And I don't want to give my primary email to an app that will spam me.
If I want to share something, I'll send a link and the recipient can connect to me that way. I don't need to search them within the app to get in contact, that's useless.
> so when they enter your email address, our systems will believe that you don’t have an account. At that point, you’ll get an email from us asking you to create an account.
This is a trivial part of the problem to solve. Why am I being asked to create an account in an invite email? Why not "log in or create account" and having the link itself be the piece that connects the share to me.
I don't want to share my spam email with all my friends to get them to share with me. And I don't want to give my primary email to an app that will spam me.
If I want to share something, I'll send a link and the recipient can connect to me that way. I don't need to search them within the app to get in contact, that's useless.
> so when they enter your email address, our systems will believe that you don’t have an account. At that point, you’ll get an email from us asking you to create an account.
This is a trivial part of the problem to solve. Why am I being asked to create an account in an invite email? Why not "log in or create account" and having the link itself be the piece that connects the share to me.
It's not a mistake, by any means.
It's dead clear that you don't work with consumers. Your technical bias shows what you care about and you're(an me) are an utter minority.
If you want security, btw - you should have multiple passwords for different things. And ideally not even use a password manager.
It's dead clear that you don't work with consumers. Your technical bias shows what you care about and you're(an me) are an utter minority.
If you want security, btw - you should have multiple passwords for different things. And ideally not even use a password manager.
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 Apple, this kind of requirement is not really useful and will likely cause issues for you down the line, which is why usernames are better for addressing people within apps (e.g, Instagram handles).
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 Apple, this kind of requirement is not really useful and will likely cause issues for you down the line, which is why usernames are better for addressing people within apps (e.g, Instagram handles).
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.
Riot does this with Valorant too and the implementation is a nightmare.
Small nit: Potential hackers would only have access to your email, provider id and whatever other details they pass along (preferred name, profile picture URL, etc.). Social login doesn't provide consumers (AnyList in this case) with your password.
Agreed, social login like Facebook et. al do not provide passwords to consumers, but e-mail is already contentious enough.
Most people use the same e-mail for every single account they have. A large majority of these users use the same password for all of their accounts. (Just want to clarify that I do neither of these things - I have a large set of e-mail aliases and have a unique & secure password for each account I have to set up manually).
If you'll grant me that fact, then all I need is your e-mail from a dump of AnyList's users table, and look up that e-mail in my already vast database of dumped tables, and see that your password was "hunter2". Now I have access to your bank account, because you used the same e-mail and password for that account as well.
This is a bit of a contrived example, but in general, any personal information that is leaked (e-mail included) is bad - full name, address, and the like, which many websites ask for, is even worse, because crackers have even a better shot at guessing a lot of your personal information, and at that point, the ball is in their park.
Most people use the same e-mail for every single account they have. A large majority of these users use the same password for all of their accounts. (Just want to clarify that I do neither of these things - I have a large set of e-mail aliases and have a unique & secure password for each account I have to set up manually).
If you'll grant me that fact, then all I need is your e-mail from a dump of AnyList's users table, and look up that e-mail in my already vast database of dumped tables, and see that your password was "hunter2". Now I have access to your bank account, because you used the same e-mail and password for that account as well.
This is a bit of a contrived example, but in general, any personal information that is leaked (e-mail included) is bad - full name, address, and the like, which many websites ask for, is even worse, because crackers have even a better shot at guessing a lot of your personal information, and at that point, the ball is in their park.
FYI: Getting a hold of someones' email isn't particularly hard.
So you say you are using your email as the unique identifier instead of the password?
If you use a unique password for every service, what would you need a unique email for?
If you use a unique password for every service, what would you need a unique email for?
> If you use a unique password for every service, what would you need a unique email for?
Because then you control when the flow of marketing or "Service" related email stops. And you can tell which vendor leaked your email either deliberately or by accident.
Because then you control when the flow of marketing or "Service" related email stops. And you can tell which vendor leaked your email either deliberately or by accident.
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.
The article also implies that if anyone can guess your email address, they can send you/share with you a list. I wonder what anti-spam measures AnyList implements?
Sign In With Apple would require that AnyList enable SPF protections on any outbound domain registered with Apple for SIWP use:
To send emails to users with private email addresses, you must register your outbound emails or email domains and use Sender Policy Framework (SPF) to authenticate your outbound emails.
To send emails to users with private email addresses, you must register your outbound emails or email domains and use Sender Policy Framework (SPF) to authenticate your outbound emails.
I assume they rely on the fact that sharing a random list with a random person a thousand times is pointless.
If they really needed a user ID, just have account holders create a username after the Apple sign-in flow. Most people have a go-to username, and those are easy enough to remember and give to a support associate.
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.
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.
[deleted]
> One problem is that most Apple IDs are tied to an iCloud email address. So most accounts created via Sign in with Apple will use an iCloud email address. But many of those iCloud email addresses are unused and unchecked, because a customer’s “real” email account is their Gmail, Yahoo, or Hotmail account.
Wow, this is a really good point. I just checked and yup -- my AppleID is directly linked to my icloud email, and I've never once checked my icloud email account. I wonder what's in there. Meh, too lazy to go check it
Wow, this is a really good point. I just checked and yup -- my AppleID is directly linked to my icloud email, and I've never once checked my icloud email account. I wonder what's in there. Meh, too lazy to go check it
This seems strange to me. My iCloud account is my Gmail address (even though I also have an iCloud one on the account) and when I use Sign in with Apple I get an option to redirect all emails to Gmail.
But the system is indeed weird, I signed up for an account in an app with bike routes and wanted later to check it in the browser and had no idea what or how to find out what my account is or how should I sign in (could be also the app/website didn't implement this properly).
But the system is indeed weird, I signed up for an account in an app with bike routes and wanted later to check it in the browser and had no idea what or how to find out what my account is or how should I sign in (could be also the app/website didn't implement this properly).
Things may differ from person to person depending on when they created their Apple account(s).
At first, before they had cloud services, you created an Apple account to purchase things from the iTunes store. You could use any email address.
Then they created MobileMe (which was rebranded to .Mac), and that came with an email address @mac.com. (I believe there were a couple of other domains you could choose instead, but don't remember what they were).
That was eventually discontinued, replaced with iCloud, and .Mac accounts were migrated.
Somewhere in all there Apple loosened requirements so that you could use an outside email address as your cloud ID, and made it so a cloud account could could also work as an iTunes account.
For those who created their accounts after that point, it's all sane. Create your Apple account using your outside email address if you want, or using an Apple provided address if you prefer, and then that one account can be used for all your Apple stuff. Buying music, buying or renting video, buying apps, and the cloud stuff.
For those of us who created our accounts before all that, we ended up with an account using our outside address which has our music, video, and app purchases on it, and an account using our @mac.com address that has calendars, photos, and the like.
When they changed it so all Apple accounts could be used for everything, it got even more annoying for us. Whenever we'd see some dialog asking us to sign in to our Apple account, we'd have to guess if it wanted our music/video/app account or our cloud account. If we guessed wrong, we could end up accidentally purchasing apps or media on the cloud account.
Apple does not provide any way to transfer purchases between your accounts, so if you end up with media or app purchases on both accounts there is no way to consolidate other than purchasing duplicates.
If you are willing to do that, or if you have avoided duplicate purchases, you can kind of manually consolidate accounts. You can export calendars, contacts, and the like from your original cloud account, and import them into your original iTunes account. Same for photos, online disk space, and anything else you have on the original cloud account.
Once you've got it all in the original iTunes account, delete everything from the original cloud account, and then just make sure to never again sign into that account. Any time you see the Apple account login dialog, give the original iTunes account.
At first, before they had cloud services, you created an Apple account to purchase things from the iTunes store. You could use any email address.
Then they created MobileMe (which was rebranded to .Mac), and that came with an email address @mac.com. (I believe there were a couple of other domains you could choose instead, but don't remember what they were).
That was eventually discontinued, replaced with iCloud, and .Mac accounts were migrated.
Somewhere in all there Apple loosened requirements so that you could use an outside email address as your cloud ID, and made it so a cloud account could could also work as an iTunes account.
For those who created their accounts after that point, it's all sane. Create your Apple account using your outside email address if you want, or using an Apple provided address if you prefer, and then that one account can be used for all your Apple stuff. Buying music, buying or renting video, buying apps, and the cloud stuff.
For those of us who created our accounts before all that, we ended up with an account using our outside address which has our music, video, and app purchases on it, and an account using our @mac.com address that has calendars, photos, and the like.
When they changed it so all Apple accounts could be used for everything, it got even more annoying for us. Whenever we'd see some dialog asking us to sign in to our Apple account, we'd have to guess if it wanted our music/video/app account or our cloud account. If we guessed wrong, we could end up accidentally purchasing apps or media on the cloud account.
Apple does not provide any way to transfer purchases between your accounts, so if you end up with media or app purchases on both accounts there is no way to consolidate other than purchasing duplicates.
If you are willing to do that, or if you have avoided duplicate purchases, you can kind of manually consolidate accounts. You can export calendars, contacts, and the like from your original cloud account, and import them into your original iTunes account. Same for photos, online disk space, and anything else you have on the original cloud account.
Once you've got it all in the original iTunes account, delete everything from the original cloud account, and then just make sure to never again sign into that account. Any time you see the Apple account login dialog, give the original iTunes account.
Even if you have alternate email addresses associated with your iCloud account, you are free to update it to have your external email address be the default for your iCloud/Apple ID.
Visit https://appleid.apple.com/account/manage to make those changes.
Help article: https://support.apple.com/en-us/HT202667
Although I will note that it says you can't change your Apple ID email address if you choose an @me.com, @mac.com, or @icloud.com email address for your Apple ID, which is the first time I've seen that warning.
Visit https://appleid.apple.com/account/manage to make those changes.
Help article: https://support.apple.com/en-us/HT202667
Although I will note that it says you can't change your Apple ID email address if you choose an @me.com, @mac.com, or @icloud.com email address for your Apple ID, which is the first time I've seen that warning.
... I'm not sure I understand this scenario?
So you have an AppleID, which is a full iCloud account (i.e. not just an AppleID using a Gmail address.. So you login to iCloud on some device, and then specifically go untick the "Mail" option in iCloud preferences? Really?
So you have an AppleID, which is a full iCloud account (i.e. not just an AppleID using a Gmail address.. So you login to iCloud on some device, and then specifically go untick the "Mail" option in iCloud preferences? Really?
My Apple ID was initially tied to my gmail address, and then at some point Apple forced me to change it, so I use my yahoo address. I never check that address, since I only use it for my Apple ID.
That has never been an issue.
That has never been an issue.
Another issue with Sign in with Apple is the fact that their private relay has a pre-set allow-list per app for sending email to relay addresses.
This means that you must either prove ownership of domains, or pre-add email addresses to Apple's systems. I understand why they have done this, it will reduce spam considerably, but the private relay system is already designed to empower users to do this and this extra step may be impossible for some developers.
Take for example a retailer – they need to dispatch goods and use different carriers in different countries. When the user buys something they very likely want email notifications about delivery, a feature that most carriers provide. For the carriers to send those notification emails you'll need to pre-add them all to Apple's systems. You can't prove domain ownership because fedex.com isn't your domain, but where are those emails going to come from? Better hope your carrier doesn't change sending address at some point or the email goes into a black hole.
Apple also limits the number of domains and addresses you can send from. In the original documentation it was "10 domains and addresses" (not sure if 10 of each, or 10 total). This was raised to 100 I believe, but that's still probably an issue for larger multi-national companies, or those who necessarily have to integrate with many external services.
The really hard-line privacy stance is that the retailer shouldn't share the emails and should do the notifications themselves, but for many this is prohibitively difficult to do, or at least detracts from places where the retailer can actually add value. The benefits are also very small, as the contracts with carriers typically protect user data, require deletion quickly after delivery, and retain most privacy benefits while allowing for a good UX.
This means that you must either prove ownership of domains, or pre-add email addresses to Apple's systems. I understand why they have done this, it will reduce spam considerably, but the private relay system is already designed to empower users to do this and this extra step may be impossible for some developers.
Take for example a retailer – they need to dispatch goods and use different carriers in different countries. When the user buys something they very likely want email notifications about delivery, a feature that most carriers provide. For the carriers to send those notification emails you'll need to pre-add them all to Apple's systems. You can't prove domain ownership because fedex.com isn't your domain, but where are those emails going to come from? Better hope your carrier doesn't change sending address at some point or the email goes into a black hole.
Apple also limits the number of domains and addresses you can send from. In the original documentation it was "10 domains and addresses" (not sure if 10 of each, or 10 total). This was raised to 100 I believe, but that's still probably an issue for larger multi-national companies, or those who necessarily have to integrate with many external services.
The really hard-line privacy stance is that the retailer shouldn't share the emails and should do the notifications themselves, but for many this is prohibitively difficult to do, or at least detracts from places where the retailer can actually add value. The benefits are also very small, as the contracts with carriers typically protect user data, require deletion quickly after delivery, and retain most privacy benefits while allowing for a good UX.
That's a good point, but I'd be surprised if Apple doesn't have (or is building) a mechanism to allow certain well-known domains to be trusted sender, in the circumstances you note. Like, have "enter your custom domain", but also "checkboxes for fedex.com, etc".
That was an interesting read. Also, they close with...
"These are both excellent points, and it’s absolutely true that some of the arguments above apply to creating an account via Facebook. That’s why we’re also announcing that we’ll be removing the Facebook Login from AnyList."
"These are both excellent points, and it’s absolutely true that some of the arguments above apply to creating an account via Facebook. That’s why we’re also announcing that we’ll be removing the Facebook Login from AnyList."
Well, that, and also if they don't remove FB login, then the would be required to also implement Sign in with Apple.
They didn't want to implement Sign in with Apple, so they had to remove FB login.
They didn't want to implement Sign in with Apple, so they had to remove FB login.
Which is a pretty anti-competitive move on Apple's part.
They're essentially using their control of the iOS ecosystem to benefit unrelated products.
I seem to remember that those kinds of actions didn't work out well for Microsoft :)
They're essentially using their control of the iOS ecosystem to benefit unrelated products.
I seem to remember that those kinds of actions didn't work out well for Microsoft :)
Apple takes many anti-competitive and consumer-hostile actions. They can freely get away with it, though, as they aren't a monopoly.
Also, they will argue that they are doing it for privacy and security reasons which are benefits to users.
But I don't know how much a judge would care about that.
But I don't know how much a judge would care about that.
How is this user hostile - forcing app developers to give users a choice that doesn’t give the app developer your real email?
I said "Apple takes many anti-competitive and consumer-hostile actions. They can freely get away with it, though, as they aren't a monopoly." I did not say this action was consumer-hostile.
So, forcing them to give users a choice is somehow equivalent to... forcing vendors to not give customers a competitors browser?
Ok sure. That seems totally the same. Not at all as ridiculous as the invented "monopoly of iOS" that people use to justify the claim Apple is abusing a monopoly position.
Next thing you'll complain Coca Cola is abusing its monopoly position on Coke.
Ok sure. That seems totally the same. Not at all as ridiculous as the invented "monopoly of iOS" that people use to justify the claim Apple is abusing a monopoly position.
Next thing you'll complain Coca Cola is abusing its monopoly position on Coke.
If you implement Sign In With Apple, you don't have a relationship with your customers anymore. They're Apple's customers, and Apple can take them away at any time.
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.
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.
> "Apple reserves the right to disable Sign in with Apple on a website or app for any reason at any time."
I think GP is absolutely right here. Apple can take the customers at any time for any reason. Apple could ban you from using Sign in with Apple simply because Tim Cook doesn't like what food you eat for breakfast. So, I have to agree with GP that these are Apple's customers at this point.
I think GP is absolutely right here. Apple can take the customers at any time for any reason. Apple could ban you from using Sign in with Apple simply because Tim Cook doesn't like what food you eat for breakfast. So, I have to agree with GP that these are Apple's customers at this point.
The check on this is that you are now putting an inconvenience on that apps users. Maybe it’s okay in some isolated circumstance however, I imagine this won’t sit well if it becomes a reoccurring theme for iOS users, as they will come to view Sign In With Apple as unstable/unsafe (like Google and it’s graveyard). It would quickly render Sign In With Apple useless if the trust that it will continue to work whenever used is not there
I actually think this wouldn’t really happen in practice as consumers are quick to respond negatively to this behavior, so I’d be shocked if Apple actually did this without some darn good reason (I imagine it will also include removing said app)
I actually think this wouldn’t really happen in practice as consumers are quick to respond negatively to this behavior, so I’d be shocked if Apple actually did this without some darn good reason (I imagine it will also include removing said app)
> The check on this is that you are now putting an inconvenience on that apps users.
That hasn't stopped Apple from remove apps or preventing updates -- clearly inconveniences on users -- for whatever reasons they want. It has happened and it will happen again.
There is no check on this unless your app's audience is Netflix/Spotify/Facebook huge. If you're just an average developer you can be killed off at any time.
That hasn't stopped Apple from remove apps or preventing updates -- clearly inconveniences on users -- for whatever reasons they want. It has happened and it will happen again.
There is no check on this unless your app's audience is Netflix/Spotify/Facebook huge. If you're just an average developer you can be killed off at any time.
Transferred to Apple more than the user.
Apple operates on behalf of the user. Apple saw users with throwaway/burner email addresses and said why not make this easier for everyone?
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.
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.
How is that different from FB/Google's login services? The only apps that are required to support Sign in with Apple are those that also support FB/G/etc sign in, so those companies have already chosen a path...
Google provides an email address. You could replace your Google auth with password auth in an afternoon just by adding a "forgot your password" link.
Facebook auth used to provide an email address, but it's been almost a decade since I last used their APIs so I don't know if that has changed.
Apple's "provide an anonymous email address" inserts them between you and your customer.
Facebook auth used to provide an email address, but it's been almost a decade since I last used their APIs so I don't know if that has changed.
Apple's "provide an anonymous email address" inserts them between you and your customer.
When you use Apple's Sign In it flat out asks whether you want to use your real email or an anonymous one. The user is purposely says, "Hey, Apple get in the middle I don't trust these clowns."
HN... where people go to complain about both companies requiring access your email, and companies requiring you to be able to block other companies from access to your email. I don’t get it.
Exactly! Which is as it should be. Way too many websites take for granted that they can do anything with the email addresses provided, including sending spam by default or with no way of opting out. With Sign In with Apple, if they don’t get in my email, that’s because I don’t want them to have it. Then, their poor marketing practices are irrelevant, which actually makes me more likely to create an account on their website.
Many apps also don't want to have the hassle of securely managing user login details.
Not sure about Google auth, but I created a Spotify account with their FB login years ago. About 1.5 years ago I wanted to decouple them, but they have no way to do it. I had to create an entirely new account. Not sure if it's a technical limitation or just a case of Spotify not prioritizing it, but their support tech did relate to me that they had lots of those switches occurring at the time.
Facebook does not guarantee an email address, either. (Just went through this process with Apple/Google/Facebook/Email auth - even using Firebase Auth library - surprising how many edge cases there were).
[deleted]
It's not, which is why they are also removing FB login.
I don’t want to have a relationship with every app developer. If you want a relationship with your customers that you control, you are free not to implement any third party sign on and implement your own.
Not every app maker WANTS to store this user data.
Some makers just want things to work and to keep the process as simple as possible for the user.
Some makers just want things to work and to keep the process as simple as possible for the user.
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.
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.
Why is 2 so obvious? I imagine many implementations would do that, but basically once you exchange your SSO token for the site-specific token, you could stop making any requests to the SSO provider. The only part of your SSO provider's offering that inherently needs to track you is running detection if you're a bot.
There's a subtle sense of exuberance shining through in this article that makes it a gratifying read, even if you've never heard of the company before. Kudos to them for their decision not to bow to Apple's demands. Please tell us how it goes!
> bow to Apple's demands.
Apple "demanded" companies either add their privacy friendly sign in option, or give up on the data-slurping Facebook google sign-ups. This company gave up FB sign in, which they acknowledge is pretty gross and bloated.
Apple "demanded" companies either add their privacy friendly sign in option, or give up on the data-slurping Facebook google sign-ups. This company gave up FB sign in, which they acknowledge is pretty gross and bloated.
Well, they're also getting rid of the "Log in with Facebook" option too, which is arguably giving into the demands of Apple.
That works as intended - they took out FB integration.
> One problem is that most Apple IDs are tied to an iCloud email address.
Is that actually true? None in my household are.
Is that actually true? None in my household are.
It depends mostly on the demographic in my experience. For example, my parents have icloud email addresses that they occasionally email me from and never reply to for the reasons mentioned in this post.
My anecdote is similar. I first created my Apple account when the iTunes music store was introduced in 2003.
But, when I setup the account for my mom and my wife, I just created an iCloud email address.
My wife never uses her iCloud email address. I don’t think she uses the default mail client - she uses the gmail app.
But, when I setup the account for my mom and my wife, I just created an iCloud email address.
My wife never uses her iCloud email address. I don’t think she uses the default mail client - she uses the gmail app.
Then switch off the Mail option in iCloud settings on their devices. Poof, mailbox disappears.
Last year we pulled all social logins (facebook, google, yahoo) out of our app, after supporting them for years. The UX / customer service issues mentioned in this post are absolutely legit, a complete PITA. While we were nervous about adding the extra signup friction, a year later I can easily say it was worth doing.
> 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.
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.
Your iCloud account does not have to be paired with an iCloud email address. Mine is paired with my regular email address.
Yes, but many are. This app in particular needs an email address that is actually checked.
From what others have said, they also need it to add to their marketing list....
Apple's developer docs on the Private Email Relay Service are relevant to those evaluating the technicals of AnyList's position. Three specific highlights from that doc are relevant when considering AnyList's objections:
https://developer.apple.com/documentation/sign_in_with_apple...
After the user has shared a private relay email address with your app, they can find, view, and manage it in their account settings at Settings > Apple ID > Password & Security > Apps Using Your Apple ID.
The relay server transforms your email address so it’s readable to the user. For example, [email protected] may become sales_at_xyz_com_<something>@privaterelay.appleid.com instead of a random email address. Replies from the user are still routed back through the service to preserve the user’s privacy.
To send emails to users with private email addresses, you must register your outbound emails or email domains and use Sender Policy Framework (SPF) to authenticate your outbound emails.
https://developer.apple.com/documentation/sign_in_with_apple...
After the user has shared a private relay email address with your app, they can find, view, and manage it in their account settings at Settings > Apple ID > Password & Security > Apps Using Your Apple ID.
The relay server transforms your email address so it’s readable to the user. For example, [email protected] may become sales_at_xyz_com_<something>@privaterelay.appleid.com instead of a random email address. Replies from the user are still routed back through the service to preserve the user’s privacy.
To send emails to users with private email addresses, you must register your outbound emails or email domains and use Sender Policy Framework (SPF) to authenticate your outbound emails.
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.
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.
I usually uninstall apps with a 1-star review if they provide zero functionality until you provide your email address.
Apps and devices serve me, not the other way around.
Apps and devices serve me, not the other way around.
So you don't use social media on your phone?
After reading the article and comments i'm honestly a bit baffled.
Why is email address obfuscation an important component of online privacy? There are so many other more invasive and pernicious privacy concerns to worry about. It seems like we're spending an enormous amount of time to build far more complex authentication systems that are brittle and confusing just to avoid sharing an email address. Why?
Email addresses are supposed to be semi-public. If I share it with you I want you to contact me. People do abuse this, of course, but the open nature of it is exactly its best quality. I can sign up for new services easily, they can contact me, and if they bother me I block them.
I've had the same email address for almost 20 years now and have never had issues managing it. I cannot say the same for Facebook connect and Google Auth. I actively avoid signing up for services if I have to use a 3rd party auth service.
Why is email address obfuscation an important component of online privacy? There are so many other more invasive and pernicious privacy concerns to worry about. It seems like we're spending an enormous amount of time to build far more complex authentication systems that are brittle and confusing just to avoid sharing an email address. Why?
Email addresses are supposed to be semi-public. If I share it with you I want you to contact me. People do abuse this, of course, but the open nature of it is exactly its best quality. I can sign up for new services easily, they can contact me, and if they bother me I block them.
I've had the same email address for almost 20 years now and have never had issues managing it. I cannot say the same for Facebook connect and Google Auth. I actively avoid signing up for services if I have to use a 3rd party auth service.
An e-mail address is as close to a unique id of a user as you can get online.
It makes cross-site/service tracking very easy.
It makes cross-site/service tracking very easy.
> "One problem is that most Apple IDs are tied to an iCloud email address."
Is this really true? I've had Apple IDs for pretty much as long as they've existed, but I've never had an iCloud email. Any email address can be an Apple ID.
(...in fact, early on, it didn't even have to be an email address. I still have one of those old-style Apple IDs.)
Is this really true? I've had Apple IDs for pretty much as long as they've existed, but I've never had an iCloud email. Any email address can be an Apple ID.
(...in fact, early on, it didn't even have to be an email address. I still have one of those old-style Apple IDs.)
In a rat-race of adding a bunch of (Sign in with xyz) buttons everywhere in the login forms, this news feels good in a weird way. Most developers use OAuth login support using several other services to reduce the friction of signing up, but this article made me think about this for a while. I've been in a situation where I could not remember whether I signed up using a provider.
Password managers and 2FA options are getting popular in the mainstream media, and most people know about it after their financial service providers are mandating 2FA. It's probably time we figure out an easy way for users to sign in using a random alias of their email address to sign in to any service. Something that is generated using their real email address, the service provider's domain name and some kind of salting. This is the time the plain old username-password login came back.
Password managers and 2FA options are getting popular in the mainstream media, and most people know about it after their financial service providers are mandating 2FA. It's probably time we figure out an easy way for users to sign in using a random alias of their email address to sign in to any service. Something that is generated using their real email address, the service provider's domain name and some kind of salting. This is the time the plain old username-password login came back.
The only authentic point I saw in this entire article was the one about the lack of documentation by Apple in implementing this across different platforms.
Everything else applies to logging in with Facebook (or can be dealt with in other ways), which the company has supported for years and is now forced to remove it because of Apple’s restrictions. Without Sign In with Apple, I doubt if they would’ve chosen to remove the Facebook login anytime soon, thus putting more users into privacy hell holes despite making statements like this:
“At AnyList, we respect your privacy.
...
When you provide us with your email address, it is never sold, shared, or used to invade your privacy.”
If the documentation had been good enough, I’m sure they would’ve implemented it and also retained Facebook login for a longer time. Seeing Facebook login being removed gives me some comfort and a sense of “all’s well that ends well”.
Everything else applies to logging in with Facebook (or can be dealt with in other ways), which the company has supported for years and is now forced to remove it because of Apple’s restrictions. Without Sign In with Apple, I doubt if they would’ve chosen to remove the Facebook login anytime soon, thus putting more users into privacy hell holes despite making statements like this:
“At AnyList, we respect your privacy.
...
When you provide us with your email address, it is never sold, shared, or used to invade your privacy.”
If the documentation had been good enough, I’m sure they would’ve implemented it and also retained Facebook login for a longer time. Seeing Facebook login being removed gives me some comfort and a sense of “all’s well that ends well”.
Given all these third-party sign-ins are a fairly transparent grab for power by the central company, I'm not sure why anyone would implement any of them. By doing that you're giving up power over your sign-in process, which is a pretty enormous concession.
Not an Apple use but I had a question. If one signs up with Signin with Apple, how can that user move over his stuff to say an Android app? Or even Desktop app? (Or does the Apple ID keep track of all this anonymous id to app mapping?)
You still have your apple account on your PC/Android phone/etc. You just login on apple's website with your apple account and it passes the token/id to whatever app needs it.
For example you can goto dropbox on your pc/whatever and click signin with apple to see how it works.
For example you can goto dropbox on your pc/whatever and click signin with apple to see how it works.
I had never heard of AnyList and this makes sure I will never use them.
Before Sign in with Apple, I uninstalled most apps that required me to sign up before I could even try them at all. Now I specifically look for apps that support it.
I don't want to give my email to 100 different companies (I get spam on the aliases that I did hand out long ago to apps that aren't even around anymore).
Though, all these hitherto obscure companies jumping into the spotlight just by setting themselves up as the underdog against the Apple world tree gives me an idea of what to do when I want a quick boost in popularity.. :)
Before Sign in with Apple, I uninstalled most apps that required me to sign up before I could even try them at all. Now I specifically look for apps that support it.
I don't want to give my email to 100 different companies (I get spam on the aliases that I did hand out long ago to apps that aren't even around anymore).
Though, all these hitherto obscure companies jumping into the spotlight just by setting themselves up as the underdog against the Apple world tree gives me an idea of what to do when I want a quick boost in popularity.. :)
> 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).
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).
Developer should just ask for user's email after new sign up using third party provider. Even Facebook does not require email for user to sign up. They should separate the email used for the account & the email used for third party sign in. Because 1 user can have multiple third party sign in, all with different email.
I think they did not need to care about customer who did not check the reply email from support, because customer can also have multiple email and did not use their primary email to sign up to your service.
I think they did not need to care about customer who did not check the reply email from support, because customer can also have multiple email and did not use their primary email to sign up to your service.
What's to stop someone signing up with a fake email and sharing it on a forum so that many people can sign in with it?
Yes, I know that there are ways to reduce this by scanning IPs and so on, but by using third party auth you offload that onto the auth providers.
Yes, I know that there are ways to reduce this by scanning IPs and so on, but by using third party auth you offload that onto the auth providers.
Recently went through the same debacle. Our hope was that we could solely rely on Magic Link instead of email/password ... but it turns out many users don't really understand it [1]. So your options are:
1) Email/Password Sign In
2) Bite the bullet and add Apple / the "full auth stack" (FB/Google/etc.) & deal with account linking issues.
[1] https://snaphabit.app/blog/password-less-login/
1) Email/Password Sign In
2) Bite the bullet and add Apple / the "full auth stack" (FB/Google/etc.) & deal with account linking issues.
[1] https://snaphabit.app/blog/password-less-login/
I wonder why we still have passwords. Couldn't we have a simple USB device that is encrypted, cooperates with the native O/S in an encrypted manner, and then allows remote login to sites also in an encrypted manner?
The device could be programmed to automatically generate new passwords/keys/whatever needed for remote authentication.
It would also have a 'disable' functionality that would render it useless if stolen.
(Perhaps this thing already exists. I am too lazy to google it as I type this :-)).
The device could be programmed to automatically generate new passwords/keys/whatever needed for remote authentication.
It would also have a 'disable' functionality that would render it useless if stolen.
(Perhaps this thing already exists. I am too lazy to google it as I type this :-)).
Side note: there's (almost) no problem implementing Apple sign in on Android. It is basically the same OAuth flow as Facebook or Twitter, with couple of minor quirks.
I seriously hope I'll see the day when OpenID takes off. It doesn't seem to be going the right way, but it would solve most of our login problems.
One way to sign in, used everywhere, decentralized, set up 2FA for everything in one place, switch providers with ease or be your own provider.
Apple could promote a decentralized solution instead of forcing the sign in with apple shit on people, but clearly they want all your data so they can lock you in.
One way to sign in, used everywhere, decentralized, set up 2FA for everything in one place, switch providers with ease or be your own provider.
Apple could promote a decentralized solution instead of forcing the sign in with apple shit on people, but clearly they want all your data so they can lock you in.
I dunno. There are simple solutions to the issues raised in the blog post, many good ones here in the comments. Seems likely they wanted to get rid of third party logins and oddly chose to throw it on Apple. And I’m not sure anyone, including Apple, cares if they adopt Sign In with Apple. In the end, I think everyone just wants to end creepy sign-in practices. Facebook login deleted from Anylist... that’s a win for everyone.
[deleted]
Love it. I hate it when I'm presented with a "sign in with Google". I feel pressured to have a Gmail account or a Facebook account (which I honestly don't want).
I get the fact that login is broken across the web and there is no centralized login authority, but sorry Google/Facebook are not it imho.
We can/should look at other ways to authenticate, but thats a larger discussion.
I get the fact that login is broken across the web and there is no centralized login authority, but sorry Google/Facebook are not it imho.
We can/should look at other ways to authenticate, but thats a larger discussion.
It's a grocery list app, how much customer support do they have to do!? Feels like they just really really want to have my email.
The larger problem is trying to get the average Facebook and Instagram user to care about security (if they cared about those things they wouldn’t be on a Facebook product but I digress).
I applaud Apple’s intentions but as this article proves, if the user isn’t driving the push to be more private then initiatives like Sign In With Apple cause little more than support headaches.
I applaud Apple’s intentions but as this article proves, if the user isn’t driving the push to be more private then initiatives like Sign In With Apple cause little more than support headaches.
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)
It’s pretty user-hostile to refuse to support the authentication provider the user wants to use. If I’m already in the Apple ecosystem, using Sign In with Apple, a service that doesn’t implement Sign In with Apple but could is preventing me from doing what I want, just as much as Walmart not accepting Apple Pay.
Why do you need to log in in this app? All the problems indicate that app is used on one device only
All of them good points. I'll add another wrinkle; for some reasons I can barely remember, I have 2 different Apple IDs. I was a paid .Mac user when it was a thing, but I also had a different account to make iTunes purchases back in the day. Currently I need to log in with both in my devices; one of them is used for purchasing in iTunes/App Store, the other one is used for iCloud Photos/iCloud Drive. However you can also make purchases in the Books app (which I use it to sync PDFs), so this always trips me up. There's no way to merge two Apple IDs, and setting up a new device is always an adventure. Knowing when to use which Apple ID can be confusing (don't get me started on 2FA, I'm afraid that having 2 Apple IDs will eventually lead to me getting locked out!).
I liked the concept of Sign in with Apple when I first heard about it, but at this point it might be too confusing (I also never check my "main" Apple ID email).
I liked the concept of Sign in with Apple when I first heard about it, but at this point it might be too confusing (I also never check my "main" Apple ID email).
Identifying users by email is a bad practice anyway. Such systems usually don't provide a way to change the email address, because it's literally your id. This makes it unnecessarily difficult to migrate between email addresses.
Apple having a major flaw is a pretty bad mark against this. But in my experience, companies doing it themselves are far worse.
The correct response to "Yo, they fucked up." is not "Oh screw it. We'll just do it ourselves."
The correct response to "Yo, they fucked up." is not "Oh screw it. We'll just do it ourselves."
I find Apple's Sign in approach shady (forcing apps to have it, and have it first on the list), but this response is also about not liking the privacy features of Apple Sign in so... I wouldn't read much into it.
This is a war between apps and platforms on who gets direct access to customers.
Makes sense to support it and respect users privacy. If they forget their login, they can just sign in with apple again? And if they contact you for support they can provide their email address to you then.
Some of this can be solved by asking a user for their email when they open a support ticket. Also allowing them to link accounts from multiple login providers. These are largely "solved" issues.
How long till it becomes mandatory by Apple? I give it a year. Then they'll say "our users expect it, so now we do" and it won't matter if that's true or not.
What about vendor lock-in? Apple forced many apps on the App Store to use Sign In with Apple for increased “convenience” but it also makes it very inconvenient for people to switch to Android.
Yes, that's mentioned in the article:
> if there are platforms where AnyList doesn’t support Sign in with Apple, like Android, and someone wants to log into their account, they’d have to know their privaterelay.appleid.com email address.
> if there are platforms where AnyList doesn’t support Sign in with Apple, like Android, and someone wants to log into their account, they’d have to know their privaterelay.appleid.com email address.
Sign In with Apple works a lot like Sign In with Google or Facebook. There's no reason it can't be used on Android also.
https://github.com/willowtreeapps/sign-in-with-apple-button-...
https://github.com/willowtreeapps/sign-in-with-apple-button-...
I mean, if this is pushing them to remove Facebook login, Sign in with Apple and the resulting requirement to use it has been a net positive for privacy for AnyList as well.
The convenience and supposed privacy of signing in with Apple ID out weights the cons. People will still have problem remembering which email they used down the road.
I support their decision. They shouldn't be dictating developers which SSO services to use or not. It's developer's app not Apple's.
> Furthermore, if there are platforms where AnyList doesn’t support Sign in with Apple, like Android, and someone wants to log into their account, they’d have to know their privaterelay.appleid.com email address. (And that certainly won’t be easy to find if you no longer have an iOS device.) And then they’d have to create a password with us, since they wouldn’t be able to sign in using Sign in with Apple.
I’m an avid iOS user with a Windows desktop. I will never use “Sign-In with Apple” for this reason. It’s not useable unless you exclusively use Apple devices. Which I don’t.
I’m an avid iOS user with a Windows desktop. I will never use “Sign-In with Apple” for this reason. It’s not useable unless you exclusively use Apple devices. Which I don’t.
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 devices. It should show up on the web and in Android apps, Apple only requires it on Apple devices because that's the only devices that they control.
I wish Apple communicated that better and/or developers better understood that Sign in with Apple really is a FB/Google/social login button like all of the others and should be supported everywhere, not just Apple devices.
(I'm in the iOS/Windows dual mode user team myself these days and find that I trust Sign-In with Apple, but I've definitely had to already email developers to request that they add the Sign-In with Apple button to websites and explain why they would/should.)
I wish Apple communicated that better and/or developers better understood that Sign in with Apple really is a FB/Google/social login button like all of the others and should be supported everywhere, not just Apple devices.
(I'm in the iOS/Windows dual mode user team myself these days and find that I trust Sign-In with Apple, but I've definitely had to already email developers to request that they add the Sign-In with Apple button to websites and explain why they would/should.)
If you read the article, you'd see they address the reason they cannot implement it on Android yet. Apple hasn't provided documentation for it. Apple doesn't seem to be taking it seriously.
To keep my reply in a single place: https://news.ycombinator.com/item?id=23684452
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.
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.
Interesting. I’ve never signed into iCloud on my Windows PC so tbh the thought that’s how it worked never crossed my mind!
I’ve also never come across a “sign in with Apple” button on Windows. Not sure I’ve seen it on iOS either...
I’ve also never come across a “sign in with Apple” button on Windows. Not sure I’ve seen it on iOS either...
Well, that's another app I won't be using.
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 thinking of enhancing notifications do you can interact with them directly from the chatbot interface too.
The signin flow is great as it has 2fa built in by default.
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 thinking of enhancing notifications do you can interact with them directly from the chatbot interface too.
The signin flow is great as it has 2fa built in by default.
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.
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.
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.
Well I also have no intention of slurping PII beyond the bare minimum. I understand there may be some added friction for some users but as a one man show I can’t deal with the maintenance necessary to be on the mobile app stores. I look at it as a constraint to encourage creativity. As I develop ideas I am exploring more and more how to make the ux and the approach gel in a seamlessly natural manner. I guess I’ll find out if I’m successful after launch...
It certainly is creative, and not abusing data is commendable (and I am sincere). We would not be in this situation if websites were better behaved overall. However, I necessarily use heuristics informed by my experience, because I cannot afford the time or money to do a background check for every site or app.
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
AnyList does not like Sign In with Apple (and others), but they helping with the sign on jungle.
If you disable your account through Apple's website the email is no longer valid. Does anyone know if they recycle the emails?
Why not just bind the sso Mail to an local Account, then it doesn't matter what identity Provider gets used by the customer. In addition, add a check that prevents Account creation of [email protected] you have a problem with it or nag the user to provide a real mail for this account if you detect this type of mail.
This way you would have a user friendly implementation without giving up on sso.
Wouldn't their problem be solved by using usernames?! Usernames are easy to remember, share and setup.
Um, it doesn’t forward to their iCloud email address, it forwards to the email they use for their iCloud login - eg the primary gmail or whatever address.
Users have the option to provide their personal email address, but given the track record of these being sold it’s reasonable to expect users to not trust you.
You can email them correspondence because as above that goes to their primary email.
What you lose is the value of the email address as an asset.
Users have the option to provide their personal email address, but given the track record of these being sold it’s reasonable to expect users to not trust you.
You can email them correspondence because as above that goes to their primary email.
What you lose is the value of the email address as an asset.
Well opined piece, as a customer of Anylist for over 3 years you have my full support in this decision.
[deleted]
I'd like to see Apple allow users to use "Sign in with Apple" to maintain Apple ID account and purchase hardware/software? Imagine if they had to go through what they're asking all the services on their platform to go through... yeah... never gonna happen. Bravo AnyList for calling Apple out for pushing immature software ecosystem harmful software agenda.
[deleted]
As a user, I won't be supporting them either.
Just give me sign in without involvement of a third party.
Just give me sign in without involvement of a third party.
[deleted]
For me it sounds like they didn’t like the additional work Apple made them do, that would actually benefit the end user - I love sign in with apple, the best part is the unified workflow without typing on a phone.
I dream of a world when I won’t have to type passwords on a phone anymore.
I dream of a world when I won’t have to type passwords on a phone anymore.
Their blog post is well written and explains point by point why implementing it would be problematic for them AND for end users. Strange that you arrived at the conclusion "they didn’t like the additional work Apple made them do"
They describe and edge case of someone not getting the email or wanting to login on another platform.
I’m talking about the most common happy path that they don’t want to optimize - the user registration/login
I hate typing a secure password on a phone and I want to evade this process whenever possible. Using Sign in with Apple you don’t have to type a thing and you confirm using FaceId.
It seems like the problems they were facing require different UX solutions than they already had or some bug reports to Apple (if the feature is really missing something).
For me it is much better to use Sign in with Apple as the user as the flow is simple, unified and Apple has a track record of caring about privacy, where it is often not the case for randomservice.io
I’m talking about the most common happy path that they don’t want to optimize - the user registration/login
I hate typing a secure password on a phone and I want to evade this process whenever possible. Using Sign in with Apple you don’t have to type a thing and you confirm using FaceId.
It seems like the problems they were facing require different UX solutions than they already had or some bug reports to Apple (if the feature is really missing something).
For me it is much better to use Sign in with Apple as the user as the flow is simple, unified and Apple has a track record of caring about privacy, where it is often not the case for randomservice.io
so all of this could be fixed by AnyList just asking the user to type in their email address instead of tying it to a data mining operation from their login name
well at least they are honest!
well at least they are honest!
>> 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.
It’s not. It’s perfectly slick , simple and powerful and even non technical user can use. Please enable.
What a well written and forceful argument.
cry me a river
They will get removed. They don't have the power to fight Apple.
No, they're fine -- if your only login is first-party, you don't need to support Sign in with Apple. (They're taking out FB login to comply.)
I do wonder, though, whether the requirement for Sign in with Apple is coming in a few years. As in, if you allow users to sign in with email/password, you must allow users to sign in with "sign in with apple". It might be more subtle, like suggested auto-fill to create a new account.
That sounds like a bridge too far even by Apple standards. I can get on board with "if you support Facebook, you have to support us as well", but not allowing any kind of escape hatch feels particularly scummy. At some point it's none of Apple's business how people sign up with my service.
I don't understand how "if you support Facebook, you have to support us as well" is ok. Only by holding the relationship between the user and the developer "hostage".
For now. I don't have much hope that it will remain like that.
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.
EDIT: I really love the downvotes from developers that are perfectly aware this is how the things are.
I found it jarring that Apple would present themselves as the vanguard defenders of privacy by announcing what is basically an email relay service. Most privacy-conscious people wouldn't exactly think of their emails going through Apple as any particular win in privacy.
And even for the "general user" I find the argument very weak, since it doesn't look as being any easier than using any other email relay, and there is a huge obvious conflict of interest for Apple here (they get data they may not have had otherwise PLUS have yet another tool to bind you to their services).
It reminds me of the days where everyone in the www was making OpenID providers but no one was actually willing to do an actual OpenID _consumer_. So that I could actually use _my_ identity provider on a server of _my_ choice instead of going through the hoops of yet another large company for no reason.
And even for the "general user" I find the argument very weak, since it doesn't look as being any easier than using any other email relay, and there is a huge obvious conflict of interest for Apple here (they get data they may not have had otherwise PLUS have yet another tool to bind you to their services).
It reminds me of the days where everyone in the www was making OpenID providers but no one was actually willing to do an actual OpenID _consumer_. So that I could actually use _my_ identity provider on a server of _my_ choice instead of going through the hoops of yet another large company for no reason.
How is it anything but a win to have an additional easy option to use a more trusted relay rather than not? Many people have never heard of a relay, and wouldn’t understand its benefit if the option wasn’t presented to them like this.
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 to log into a site or app before. My password manager is usually pretty good at letting me know if I've got a "normal" account with user/password, but it doesn't do anything to remind me if I ought to log in with one of the other services.
Every time I'm occasionally asked to sign into Spotify, Pinterest, Medium, Quora, etc. -- it's like, I'm pretty sure I've signed up with something before, but who even knows which one, or multiple?
If password managers could start saving that you've got accounts associated with Apple/Facebook/Google and highlight the relevant button on sign-in, it would be a big feature improvement.