Apple is about to make Hide My Email useless

Original Article ↗ Hacker News Discussion ↗

Apple’s plan to move all “Hide My Email” and “Sign in with Apple” addresses onto a new `@private.icloud.com` subdomain is raising concerns that websites will more easily block these privacy-preserving aliases, much like they already do with known disposable email services. Commenters argue this undermines one of iCloud+’s most valuable privacy features, increases ecosystem lock-in, and shifts blame for poor UX from Apple to third‑party sites that may reject such addresses. Others note that determined services were already filtering many aliases and suggest alternatives like custom domains, Fastmail, SimpleLogin, or Proton’s alias features.

What Apple Is Changing

  • Previously, both normal iCloud mail and Hide My Email (HME) aliases were @icloud.com, making them indistinguishable by domain.
  • Apple is moving both Sign in with Apple relay addresses and HME aliases to @private.icloud.com.
  • Legacy @icloud.com / older domains will continue to work and forward mail.

Why This Enables Easier Blocking

  • Many services already block “temporary/anonymous” email domains via domain blocklists.
  • Before: blocking icloud.com would also block millions of legitimate users, so it was impractical.
  • After: services can block private.icloud.com as a “temp/relay” domain while still accepting icloud.com.
  • This is compared to how services banned Mailinator and similar throwaway domains once widely used.

Impact on Privacy and Usability

  • HME is valued for:
    • Hiding the real address and reducing cross‑site correlation.
    • One-alias-per-site tracking of leaks and easy revocation.
  • Many see the change as a “win for trackers,” making HME much easier to refuse and therefore less useful.
  • Some argue determined sites already detect HME patterns, so the change is unnecessary harm.
  • There is confusion but partial clarification that HME addresses can be used to reply, but not for arbitrary “spam.”
  • Concerns about ecosystem lock‑in: hundreds of logins tied to Apple’s relay; uncertainty about behavior if iCloud+ is canceled (reports: aliases still receive, but management/reply may be lost).

Debate Over Real-World Blocking

  • Some think “no reasonable business” will ban Apple’s private domain, especially if it affects affluent Apple users.
  • Others report many examples of alias or privacy domains already blocked (Proton aliases, SimpleLogin, some custom domains, some TLDs, temp services).
  • Clarification: a site can accept Sign in with Apple while still banning @private.icloud.com for manual email signup, so SSO doesn’t fully protect HME.

Alternatives and Workarounds

  • Suggested substitutes:
    • Custom domains with catch‑all or subdomains, often via Cloudflare routing.
    • Alias services like SimpleLogin, addy.io, Fastmail masked email, Proton aliases, sometimes integrated with password managers.
  • Tradeoffs noted:
    • Better portability but weaker privacy herd (unique domain becomes an identifier across leaks).
    • Some services whitelist only big providers or block custom/“weird” domains and certain TLDs.
    • SPF/DKIM/DMARC and forwarding/SRS add technical friction, though some say they’re manageable.

Speculation on Apple’s Motives

  • The rationale is unclear.
  • Theories include:
    • Internal “simplification” or unification of email systems.
    • Protecting Apple mail infrastructure from spam/abuse reputational issues.
    • Bowing to external pressure from anti‑privacy interests.
  • No definitive explanation is given in the thread.