This article may contain affiliate links. Learn more on our Partner Program page.
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, to bundle two data protection services under a common domainBoth "Sign in with Apple" and "Hide email address" should in future display new addresses under private.icloud.comspend. For the second service, this would have largely negated its protective effect. In a Message to developers Apple has now removed this part – according to its own statement, after further consideration and evaluation of feedback from the community.
Key Facts at a Glance
- Addresses from “Hide email address” remain on
icloud.comand do not switch to their own domain. - The „Sign in with Apple” feature will remain unchanged: New addresses will be available later this year.
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 wishing to block such addresses would have to do so icloud.com Block them completely – and that includes 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 will remain, and new ones will continue to be created under [unclear - possibly " ... icloud.com It creates, and for those unfamiliar with the function: it belongs to iCloud+ and can be used anywhere registration requires an address – the instructions for this are in the manual. “Hide 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.
