Two months after the announcement, Apple is reversing a decision that would have undermined one of the company's most effective privacy services. The reason for this is unusually clear in the announcement.
In June, Apple announced plans to consolidate two privacy services under a single domain: Both "Sign in with Apple" and "Hide your email address" would henceforth issue new addresses under private.icloud.com. This would have largely negated the protective effect of the second service. In a notification to developers, Apple has now removed this part of the plan – according to the company, after further consideration and evaluation of feedback from the community.
Key Facts at a Glance
- Addresses selected from "Hide email address" remain on
icloud.comand do not switch to a separate domain. - For "Sign in with Apple", the change will continue: New addresses will be available later this year at
private.icloud.com. - Existing addresses under
privaterelay.appleid.comwill continue to work and forward messages without interruption. - Users do not need to take any action. Developers need to allow the new domain in their systems.
Why having a separate domain would have weakened the service
The protection offered by "Hide email address" relies on the fact that the generated aliases are not recognizable as such. They reside on the same domain as regular iCloud mailboxes. An online shop that wanted to block such addresses would have to block icloud.com entirely – and thus also all regular iCloud users.
This very protection would have disappeared with a separate domain. An address like private.icloud.com is immediately recognizable as a disposable alias, and a domain-level block would have had no further undesirable side effects. Anyone unwilling to disclose their real address during registration would simply have been rejected in many places.
| Service | Previous domain | Future domain |
|---|---|---|
| Hide email address | icloud.com | icloud.com remains |
| Sign in with Apple | privaterelay.appleid.com | private.icloud.com (new addresses) |
The question is not as pressing with "Sign in with Apple". These addresses were already on a separate, clearly identifiable domain – so the change doesn't worsen anything, it merely rearranges the naming.
A service that has been under observation since the summer
This isn't the first setback for the feature this year. In early July, it was revealed that a security vulnerability could expose the real addresses behind the aliases – revealing precisely what the service is designed to protect against. Apple patched the vulnerability three weeks later.
The domain change would have been the third intervention within a few weeks, but this time it wasn't a mistake, rather a conscious decision. The fact that Apple is reversing it and stating the reason is the real news: reversals happen, but explicitly citing community feedback is rare.
What to do now – and what not to do
Nothing changes for users. Existing aliases remain, new ones will continue to be created at icloud.com, and for those unfamiliar with the feature: it's part of iCloud+ and can be used anywhere registration requires an email address – instructions are available in the guide to "Hide your email address".
On the other hand, action is needed. Apple is reminding developers that account systems, email verification routines, and whitelists must accept the new domain in addition to the existing one. Those who fail to do so will be locked out of users who register using "Sign in with Apple" starting this year.
A practical side effect for everyone sharing iCloud+ within their household: The aliases are linked to the respective Apple account, not the subscription holder. How the service is distributed within a family is described in the iCloud+ Family Sharing overview.
What Apple's retreat reveals about their deliberations
The original plan made perfect sense from a technical perspective. Two related services under one domain are cleaner to operate, easier to document, and more straightforward for developers. What was overlooked, however, was that the unobtrusiveness of this one service isn't a secondary consideration, but rather its very functionality.
From the perspective of readers in this country, the result is the best possible: A service for which you pay with an iCloud+ subscription retains the characteristic that distinguishes it from any disposable address service. If you use the feature, you don't need to do anything – and should continue to use it primarily where an address is only required for registration anyway.
Do you consistently use hidden email addresses when registering for services – or do you prefer to use your real address for services you plan to use regularly? Let us know in the comments where you draw the line.
