When a company blocks Mailinator, they're giving up a pretty small number of users -- those who know about Mailinator, use it, and refuse to sign up for a service that blocks it. Since Sign In with Apple is required for any iOS app that supports 3rd-party login, any company (with an app, which is mostly what this is all about anyway) that decides to block this new type of authentication will be forced to either give up all 3rd-party login options (costing them existing users who sign in this way and increasing the cost to acquire new ones), or give up their iOS app -- in either case, this probably means giving up a large number of users.
I’d like to see these:
1. Restricted to people who have associated a physical Apple device, and
2. No ability for the user to re-scramble the anonymous identifier once it is assigned to a service.
If these two criteria are met, I won’t consider it a throwaway email service.
People can and have been trivially creating “unlimited new anonymous accounts” by creating new and multiple email accounts on Gmail, Yahoo, Outlook, Protonmail, Tutanota and many other “free e-mail” providers. Unless you have a list of all “free” email providers around the world and are blocking them, this stand against Apple doesn’t make sense to me.
These proxy email addresses are supposed to be pseudonymous, one per apple id + app team, and are set to relay to a verified email address associated with that apple id.
Authentication will tie back to an associated physical apple device, although you can have one device associated with more than one Apple ID.
I haven’t investigated Facebook or Google SSO in depth (I always considered it a bit distasteful to participate in making these behemoths more indispensable) but if they offer some useful metadata that allows me to exclude G/FB accounts which are inauthentic or freshly created, I might look into it too.
The "real person bit" is a thing. It's the sole bit of information Apple gives for free, which is either that Apple thinks it's "highly likely" that the user is a real person (the bit's absence doesn't mean Apple thinks it's a bot, it just means Apple can't be confident it's a real person, which might simply mean Apple doesn't have enough information to make that call).
I run a large regional forum (10-15k active users per day) and our business model (such as it is) does not rely upon having as many randoms as possible getting user accounts.
We are quite selective when it comes to approving new memberships. We look at numerous subtle signals to decide whether to allow an account to be approved instantly, approved with limits, delayed or rejected. Email, ASN, browser behaviour, user's actions prior to the registration page, and numerous other things which strongly predict whether someone is an authentic new contributor, or a sock puppet/astro-turfer/troll/spammer/abuser etc.
This saves us an astronomical amount of pointless work for our moderators and makes our environment more conducive to constructive and useful contributions. (In a way it's like Hacker News comments except we're not as pedantic about chatty contributions so long as they're good natured.)
User privacy is a great thing, and most of us smaller developers have nothing against it. However, it needs to be done in a way that doesn't threaten our business continuity.
If your business is dependent on giving away user privacy to Facebook or Google unless you are doing something that integrates with them - it deserves to fail.
I don't want to know who someone really is.
I don't care how little information I get through these systems. I don't want it.
What I do want to know is that I can exclude throw-away Google/FB/Apple accounts made five minutes ago specifically to establish a new whitewashed identity on my site.
Right now I don't offer Facebook or Google login at all—specifically because I think the consequences (both privacy and the further entanglement of powerful entities) are not worth it.
For dealing with non-legit users the email address itself isn't so important. We don't ignore it—we happily reject attempts from ~10k throwaway domains and also some whole TLDs—but it's only one in a set of signals. The reason why the click-link-in-email process is so useful is mostly because it's a way for me to inject confusing and uncertain failures to the process to make it incrementally harder to game/predict our registration system. And it lets us inject plausible yet artificial slowness so that a persistent arsehole is never able to move faster than our people.
(Far more important are the subtle signals, particularly how the user behaves prior to registration. For example if a totally clean browser goes straight to the registration page it's likely to be an arsehole in a private browsing window. Legit users almost invariably browse content immediately prior to registering.)
You can still verify their email address for password resets. You send the link with the email address to the alias and Apple forwards it to the user.
But the whole purpose of using SSO is that you are not responsible for passwords - the IDP is. You should just be able to store the user id.
Besides, why use any third party identity provider if you are still managing passwords? You said that you needed an email address to send a password reset link.
Correct but irrelevant. For aiding the registration of legit users, verifying an email address is beneficial as a way for them to ensure they are able to recover their password.
Why do you need to help them recover their password if you’re using a third party?
Which would be even more reason not to sign in at all. That said I'm sure that whenever the official guidelines come out there will be something explicit about not doing so (although of course that would only apply to apps)