During its unveiling of iOS 13 last week, Apple gave a significant amount of stage time to new privacy features that it’s been working on, not the least of which is a new Sign in with Apple feature that’s designed as a secure and private alternative to the traditionally invasive integrated sign-in systems that Facebook and Google offer.
Apple highlighted some of the key points about the new feature, such as how it would reveal as little private information as possible and even offer the ability to create random, private forwarding email addresses for each sign-in that can be discarded at any time. However, as with many of Apple’s new features, the introduction left numerous questions about the specifics of how it will all work.
Fortunately, TechCrunch’s Sarah Perez has been able to take a deeper dive into the feature, offering up answers to a number of “burning questions” that we’ve probably all had.
What We Already Know
Perez confirms some of the key things we already know, such as the fact that Apple has designed the feature to be focused on privacy, and that it will leverage Apple’s existing two-factor authentication support — features like Face ID and Touch ID — as well as offering anti-fraud detection and a “one-touch, frictionless means of entry” into third-party apps. If an app simply wants a sign-in for a back-end web service but doesn’t require any personal information such as your name or email address, the sign-in procedure will be extremely quick and seamless.
As Apple’s Craig Federighi already touched on during last week’s keynote, if an app does want more personal info, you’ll be told what information it’s requesting, and be able to choose whether to share your email address at all, while also offering the choice of using a random forwarding address for privacy. However, to make things simple, Apple presents this as two basic options: Share My Email or Hide My Email. The latter generates the aforementioned random address, but doesn’t appear to bother the user with the details of what the address actually is.
While Federighi mentioned that any of the addresses can be easily disabled at any time, he didn’t elaborate on exactly how this will be done, but presumably Apple will offer a feature in the iOS Settings app, or perhaps via the iCloud web portal, as a means to view and manage these addresses and which apps they’re associated with.
The ability to use disposable addresses isn’t entirely new, of course. Gmail and other services have long supported the ability to add a suffix to your email address, simply by adding a plus sign to your name followed by any string of text you like. Apple’s approach offers an unprecedented degree of anonymity; plus addressing still clearly exposes your real email address, while Apple’s private addresses are completely unique and can’t in any way be tied back to your real email address. They’re also much easier to get rid of if you no longer want to use them.
So How Private Is This?
According to Perez, this is considerably more private than the likes of Facebook. It seems that the maximum amount of information that a developer will be able to get from Sign in with Apple is the the name associated with the user’s Apple ID, their verified email address, and a “unique stable identifier” that’s used to associate the sign-in with an account on the developer’s systems — and this is the maximum information that’s available. Some developers may get nothing more than the unique ID, which is an entirely anonymous blob of data, while others may want to know your name, but not care about your email address. Further, even if they want your email address, you’ll always have the option of using a random, anonymized address.
By comparison, Facebook has a huge database of information to share with app developers, and we all know that it has few compunctions about doing so. Apple doesn’t even have most of this kind of data, so there are no “likes” or “friend lists” that Apple could share with developers even if it wanted to.
Where Will It Work?
Apple touted the new feature during its demonstration of iOS 13, but in fact Sign in with Apple will work across the entire family of Apple devices — even on the Apple TV and Apple Watch. You also won’t need to sign up again when moving between devices — even when getting a new iPhone or iPad — as it’s associated with your iCloud account, not your device.
Authentication is handled via Face ID or Touch ID on devices that support it; on other devices it will fall back to the method that’s already used for two-factor Apple ID sign-ins, which sends a six-digit code to a trusted device or phone number.
How Are Private Email Addresses Handled?
Perez makes it clear that the randomized email addresses that Apple creates are merely forwarding addresses, so this means that Apple won’t have access to any email sent through the system (unless they’re forwarding to your own iCloud.com address, of course, but this is subject to the same privacy policies that are already in place for iCloud).
What’s really interesting is that developers will be required to register the domains and email addresses that they will be using to send emails to the users through these private email addresses. These domains must be verified by Apple as being owned by the developer (so they won’t be able to just register something like gmail.com), and each developer can only register a total of 10 domains.
This strongly suggests that Apple’s relay service will only accept emails from those domains that have been registered, although it’s less clear whether this will be a general restriction (i.e. all domains registered by any developer can use any private email address), or whether Apple will actually lock it down on a per-app basis (i.e. a private email address registered by a given app will only accept emails from the specific domains registered by that app’s developer). Either way, however, we’re pretty impressed that Apple has taken this extra step to secure its private email addresses against abuse.
Where Will It Be Used?
Apple has insisted that Sign In With Apple be offered in all apps that currently offer third-party sign-in systems, and has suggested that the option be placed first, although the latter is not a requirement.
This obviously includes the big two — Facebook and Google — but would apply equally to apps that sign in with Twitter, Instagram, Snapchat, or really anybody else.
Developers are not required to use Sign In With Apple, however, if they only offer their own direct sign-in system, although they can certainly do so if they want to.
Moving to Sign In With Apple
For users who have already signed up to a service using their email address, Sign In With Apple will attempt to match accounts by tying into iCloud Keychain and looking for any existing credentials that are stored there. If it finds a match, it will alert you to this and ask if you want to log in with your existing email instead.
Coming from Facebook or Google will be a bit more complicated, as Apple says it’s expecting the developers themselves to address this. Apple has long insisted that developers should offer users a way to opt-out of using social logins, so the ability to do this should already be in most apps — letting users basically switch back to a direct sign-in with only their email address, for example. Once Sign In With Apple launches, developers could offer a direct migration path, or simply let users fall back to a direct sign-in and then make a second switch over to using their Apple ID.
It’s worth noting that Apple hasn’t updated its actual App Store Guidelines for Sign In With Apple yet; only its developer design guidelines have anything to say about the feature, and these are all generally suggestions. We probably won’t know more about the actual rules Apple will be enforcing until closer to the rollout of the feature this fall.