> At your first sign in, apps and websites can ask only for your name and email address to set up an account for you. You can use Hide My Email—Apple's private email relay service—to create and share a unique, random email address that forwards to your personal email. That way you can receive useful messages from the app without sharing your personal email address. Only the registered app or site developer can communicate with you using this email, and you can turn it off at any time.

> Sign in with Apple won’t track or profile you as you use your favorite apps and websites, and Apple retains only the information that’s needed to make sure you can sign in and manage your account.

From https://support.apple.com/en-us/HT210318

Interesting - Apple is requiring that you register sending domains as an app developer. So even if your email address database leaks (or you try to sell your user data), only messages that are from your domains and pass SPF/DKIM would be able to send to those addresses. Really smart. I wish Google Oauth would support something like this!

https://developer.apple.com/documentation/signinwithapplejs/...

As a application owner, I won't see the users email, instead Apple generates a unique address for each signup. That email also redirects any emails to the users email.

For someone who doesn't like a lot of what Apple does, this is a really nifty feature.

We just started integrating "Sign in with Apple" last week and are about to deploy it. Discovering the shielding of email addresses was a happy discovery, which I haven't seen before.

What happens when the customer contacts you for support and is using the shielded email service. You don't know the "real" email for the account, and the customer can't email you from the "shield" email. So you have limited means of verifying they are who they say they are. So how do you for disclose account information to them if you can't be sure they are the account owner?

I assume what Apple would like you to do is to build an "open a support ticket" flow into the app itself, which either asks for the customer's "contact email", or allows correspondence directly through the app. Such in-app support flows are already pretty standard for e.g. mobile carriers' apps, I've noticed.

You send them an email to the address associated with to account with a verification code.

When I used the feature with Byte it gives you the option whether you wish to mask your email address or send your real email address.

Is this on Apple's side of the authentication? Because if you implement the web version (on a non-Apple device) and login with credentials, you don't seem to get a choice, it always uses a masked email address.

Yeah, gives you a choice when you login with iOS.

Then again most application owners won’t be that happy they have one less data point to sell.

I think if you look at most application owners (not the top 1%/10%), they don't care that much about selling the data to someone. Better to use it themselves to gain better understanding. And as long as you can reach the user, it's good enough.

But maybe I'm naive, or biased because of my location and personal wants.

Here's a link for ya:

https://support.apple.com/en-us/HT210318

In essence, Apple generates a unique email address through their relay service that forwards to (and thus hides) your actual email address. It was widely considered a pretty major step in the right direction for user privacy.

How does account recovery work?

If you signed in the Apple, it would be through Apple's recovery process.

Sounds like it is good for privacy, unless Apple decides to snoop?

If you're using iOS or macOS, Safari, etc. you're already trusting them significantly. This avoids introducing a third-party who otherwise would not be involved in the session.

Well, as is any online service. I think the idea is the site you sign up with doesn't know your actual email address.

"Utterly private" is a very odd term here.

At the very least, Apple knows which sites you're signing into, and has the unique e-mail addresses used at those sites, and has likely issued the authentication tokens for those sites. I'm not sure what's "utterly private" about this setup.

You are already trusting Apple regardless if you are using iOS.

Your email isn't revealed to the site, so it's privacy from the site you are signing into. Although I'm sure they are still requesting basic info like name and potentially age.

As covered on Macrumors [1], you have the option of using a unique generated email on Apple's servers which then forwards to your own email without the service provider getting any info about you. You also have the option to choose what data, if any, you share with the service.

[1] https://www.macrumors.com/guide/sign-in-with-apple/

So is the unique generated email one-time use or it's persistent? Also, if an app owner gives that generated email address to a third or fourth party, and that party sends an email to the unique address, does the mail still reach my inbox? If so then what is the purpose?

The app developer has to tell Apple which domains are allowed to send emails to the generated address. If the domain isn't on the list, no emails will be received.

Ah ok. Pretty neat.