Shestakov documents how the new Hide My Email behavior adds friction to alias creation and management, and crucially removes the property that aliases be indistinguishable from regular emails at the receiving end. He argues this surgically removes the parts power users — developers spinning up throwaway addresses by the dozen — relied on, while leaving the consumer-facing veneer intact.
The editorial frames the HN reaction as 'bitter rather than surprised,' arguing the developer audience inherited Hide My Email by accident and is now watching a familiar pattern play out: a platform ships a clean primitive, niche users build workflows around it, and the vendor walks back the parts that made it useful. The implication is that relying on platform-bundled privacy tools is structurally fragile.
The editorial notes that Hide My Email's heaviest users were 'exactly the people who'd otherwise be running their own catch-all on a custom domain.' The implicit argument is that the workflow these users want — unlimited, fire-and-forget aliases indistinguishable from normal email — is only reliably achievable by owning the domain and mail infrastructure yourself, rather than depending on a vendor's privacy SKU.
Arseniy Shestakov's post "Apple is about to make Hide My Email useless" landed at 482 points on Hacker News on June 16, with a comment thread that read less like outrage and more like a collective groan from people who'd already half-expected this. Shestakov walks through changes Apple is rolling into Hide My Email — Apple's per-site email relay service bundled with iCloud+ — that materially break the workflow most power users actually rely on: generating throwaway addresses by the dozen, using them once, and never thinking about them again.
The service shipped at WWDC 2021 as one of Apple's three flagship iCloud+ privacy features, alongside Private Relay and the custom-domain mail feature. The pitch was simple: when a site asks for your email, tap a button, get a random `@icloud.com` address, and Apple forwards mail to your real inbox. You could disable any alias at any time. It was, for a brief window, the cleanest consumer alias service on the market — no separate account, no extra app, baked into the OS.
The new behavior, as Shestakov documents it, doesn't kill the feature outright — it just removes the parts that made it useful for the audience that adopted it hardest: developers. Aliases that previously felt fire-and-forget now require more friction to create, more friction to manage, and lose the property that mattered most — being indistinguishable from any other email at the receiving end.
Hide My Email was never really a consumer feature. Civilians don't sign up for 40 SaaS trials a year, don't need a clean address for every npm publish account, and don't care whether the sender can tell their email is a relay. Developers do. The feature's most enthusiastic users were exactly the people who'd otherwise be running their own catch-all on a custom domain, and Apple inherited that goodwill by accident.
That's why the HN thread skews bitter rather than surprised. The pattern is by now familiar: a platform ships a privacy feature, developers adopt it because it removes friction, the feature accumulates abuse vectors, and the platform responds by adding friction back until the feature is functionally equivalent to not having it. Google did this with App Passwords. Microsoft did it with local accounts (we wrote about Insider build 26200.5516 patching the `ms-cxh:localonly` workaround twelve hours ago). Apple is doing it with Hide My Email.
The technical reasoning Apple presumably has is real. Free-tier alias services are catnip for spammers, fraudsters, and account-farming operations — and Apple is the largest free-tier alias service in the world by an order of magnitude, because every iCloud+ subscriber gets it. The countermeasure tax is real. But the countermeasure tax is being paid entirely by the legitimate users, which is the universal failure mode of platform privacy features: the abuse mitigation degrades the honest workflow without seriously inconveniencing the determined adversary, who simply moves to the next free service.
Compare the alternatives that didn't get nerfed. SimpleLogin (acquired by Proton in 2022) charges $30/year for unlimited aliases on your own domain. addy.io (formerly AnonAddy) does the same, open-source, self-hostable. Firefox Relay ships free with 5 masks and $0.99/month for unlimited. Fastmail's Masked Email integrates with 1Password and costs nothing extra if you're already a Fastmail customer. Every one of these services that isn't bundled with a trillion-dollar platform's free tier still works exactly as it did three years ago, because their economics don't depend on stopping abuse at the alias layer.
The HN thread surfaces the obvious counter-argument: "just use a custom domain." It's the right answer, and it's also the answer people resist because it implies running infrastructure. But "infrastructure" here is one MX record and a paid mailbox at any provider that supports catch-all addressing. The break-even versus an iCloud+ subscription is roughly zero days.
The practical move, if you've been leaning on Hide My Email for signups, is to stop. Migrate the addresses that matter — anything tied to a recovery flow, a paid subscription, or a deploy key — onto an alias service whose roadmap you can read. The ones that don't matter (forum logins, one-time downloads) can stay where they are until they break, at which point you don't care.
A migration plan that takes about an hour:
1. Audit. Most password managers can filter by email domain. 1Password, Bitwarden, and Apple Passwords all let you list every login using `*@icloud.com`. Sort by "last used" and you'll find that 80% of them are dead accounts. 2. Pick a backend. A custom domain at Fastmail ($5/month, includes Masked Email) or any registrar plus an alias service you control. If you genuinely don't want to think about it, Proton's SimpleLogin Premium is the closest drop-in replacement. 3. Migrate the top 20. Bank, GitHub, npm, AWS, your registrar, your domain DNS provider, your password manager itself, your phone carrier, your cloud storage, your AI subscriptions. Change the email on each, verify, log out, log back in. Everything else can wait. 4. Disable, don't delete. Hide My Email aliases keep forwarding until you turn them off. Leave them live during migration so you catch the slow-moving notification emails (annual renewals, tax docs) you'd otherwise miss.
The deeper lesson, if you want one: a privacy feature you don't host is a feature on loan, and the lender can change the terms. Hide My Email was a beautiful loan. It is also, predictably, getting recalled.
Watch for two things in the next quarter. First, whether Apple publishes any official changelog acknowledging what changed — the absence of one is its own signal, and so far the changes have been documented by users rather than Apple. Second, whether SimpleLogin and addy.io see a spike in signups; both publish rough growth numbers, and a visible bump would confirm Shestakov's read isn't just a vocal minority. The longer-term question is whether any of the big three (Apple, Google, Microsoft) ever ship a privacy primitive that survives contact with abuse at scale — the track record so far suggests the answer is no, and the workaround is the same workaround it's been since 1998: own the domain, run the catch-all, accept that the convenience tax of self-hosting is the price of features that don't get unilaterally downgraded.
> If you use iCloud+ and Hide My Email, there is still time to generate more aliases on @icloud.com as the change has not yet landed and the rate limit for creating aliases is at least 30 per hour.Part of the reason to use Hide My Email was that it made keeping myself private hassle-free. Making
Hide My Email is fundamentally broken in two major ways:1. Services those emails are used with cannot unilaterally send email to them. They must pre-register how they will send email to them, which breaks services with third-party relationships such as online retail with payment processors or shippi
Pro tip for doing something like this without apple. Buy or get a cheap domain name. Create a subdomain on it and have it catch and forward all messages to you when sent to that sub. For example:nytimes@mailsub.example.com -> jono@gmailanything-else@mailsub.example.com -> jono@gmailYou dont ev
> Long story short: now both Sign in with Apple and Hide My Email aliases are going to be issued on the @private.icloud.com subdomain. This makes it much easier to ban all aliases without affecting non-relay mailboxes on iCloud mail.Could someone clarify why having Sign in with Apple and Hide My
Top 10 dev stories every morning at 8am UTC. AI-curated. Retro terminal HTML email.
If your website will block me out because I used a privacy friendly email, I want nothing to do with your website.