As they point out at the very bottom, all their arguments apply to all third-party sign-ons, so they're removing Facebook as well.
So there's nothing specifically against Apple, despite the title seeming to imply it -- just that they're taking the move right now because of Apple's new policy coming into effect.
I've got to say, I really wish there were a way to know whether I already used Facebook, Google, or Apple 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.
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.
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.
> 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.
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
> 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.
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.
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.
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..."
> 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.
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.
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.
> "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.
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...
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.
> 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.
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
> 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.
> 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.
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..
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.
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.
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.
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.
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.
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.
> 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
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.
> 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
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.
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."
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.
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.
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!
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.
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.
[+] [-] crazygringo|5 years ago|reply
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.
[+] [-] rahimnathwani|5 years ago|reply
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.
[+] [-] joshspankit|5 years ago|reply
Username: Log in with FB
Password: <blank>
[+] [-] kripy|5 years ago|reply
[1] https://www.facebook.com/settings?tab=applications&ref=setti...
[2] https://myaccount.google.com/security
[+] [-] mcintyre1994|5 years ago|reply
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.
[+] [-] mdavidn|5 years ago|reply
[+] [-] jborichevskiy|5 years ago|reply
[+] [-] imron|5 years ago|reply
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.
[+] [-] ryanianian|5 years ago|reply
[+] [-] cj|5 years ago|reply
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.
[+] [-] grawprog|5 years ago|reply
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.
[+] [-] neya|5 years ago|reply
"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..."
[+] [-] cbhl|5 years ago|reply
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.
[+] [-] TheSpiceIsLife|5 years ago|reply
[+] [-] envolt|5 years ago|reply
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.
[+] [-] Thorrez|5 years ago|reply
What about the argument that users check their gmail addresses regularly but rarely check their icloud email addresses?
[+] [-] ourcat|5 years ago|reply
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.
[+] [-] dustinmoris|5 years ago|reply
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...
[+] [-] jasonlingx|5 years ago|reply
Nope, not all their arguments. Only some.
[+] [-] spullara|5 years ago|reply
I absolutely agree that password managers could remember this stuff. Single-signon is pretty easy to identify and you could setup the relationship.
[+] [-] dalore|5 years ago|reply
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.
[+] [-] habosa|5 years ago|reply
[+] [-] unknown|5 years ago|reply
[deleted]
[+] [-] meerita|5 years ago|reply
[+] [-] thaumasiotes|5 years ago|reply
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.
[+] [-] no_wizard|5 years ago|reply
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
[+] [-] WorldMaker|5 years ago|reply
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.
[+] [-] alister|5 years ago|reply
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.
[+] [-] czzr|5 years ago|reply
[+] [-] djrogers|5 years ago|reply
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..
[+] [-] stickfigure|5 years ago|reply
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.
[+] [-] muro|5 years ago|reply
[+] [-] alerighi|5 years ago|reply
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.
[+] [-] intellirogue|5 years ago|reply
[+] [-] mxcrossr|5 years ago|reply
These seem to just be contrived arguments to protect their customer data selling bottom line.
[+] [-] nashashmi|5 years ago|reply
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.
[+] [-] persona|5 years ago|reply
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.
[+] [-] zaroth|5 years ago|reply
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.
[+] [-] TheArcane|5 years ago|reply
Ironically, this is also why I use Sign Up with Apple at every opportunity I can
[+] [-] ThePhysicist|5 years ago|reply
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.
[+] [-] lowmemcpu|5 years ago|reply
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
[+] [-] danpalmer|5 years ago|reply
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.
[+] [-] blakesterz|5 years ago|reply
"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."
[+] [-] stickfigure|5 years ago|reply
[+] [-] qwerty456127|5 years ago|reply
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.
[+] [-] tboyd47|5 years ago|reply
[+] [-] Angostura|5 years ago|reply
Is that actually true? None in my household are.
[+] [-] withinboredom|5 years ago|reply
[+] [-] artichikin|5 years ago|reply
[+] [-] TheRealDunkirk|5 years ago|reply
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.