These seem to just be contrived arguments to protect their customer data selling bottom line.
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.
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.
And to extend that, if they are a spammy company, that would be exactly why they would be complaining about SIWAI.
Side note, disabling 'load remote content' in email client stops all spam in a while, they think emails are not read.
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.
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 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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Ironically, this is also why I use Sign Up with Apple at every opportunity I can
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.
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 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.
What's the point in password manager, if all you need is one time auth - and you're in!
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).
Riot does this with Valorant too and the implementation is a nightmare.
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.
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.
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.
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.
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
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).
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.
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.
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?
That has never been an issue.
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.
"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."
They didn't want to implement Sign in with Apple, so they had to remove FB login.
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 :)
But I don't know how much a judge would care about that.
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.
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.
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 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)
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.
Hardware requirements for software is a decades old concept, and it’s true they deprecate and obsolete supported software and hardware on for older platforms, but it’s rare I’ve seen Apple taken a user hostile approach here within supported lifetimes though it has happened yes it is rare.
Their developer experience on the other hand does not see the same care and attention a lot (most even) of the time. That’s because, and I believe this strongly, Apple never wants 3rd party software to have platform influential power over them again, like Microsoft and Adobe did for decades. It’s sad but not unsurprising that their platforms can be very developer antagonistic if you don’t take their happy path (and sometimes even then). To them though, it doesn’t matter until it affects a large quadrant of the Apple consumer base and in some occasions yes not even then, but largely it’s the consumer who has the biggest voting block with Apple in terms of pressure on the platform, as I’ve watched it play it they never had a history particularly after the iPhone came out of having the best developer relations relative to say, Microsoft, who provides a very positive experience in comparison
It’s just not in their DNA because of the fear of having too powerful of vendors putting pressure on the platform that they otherwise control outright. When you look at their policies in this context they make a heck of a lot more sense (even if you don’t agree. I certainly do not always)
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.
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.
Some makers just want things to work and to keep the process as simple as possible for the user.
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.
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.
Is that actually true? None in my household are.
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.
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.
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.
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, firstname.lastname@example.org 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.
Apps and devices serve me, not the other way around.
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.
It makes cross-site/service tracking very easy.
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.)
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.
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”.
For example you can goto dropbox on your pc/whatever and click signin with apple to see how it works.
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).
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.. :)
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.
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.
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 :-)).
1) Email/Password Sign In
2) Bite the bullet and add Apple / the "full auth stack" (FB/Google/etc.) & deal with account linking issues.
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 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 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 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).
The correct response to "Yo, they fucked up." is not "Oh screw it. We'll just do it ourselves."
> 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.
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 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.)
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.
I’ve also never come across a “sign in with Apple” button on Windows. Not sure I’ve seen it on iOS either...
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 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.
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.
Just give me sign in without involvement of a third party.
I dream of a world when I won’t have to type passwords on a phone anymore.
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
well at least they are honest!
It’s not. It’s perfectly slick , simple and powerful and even non technical user can use. Please enable.
EDIT: I really love the downvotes from developers that are perfectly aware this is how the things are.
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.