On Sign-In with Apple

At WWDC this year, Apple announced a new feature for user registration with applications. Called simply "Sign In with Apple", it's effectively an OAuth2 authentication ritual similar to what Facebook, Google, Twitter (and more) currently offer. The catch is that Apple wants to do it in a way that protects your privacy, by acting as an in-between agent to avoid your email address being used for spam, data targeting or profiling, and more. It's really significant, since a company the size of Apple pushing this could enable it to take off in a way that just wouldn't happen elsewhere.

However, I've noticed more than a few people throwing comments around the web to the tune of:

• "I already do this by providing a fake email, like [email protected], to everyone!"
• "I'm protected already because I run my own domain with a catch-all email, like [email protected]!"

These imply that what Apple is doing is easily replicated, which is somewhat far from the case. Let's examine why.

The Special Email

You sign up to a provider for some service that you just want to scope out, and you're worried about the safety of it. You use Gmail, so you decide "let's just give it a special one that I can block later, like [email protected]". Later on the service database leaks. You're safe, right?

Not so much. Removing the special character bits from Gmail is not inherently difficult, so matching your email across database dumps becomes relatively straightforward for any cleaning script worth its salt. You can block all the emails coming from that special email, but nothing is stopping you from getting them... and nothing is stopping the provider from emailing your real one, which as noted, there's a good chance they've got now. Linking your data sets together for profiling is also relatively easy at this point.

How's this change with Apple's approach? When you sign in with Apple, you get assigned a special email address that acts as a relay to your true email. Reading the documentation further, this becomes even more useful than it sounds - to send email via that relay, it has to come from a domain that the developer explicitly proves they control. Anything else is outright ignored. This means that, should database leaks occur, you have a per-app-unique email that can't be tied across leaks, and can't be arbitrarily emailed or spammed. It's providing privacy in a way that your home-grown special email case simply can't.

The Catch-All Email

So you're savvy enough to run your own domain-based email, and you decide "alright, let's just use a [email protected] email and weed out the bad actors this way". This works slightly better than the special email case above, but at the end of the day, I'm going to be honest with you: I've seen more than my fair share of data cleaning scripts, and if your domain isn't a known email provider, you're just going to be attributed as the same user across leaks. You're not big enough to matter to a bad actor, and it's easy enough to lump anything matching your domain together. You're still going to be profiled if you go this route.

Big-Corp?

The other thing I keep seeing come up is paranoia around big corporations being the one to vend out these solutions. This is also sometimes phrased as "privacy shouldn't come at a price". This is correct, it shouldn't... but Apple should be applauded for this move, because your home-grown solution isn't actually doing anything to solve the bigger issue. Apple didn't invent email relays, privacy tools, or what have you, but they're able to push them at a scale that forces the tech industry to change for the better.

We will not move past this era of user-targeting unless there's a big entity that steps in, be it government regulation (seemingly, currently, unlikely) or a large corporation with enough muscle to make it happen (in this case, Apple). Dislike them for whatever reason you want, but they really do deserve credit for being willing to stand up and push this issue.