Apple is about to make Hide My Email useless

Original Article ↗ Hacker News Discussion ↗

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.