Yes but not always applicable unfortunately… e.g. the other day I was in Italy, I needed to park on the publicly available parking which was paid to the municipality.
No other parking available anywhere near in 30 mins walking distance. (paid or free)
I had to download a 3rd party app that asked me to register. This app isn’t by the Italian government, it’s affiliated though.
So in that situation, I want nothing to do with your website or app, because I wouldn’t able to park.
Can you not pay with cash or card anywhere? What if you don't have a "smart" phone? I would categorically refuse to park anywhere that requires running a proprietary app on my device. Fortunately, in the States at least, I have not encountered such a place yet.
Sometime ago I had to pay for parking to get access to a hiking trail (in US). The way to pay for parking was shady as hell. Just a random QR code sticker on the wall that said "pay here" that navigated to a payment portal that asked for your CC, address, license plate. I mentioned to my friend who was with me, "anyone could really just put any sort of QR code here and navigate you to a fake payment portal and steal your CC"
But like you said, what are you supposed to do otherwise?
I think in most countries the only way to challenge this kind of thing is to park illegally and then go to court and claim it was impossible for you to park legally. Which is a hard process, on purpose.
It's precisely when I want "nothing to do with your website" that I want to use a private friendly email if I'm nonetheless forced to interact with it...
I ran into this with an NVMO mobile provider. They did not like my personal email domains (assorted .net and .org) so I nagged their customer support until they manually added it. Their marketing team happily emails my personal domains once added. Some day this will probably cause a problem but my goal is to eventually get rid of my cell phone either way.
As of about six months ago, AT&T's web site would not accept email addresses without a three-character TLD. I had to get a customer service person on the phone to manually change my address.
I frequently buy a domain that I think is funny and use that to forward all my emails to my main email account. It's trivial to do from Cloudflare. Then after that 1 year is up, my domain goes away and so does all of the spam.
Completely agree - have you encountered this before? The Gmail plus sign alias trick has been widely known for a long time and, to my knowledge, still works well today. It would be easy enough for websites to either block + in gmail addresses or instead grab the true email.
Some sites that block "+" in email addresses are actually just doing it out of incompetence. My credit union, for example, will actually accept an address with a "+" in it, but nothing will work because some broken bit of web 1.0 plumbing along the way converted it to a space (it shows up that way on my profile page). I wouldn't be surprised to see " " on my printed bank statements.
Gmail also have "googlemail.com" alias and you can split your username with dots since they dont count like "user@gmail.com" and "u.s.e.r@gmail.com" are the same thing,
I used to run a hybrid mobile app + webapp company.
Private emails regularly lead to awful customer service interactions because people cannot tell us the email they used to register. Fastmail at least is off the beaten path enough that people probably can understand. Apple, especially using sign in with Apple, is horrid. And not just people unable to tell us the email; they then create multiple accounts; try to sign in on web and use their actual email and then have 2 accounts and flip shit that their stuff is gone; etc. Oh, and regularly blame us for their confusion.
ChatGPT doesn’t allow private relay and hasn’t allowed it since launch may be. So it’s not always possible to not use them, of course now there is no need to use ChatGPT and I have just stopped and moved on from it
Didn't really have a choice with openrouter. I ended up using "Hide My Email" which gave me an icloud.com, which will likely no longer work according to this article.
> If you insist on giving me a fake email, your business is probably a liability I don't want anyway
It's not a fake e-mail, it's a legitimate e-mail that you can send e-mail to and the user will receive, which has to be created by a paying iCloud user and not an anonymous rando off the internet.
I'd be interested to know what downsides, if any, you see for a website to accept a private e-mail address like this. Do you have a legitimate complaint about these sorts of e-mails? Again, given that private relay isn't an 'anonymous e-mail service' (it's still tied to your iCloud account so spam, etc. shouldn't be any more of an issue) but merely an 'anonymous to the person you're giving the e-mail to' service.
If your actual complaint is 'if you insist on giving me an e-mail that you can revoke unilaterally making me unable to contact you against your wishes, and which cannot be associated with other user data from other sources to build a profile of you, then you're not worth having as a customer' then that's a separate complaint - and one that means I want nothing to do with your website.
As others have alluded to, I'm not doing this to be anonymous, I'm doing this because companies can't be trusted not to leak my email address. Every real business that knows my real identity (banks, payroll, government, retailers, etc.) gets its own alias.
When an organization invariably leaks my email and I start receiving spam to it, I generate a new one, update my email on record, deactivate the old one, and the spam stops.
Seems like we have a meeting of the minds here. You don't want me as a customer and I don't want you as a vendor (or payment processor). Enjoy your spamming :)
> 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 a system to pre-generate values and then catalog them for later use is quite the hassle.
You can sort of do this today with iCloud. Add a custom domain and enable the catch-all forwarding, and you can receive anything@domain.tld and it’s forwarded to you.
What you’d lose is the reply-to forwarding feature.
If you mean "set up an equivalent service" under your own domain, that's both less private and more likely to be blocked; there are a lot of services which, unfortunately, only allow sign-ups from big, well-known domains.
It's E2EE (only if you turn it on, which you can't do in the UK) but it saves (non-encrypted) the hashes of the plaintext of the files to Apple (presumably for dedup).
This allows Apple to see which sets of users share unique Winnie the Pooh memes. They know who had them first, who they sent them to, and when.
The E2EE is useless with such unencrypted metadata leaks.
I pay for the bundle, but HME was never hassle-free. I would say that it works on ~40% of form fields. Most of the time I never get the prompt from HME.
It’s also might obnoxious if you ever need to remove an email from that list (or, gods forbid, mass clean the list).
But okay, this update is even worse. I might just stop paying for the iCloud+ whatchamacallit and backup to my Mac like I used to.
Yeah, I have several dozen already—I suppose I can reuse those forever… I guess it's kind of cool having one-per-site though so you can tell who the "rat" is when one of your hide-my's gets spammed.
I have over 300 so far. In addition to knowing where spam is coming from, and being able to block it, it also helps prevent correlation across accounts and websites as data leaks occur.
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 shipping companies.
Users don't like not receiving shipping notifications, and users don't like not seeing invoices or at worst missing bills and going into debt because the payment processor can't contact them.
2. Users signing up for services struggle to re-use accounts. If the account is identified by email, as most are, figuring out the private email used when you signed up on your iPhone, when you later try to sign in on the web, basically impossible for your average user. Users end up with mulitple accounts, likely one on their real email anyway, and it's a support nightmare for both the user and the service provider.
Does this increase user privacy? Yes. Does it increase user control? Sure I guess. But it does so at the cost of basic UX and service expectations, and likely makes the overall experience and control worse for users in many cases.
So why is this change being made? My take is that it's so that it's easier for services to exclude Hide My Email sign-ups. That way the bad UX is gone, and the service provider looks like the bad guy rather than Apple.
> 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 shipping companies.
You're talking about "Sign in with Apple" email addresses here, not Hide My Email. Anyone can send to Hide My Email addresses.
If you have iCloud Keychain enabled you don't have to "remember" a sign-in at all. Flip a toggle, say "Yes" when Safari offers to remember the new password you generated for the fake email you generated in a drop down menu, and you're a FaceID/TouchID away from auth. My 80 year old uncle can manage this.
I have been a happy Hide My Email user for years. This is simply not a problem, and even for normies it's no more a problem than "can't remember password at all".
For now I think Hide My Email is for power users! It's on the user side to manage their identities. My current workflow:
- Label Hide My Email with the service name I registered with it. Add number or nickname if I have multiple accounts on that service.
- Add an email rules to move the email addressed to that Hide My Email addressuu to a separate inbox.
- Use the same label in password manager, also save the email to the password manage entry.
> For now I think Hide My Email is for power users! It's on the user side to manage their identities. My current workflow:
> - Label Hide My Email with the service name I registered with it.
I think the ‘normal’ way to do it is way simpler:
- a site asks for an email address
- click “Hide My Email”
- use Apple’s flow to create a new email address
- use Apple’s flow to pick a password
- phone or Mac automatically associates the email address with the site and stores the password in the KeyChain
AFAICT, the only thing that doesn’t do that you describe is “Add an email rules to move the email addressed to that Hide My Email address to a separate inbox”.
I think that’s orthogonal to using Hide My Email, though. If you want that, you likely would do the same for mail from the site’s domain.
I appreciate this ends up as your problem when it shouldn't be, but it feels so self-inflicted; someone using a privacy email has declared they don't want to receive email, so they shouldn't be surprised when .. they don't receive a shipping notification email.
I've received emails to my HME address from third parties. Bought something from Shop A, got the email confirmation from them, later got the shipping notification from Courier B, all to the same HME address.
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:
The problem is if someone figures it out and starts sending you spam to {random}@domain.tld. That's when you will need to sit down and start creating actual aliases for all those used email addresses and stop the catch-all forwarding:)
Also, another downside is that you will loose privacy by using your own domain.
And the lack of privacy makes targeted scam/phishing more likely, and targeted scam is the one we are most susceptible to.
All in all, I am not saying this is bad idea, in fact I am doing it myself, just pointing out this is not so black and white.
Using iCloud solves those problems, but puts you at risk of getting your account banned and loosing access to those emails, so there is that.
Probably best way to deal with it is to get dedicated email domain with a bunch of your friends, and hook it up with something like SimpleLogin. But that's gets complicated quickly ;)
I have run this for years with very little problems. And I can honestly say that have not found anyone writing to addresses I did not give them at their domain. Simple as this is, it is way to niche for companies to figure it out and exploit it. And if that really was a problem I'd just create a new subdomain.
If you are worried about privacy, get a domain just for this. Use domain privacy and dont host other things there.
Yes, some sites whitelist domains or dont allow subdomains. For those I'll use another account - or a firefox alias or something. But 9 out of 10 work fine.
I am not a fan of alias services since materializing names takes discipline. How many do you make? Maybe there is a limit of 50. When do you share them across services? My guess is many people just create 2 or 3 aliases they use for everything - which defeats the purpose. Sure, it masks your personal address, but once one gets compromised, you find it basically served as your personal address anyway.
I also dont really keep track of most of the names I use. Since most are one time things that I would never use again, like to sign a waiver or something. But I mostly stick to '{domain}@' for the names. So my nytimes account would just be nytimes@, which is predictable when I need to recover it. I used to use addy.io for this, but it was not as good since it had account limits and I had to manually manage every alias. Much easier for me to just create a mail filter to sinkhole an old name. Of course I have never really needed to do this anyway.
I've found using a subdomain helps with that, spammers will try everything@domain.tld but won't bother trying to brute force subdomains.
However be warned some surprisingly large websites don't support subdomains, for example eBay will silently send user@sub.domain.tld to user@domain.tld and you'll only figure it out by looking at your server logs for rejected mail.
In those cases I have to specifically alias that username@domain.tld to the subdomain.
With this new Apple privacy subdomain maybe eBay will finally fix this.
> The problem is if someone figures it out and starts sending you spam to {random}@domain.tld.
It's a non-issue. I've been using a catch all domain for at least a decade. I get a small amount of spam to random made up emails but not enough to care about plus it all gets caught and filtered.
I do this. The awkward thing is when I am in person or on the phone and have to explain that my customer email address is [their_business_name]@my_weird_domain.tld
But the people usually just nod along.
The other downside is that it's forward-in only, wish I could proxy responses without setting up a whole new inbox (and outbox).
> The only awkward thing is when I am in person or on the phone and have to explain that my customer email address
I had one small business aggressively threaten me that they fully owned their business name and I wasn't allowed to use it in my email address.
My solution was to keep my wonderful aliases and dump them. If a business is concerned but nice about it I'll offer an alternative such as plumber@
> The other downside is that it's forward-in only, wish I could proxy responses without setting up a whole new inbox (and outbox).
If you have your own domain most mail providers don't care what username@ you use on your sent mail so you shouldn't need any additional mailboxes (especially if they already offer inbound catch all)
I also use the ReplayAsOriginalRecipientUp [1] extension in Thunderbird which takes the recipient address and puts it as the sender for ongoing communication.
So I guess I'll take a moment and plug my email provider, Fastmail. Their integration with 1Password to enable creation of Masked Email at account creation time is really fantastic! I have several hundred of these at this point, it's made my digital life appreciably better.
But to the point of forward-in-only -- I use the fastmail web client and iOS client. Both of these respond using the Masked Email address if you choose to respond to an email. In fact I can choose any of my masked email addressed as I am composing mail to initial communication from that address.
In short, "it just works". I really can't say enough good things about Fastmail!
Just happened to me today! I was at the Verizon store and my address was verizon@... Sometimes it leads to confusion, but sometimes it leads to getting extra special treatment actually! They think I'm someone important.
I do something similar, use an open source service called addy.io, bought a domain but you can also use their domains too, and each website has a separate login i create through bitwarden with the addy integration.
This lacks the easy control over blocking the “aliases” you’re done with.
The real pro tip is to use this domain with something like addy.io (paid or self-hosted) where you can either pre-create the aliases or have them dynamically created for you as they become used for the first time - and having control over each of them so you can block it when you want.
I have never had to do this in my years of using this scheme. And if I did, I would create an email filter. Which I consider to be more standard and scalable then managing a bunch of individual aliases.
This is absolutely not difficult to get right. Run OpenDKIM and OpenDMARC on your server along with your email stack (I use Postfix and Dovecot). Use a tool such as mail-tester.com to verify compliance.
> 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 Email on the same domain would make a blanket ban easier rather than harder? What am I missing?
Before, the emails were "me@icloud.com", the default for all apple users. There was no way to distinguish normal emails from generated private emails.
Now, they will be "blah@private.icloud.com", so it will be easy to ban the generated/private email that reduces the ability to associate logins across services.
Unclear why Apple would shoot themselves in this way; I hope it's not Ternus complying with anti-privacy.
I've been in the ecosystem long enough to have .iCloud.com, .me, .mobileme.com, iTunes.com, and probably one or two more addresses all assigned by various Apple services over the years before they started unifying the systems.
They all work, and independently of one another.
I wonder if all the domains will be migrated, and how namespace collisions will be handled.
maybe to avoid getting their legitimate email servers banned by other servers since they host (i.e. being exploited) a growing number of spam accounts.
I see – somehow the Apple UI for this gave me the mistaken impression that privaterelay.appleid.com was the domain used by the alias, but I see now that it was always just icloud.com.
Apple was generating (something)@icloud.com whenever you used that service.
Now, it will use (something)@private.icloud.com instead. So you can ban this subdomain instantly, knowing people will be "hiding" with this service by default.
It's like blocking anondaddy, simplelogin etc but not protonmail.
I guess their thought process is, both alias and non-alias accounts use @icloud.com
You were always able to reserve a normal icloud email address just like you would a GMail account, so banning all icloud email addresses would be banning non-alias Apple customers
That being said, I'm not convinced anyone who wanted to ban aliases couldn't have already. The alias emails look weird enough I'm guessing you could ban them with few false positives.
I highly recommend either SimpleLogin or Fastmail aliases. The latter are superior because they can be used to reply directly to any received email without needing to set up reverse aliases.
When you own your own domain, the switching cost between providers is small. You can make a dedicated domain just for aliases
Both SimpleLogin and Fastmail have excellent integration with password managers as well
"Useless" is a leap. The kind of site that would block private relay emails is the kind that was already getting my burner anyway. The private relay is for sites I want to hear from, but also want a failsafe in case they're hacked later.
Nothing breaks when you switch. You just can't create more private icloud addresses. I recently switched back to Android and can still use my old icloud logins.
Does it? I use Hide My Email largely without integration to the Apple ecosystem - I generate new emails on icloud.com and copy/paste them to login forms before saving to 1Password.
This is one reason I never used it, but another reason is that I never felt that the privacy benefits were worth the hassle of randomized emails.
If I need to make an account with someone I don't trust enough to hand my email over to, usually the right answer is to just not create an account with them.
I have also tried things like having email aliases but what ends up happening is now I have more email accounts aliases to maintain/think about. It's annoying.
I don't personally find the prospect of "receiving spam email" or "having my email account leaked in a hack" to be particularly threatening. Spam just goes to the spam box, it's usually not my problem.
And besides, my real email can get exposed by my own legitimate companies that really should have my real email getting hacked. See also: EquiFax.
Like yes that, but also. Why would I want to hide my email from someone but not from Apple? And why can’t I turn it off and choose not to hide my email? This is one of my top Apple ‘features’ that would make me migrate away, if not for android being similarly awful
Determined sites could already easily do this. Just detect the patterns used. I agree it's a useless change though.
heave_balks_0g@icloud.com
It shouldn't matter for the sign in with apple because sites are already expressly supporting that.
Email aliasing is hard because you want privacy from a herd of users, but then you're locked into that ecosystem versus a domain you control has no herd, but the upside is no lock-in.
I use Proton aliases everywhere...Well not everywhere, there are indeed quite some places that don't accept a passmail.net address... So I can imagine this becoming a useless feature, at least on some sites.
Btw I only use these aliases for sites where I don't mind loosing the login, otherwise it would the mother of all lock-ins... Would have been nice if I could opt for aliases on my own (secondary?) domain... At least then I could still move them (using wildcards or some exported list).
In the flip side, someone who blocks private.iCloud.com will block the ability to do SSO with Apple, thereby cutting themselves off from Apple’s ecosystem.
Not really. You could allow private.icloud.com only if they're using Apple's SSO. If someone tries to create an account not using Apple's SSO, then you don't allow private.icloud.com email addresses.
Almost all of my iCloud relayed addresses are already @privaterelay.appleid.com, and they've been working perfectly. So I don't expect this to change any time soon.
You can use Hide My Email on any website though, whereas Sign In with Apple is limited to just those websites and apps that support it. Sign In with Apple isn't nearly as popular on the web, so it's a lot easier to just ban "@private.icloud.com" from your web service there.
Hide My Email isn’t particularly related to apps. You can use it on any web form that asks for your email address, or as the sender of any email message you send using Apple Mail.
> They already require that you use Sign in with Apple, I would think that it working fully is also a requirement?
They require apps offer a service which meets their privacy requirements if they use any 3rd party or social login service.[1] And apps could block private.icloud.com for email and not Sign in with Apple.
Shameless plug - I created a chrome extension that allows to create unique email addresses that forward to your real inbox. It uses Cloudflare email routing, simplifies creating/labeling of new addresses and keeping track of them. Always 1 click away.
The addresses are pre-allocated and recycled when deleted so creating a new one is faster that with Apple's hide my mail.
With cloudflare you can also just setup catch-all and be done wirh it.
I personally doing catch-all already, but problem is that using your own domain for website registration basically gives everyone unique id to eaaily connect all the information that ever been leaked for your accounts and something always gets leaked.
Because many sites check the domain part of your email address against a blocklist, which contains entries like trashmail.com to prevent users from signing up with ad-hoc throwaway accounts. They don't want that, because they'd like to get a proper lead they can either track, sell, or reach out to.
Now Hide My Email allowed you to do just that: Create an account with an email that wasn't tied to your identity, and that you could just decommission if you didn't need it anymore. Sites had no way to detect these either, because all of the randomly generated addresses Apple provided you with just ended in @icloud.com, which is also used by tons of regular accounts - so if you blocked this domain, you'd invariably preclude millions of people from your service.
But by separating the domains, sites can simply add private.icloud.com to their trash mail blocklist, preventing the use of Hide My Email, while regular @iCloud.com addresses will continue to work. It makes the entire service useless at once.
Right now it’s the same @icloud.com domain as normal personal emails. Now all auto-generated emails will use a separate domain name, so sites can block emails with that domain, without worrying about blocking people’s main personal email.
Websites block certain throwaway email domains from signups. The concern is that this will happen with private.icloud.com
A good example of a throwaway email that is now useless because of these blocks is mailinator.com. Originally, you could just make up a random email on the spot like gregsrightfoot@mailinator.com, visit mailinator.com, and get the needed signup verification email. These services autodeleted messages and required no signup so they were a black hole for spam. However websites eventually got wise that their spam wasn’t being seen and started blocking the domain. Mailinator came up with alternative domains and there was a brief back and forth before the throwaway email domains all ended up being blocked.
I guess I'll go back to mailinator. That thing has 100s of aliases by the way for some that don't use that yet. Great service. Not guaranteed private really so don't depend on it for that. (Though if you use a strong has for a hash@mailinator.com address, is it pretty secure for "email purposes"?)
That was always opt-in from the sites, and many never bothered - me included, because I refuse to pay Apple $99 per year for the privilege to offer easier authentication to their users.
I frequently run into scenarios where it won't let me generate the email within 1password on a website, and I have to go to Fastmail and then manually do it. Is this something you have bene able to work around?
I wonder if the existing hidden emails I already have in iCloud will be changed over too. If that's not the case, I'm just going to use one of the 50 throwaway addresses I already have.
The announcement the article linked said Existing addresses on the legacy domains will continue to work and forward mail to users without interruption.
Fastmail still generates theirs with @fastmail.com. And 1Password has an integration with them to quickly generate an address when creating a new account somewhere.
email isn't really a decentralized system at all. Google, Microsoft and Amazon own e-mail delivery. Perhaps Google ads customers complained that they could not correlated private @icloud addresses, and we are now witnessing the consequences. What Apple got in exchange from Google, I don't know, I'm sure it is related to their Siri deal.
Come on. Most likely this is just a result of some manager pushing for "improvement": "Why we have two different privacy email alias systems? Lets make unified one, save on maintenace and I get promotion".
And might be there just no one remain as owner of feature to explain them why its bad idea.
Oh fuck. I love Hide My Email and it's been the best feature about iCloud ever since it came out.
It's actually useful compared to Gmail's useless "yourrealaddress+alais" that gives away your actual email anyway, and it helped me catch quite a few spammers/data sellers.
Hide My Email addresses already have a peculiar format that others could guess, and some do block those, and there's no reason to add a blatant "private." tag.
This is a win for privacy-intruders, not users, just like Apple's iCloud Keychain API that has allowed Facebook, TikTok etc. to secretly track users across multiple devices and device reinstalls for years.
It all dates back to the Andrew Messaging System at CMU, developed in the 1980's. Originally the format was "<username>+<keyword>+<args>@example.net" where the mail server would interpret the keyword and arguments to route the message in whatever unique way that keyword would dictate (e.g. bob+dist+~/mailinglist@example.net would read the file mailinglist in Bob's home directory and deliver the email to addresses listed in it). If the keyword was not recognized, it would just deliver normally. So bob@example.net and bob+alias@example.net were equivalent, and could be used to filter after the fact if desired.
simplelogin from Proton works great, can recommend; for Uber I generate uber.random-word@simplelogin.com, for Slack slack.random-word etc to easily see who leaked my email
Where do I sign to show my opposition to this change? Hide My Email has been essential to keep my digital life protected from abusive mail lists and frankly one of the features that make me associate icloud with a premium service
This is so dumb. They randomly generate them anyways it’s not like they are likely to collide with other users. They should allow you to use your own domain for private relay but it doesn’t let them build a moat so they wont
If your website will block me out because I used a privacy friendly email, I want nothing to do with your website.
Yes but not always applicable unfortunately… e.g. the other day I was in Italy, I needed to park on the publicly available parking which was paid to the municipality.
No other parking available anywhere near in 30 mins walking distance. (paid or free)
I had to download a 3rd party app that asked me to register. This app isn’t by the Italian government, it’s affiliated though.
So in that situation, I want nothing to do with your website or app, because I wouldn’t able to park.
Have exactly the same situation with parking in Italy. Having a private company operating all paid parking on an island is not very healthy.
7 replies →
Can you not pay with cash or card anywhere? What if you don't have a "smart" phone? I would categorically refuse to park anywhere that requires running a proprietary app on my device. Fortunately, in the States at least, I have not encountered such a place yet.
19 replies →
Sometime ago I had to pay for parking to get access to a hiking trail (in US). The way to pay for parking was shady as hell. Just a random QR code sticker on the wall that said "pay here" that navigated to a payment portal that asked for your CC, address, license plate. I mentioned to my friend who was with me, "anyone could really just put any sort of QR code here and navigate you to a fake payment portal and steal your CC"
But like you said, what are you supposed to do otherwise?
2 replies →
I think in most countries the only way to challenge this kind of thing is to park illegally and then go to court and claim it was impossible for you to park legally. Which is a hard process, on purpose.
3 replies →
tutanota.com protonmail.com
create a burner for when ‘not always applicable unfortunately’
4 replies →
you can pay at the parking meters directly, no need for a 3rd party app
1 reply →
Unfortunately sometimes we are at some specific provider’s mercy for whatever reason like lack of appropriate alternatives.
COUGHredditCOUGH
21 replies →
It's precisely when I want "nothing to do with your website" that I want to use a private friendly email if I'm nonetheless forced to interact with it...
I ran into this with an NVMO mobile provider. They did not like my personal email domains (assorted .net and .org) so I nagged their customer support until they manually added it. Their marketing team happily emails my personal domains once added. Some day this will probably cause a problem but my goal is to eventually get rid of my cell phone either way.
I ran into this with an NVMO mobile provider.
As of about six months ago, AT&T's web site would not accept email addresses without a three-character TLD. I had to get a customer service person on the phone to manually change my address.
10 replies →
I frequently buy a domain that I think is funny and use that to forward all my emails to my main email account. It's trivial to do from Cloudflare. Then after that 1 year is up, my domain goes away and so does all of the spam.
And the not spam?
1 reply →
Completely agree - have you encountered this before? The Gmail plus sign alias trick has been widely known for a long time and, to my knowledge, still works well today. It would be easy enough for websites to either block + in gmail addresses or instead grab the true email.
Some sites that block "+" in email addresses are actually just doing it out of incompetence. My credit union, for example, will actually accept an address with a "+" in it, but nothing will work because some broken bit of web 1.0 plumbing along the way converted it to a space (it shows up that way on my profile page). I wouldn't be surprised to see " " on my printed bank statements.
1 reply →
Gmail also have "googlemail.com" alias and you can split your username with dots since they dont count like "user@gmail.com" and "u.s.e.r@gmail.com" are the same thing,
Nothing of it solves privacy though.
Spammers know to just cut out the +whatever. It's a simple regex to keep those from even getting into a database.
5 replies →
Guess what? There are some dumb website or applications complaining that the email address is invalid.
I used to run a hybrid mobile app + webapp company.
Private emails regularly lead to awful customer service interactions because people cannot tell us the email they used to register. Fastmail at least is off the beaten path enough that people probably can understand. Apple, especially using sign in with Apple, is horrid. And not just people unable to tell us the email; they then create multiple accounts; try to sign in on web and use their actual email and then have 2 accounts and flip shit that their stuff is gone; etc. Oh, and regularly blame us for their confusion.
It’s up to the app architect to make a way to make this work, and to stop using emails as anything other than a UUID type of token
7 replies →
ChatGPT doesn’t allow private relay and hasn’t allowed it since launch may be. So it’s not always possible to not use them, of course now there is no need to use ChatGPT and I have just stopped and moved on from it
Didn't really have a choice with openrouter. I ended up using "Hide My Email" which gave me an icloud.com, which will likely no longer work according to this article.
I guess you don't use github. It won't let you sign up with @airmail.cc.
It's pretty common. Shopify blocks my email aliases. So does ikea
That's probably WHY you're using a privacy friendly email.
So...
If your website needs an email address at all.. otherwise just use null@null.null, if it accepts and doesn't require a authentication code
[flagged]
> If you insist on giving me a fake email, your business is probably a liability I don't want anyway
It's not a fake e-mail, it's a legitimate e-mail that you can send e-mail to and the user will receive, which has to be created by a paying iCloud user and not an anonymous rando off the internet.
I'd be interested to know what downsides, if any, you see for a website to accept a private e-mail address like this. Do you have a legitimate complaint about these sorts of e-mails? Again, given that private relay isn't an 'anonymous e-mail service' (it's still tied to your iCloud account so spam, etc. shouldn't be any more of an issue) but merely an 'anonymous to the person you're giving the e-mail to' service.
If your actual complaint is 'if you insist on giving me an e-mail that you can revoke unilaterally making me unable to contact you against your wishes, and which cannot be associated with other user data from other sources to build a profile of you, then you're not worth having as a customer' then that's a separate complaint - and one that means I want nothing to do with your website.
15 replies →
As others have alluded to, I'm not doing this to be anonymous, I'm doing this because companies can't be trusted not to leak my email address. Every real business that knows my real identity (banks, payroll, government, retailers, etc.) gets its own alias.
When an organization invariably leaks my email and I start receiving spam to it, I generate a new one, update my email on record, deactivate the old one, and the spam stops.
> fake email
Its a real address that I can use to monitor your behavior, since businesses send so much damn spam.
Been using them for 25 years, not gonna stop any time soon.
There's nothing "fake" about the email. It's just an alias made specifically for each recipient.
1 reply →
Seems like we have a meeting of the minds here. You don't want me as a customer and I don't want you as a vendor (or payment processor). Enjoy your spamming :)
> 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 a system to pre-generate values and then catalog them for later use is quite the hassle.
If you don't mind trusting another company with forwarding your emails, it's definitely less hassle to set up an equivalent service for yourself.
You can sort of do this today with iCloud. Add a custom domain and enable the catch-all forwarding, and you can receive anything@domain.tld and it’s forwarded to you.
What you’d lose is the reply-to forwarding feature.
If you mean "set up an equivalent service" under your own domain, that's both less private and more likely to be blocked; there are a lot of services which, unfortunately, only allow sign-ups from big, well-known domains.
39 replies →
Yep, but I still generated some for myself just in case and fellow hackers can do the same if they want to.
iCloud+ was the best $1 / month custom domain email and email alias service with 100GB of E2EE cloud drive.
Obviously it will be sad to see it enshittified for seemingly no reason.
It's E2EE (only if you turn it on, which you can't do in the UK) but it saves (non-encrypted) the hashes of the plaintext of the files to Apple (presumably for dedup).
This allows Apple to see which sets of users share unique Winnie the Pooh memes. They know who had them first, who they sent them to, and when.
The E2EE is useless with such unencrypted metadata leaks.
https://www.youtube.com/watch?v=tL8_caB35Pg
3 replies →
[flagged]
5 replies →
I pay for the bundle, but HME was never hassle-free. I would say that it works on ~40% of form fields. Most of the time I never get the prompt from HME.
It’s also might obnoxious if you ever need to remove an email from that list (or, gods forbid, mass clean the list).
But okay, this update is even worse. I might just stop paying for the iCloud+ whatchamacallit and backup to my Mac like I used to.
Yeah, I have several dozen already—I suppose I can reuse those forever… I guess it's kind of cool having one-per-site though so you can tell who the "rat" is when one of your hide-my's gets spammed.
I have over 300 so far. In addition to knowing where spam is coming from, and being able to block it, it also helps prevent correlation across accounts and websites as data leaks occur.
we need s script to make date aliases for the next 10 years so one has a email for each day
is it possible to automate this
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 shipping companies.
Users don't like not receiving shipping notifications, and users don't like not seeing invoices or at worst missing bills and going into debt because the payment processor can't contact them.
2. Users signing up for services struggle to re-use accounts. If the account is identified by email, as most are, figuring out the private email used when you signed up on your iPhone, when you later try to sign in on the web, basically impossible for your average user. Users end up with mulitple accounts, likely one on their real email anyway, and it's a support nightmare for both the user and the service provider.
Does this increase user privacy? Yes. Does it increase user control? Sure I guess. But it does so at the cost of basic UX and service expectations, and likely makes the overall experience and control worse for users in many cases.
So why is this change being made? My take is that it's so that it's easier for services to exclude Hide My Email sign-ups. That way the bad UX is gone, and the service provider looks like the bad guy rather than Apple.
> 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 shipping companies.
You're talking about "Sign in with Apple" email addresses here, not Hide My Email. Anyone can send to Hide My Email addresses.
If you have iCloud Keychain enabled you don't have to "remember" a sign-in at all. Flip a toggle, say "Yes" when Safari offers to remember the new password you generated for the fake email you generated in a drop down menu, and you're a FaceID/TouchID away from auth. My 80 year old uncle can manage this.
I have been a happy Hide My Email user for years. This is simply not a problem, and even for normies it's no more a problem than "can't remember password at all".
It’s a problem if you use non-Apple devices as well as Apple devices.
1 reply →
For now I think Hide My Email is for power users! It's on the user side to manage their identities. My current workflow:
- Label Hide My Email with the service name I registered with it. Add number or nickname if I have multiple accounts on that service. - Add an email rules to move the email addressed to that Hide My Email addressuu to a separate inbox. - Use the same label in password manager, also save the email to the password manage entry.
> For now I think Hide My Email is for power users! It's on the user side to manage their identities. My current workflow:
> - Label Hide My Email with the service name I registered with it.
I think the ‘normal’ way to do it is way simpler:
- a site asks for an email address
- click “Hide My Email”
- use Apple’s flow to create a new email address
- use Apple’s flow to pick a password
- phone or Mac automatically associates the email address with the site and stores the password in the KeyChain
AFAICT, the only thing that doesn’t do that you describe is “Add an email rules to move the email addressed to that Hide My Email address to a separate inbox”.
I think that’s orthogonal to using Hide My Email, though. If you want that, you likely would do the same for mail from the site’s domain.
1 reply →
I appreciate this ends up as your problem when it shouldn't be, but it feels so self-inflicted; someone using a privacy email has declared they don't want to receive email, so they shouldn't be surprised when .. they don't receive a shipping notification email.
I've received emails to my HME address from third parties. Bought something from Shop A, got the email confirmation from them, later got the shipping notification from Courier B, all to the same HME address.
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@gmail
anything-else@mailsub.example.com -> jono@gmail
You dont even need to materialize aliases at all.
The problem is if someone figures it out and starts sending you spam to {random}@domain.tld. That's when you will need to sit down and start creating actual aliases for all those used email addresses and stop the catch-all forwarding:)
Also, another downside is that you will loose privacy by using your own domain.
And the lack of privacy makes targeted scam/phishing more likely, and targeted scam is the one we are most susceptible to.
All in all, I am not saying this is bad idea, in fact I am doing it myself, just pointing out this is not so black and white.
Using iCloud solves those problems, but puts you at risk of getting your account banned and loosing access to those emails, so there is that.
Probably best way to deal with it is to get dedicated email domain with a bunch of your friends, and hook it up with something like SimpleLogin. But that's gets complicated quickly ;)
I have run this for years with very little problems. And I can honestly say that have not found anyone writing to addresses I did not give them at their domain. Simple as this is, it is way to niche for companies to figure it out and exploit it. And if that really was a problem I'd just create a new subdomain.
If you are worried about privacy, get a domain just for this. Use domain privacy and dont host other things there.
Yes, some sites whitelist domains or dont allow subdomains. For those I'll use another account - or a firefox alias or something. But 9 out of 10 work fine.
I am not a fan of alias services since materializing names takes discipline. How many do you make? Maybe there is a limit of 50. When do you share them across services? My guess is many people just create 2 or 3 aliases they use for everything - which defeats the purpose. Sure, it masks your personal address, but once one gets compromised, you find it basically served as your personal address anyway.
I also dont really keep track of most of the names I use. Since most are one time things that I would never use again, like to sign a waiver or something. But I mostly stick to '{domain}@' for the names. So my nytimes account would just be nytimes@, which is predictable when I need to recover it. I used to use addy.io for this, but it was not as good since it had account limits and I had to manually manage every alias. Much easier for me to just create a mail filter to sinkhole an old name. Of course I have never really needed to do this anyway.
2 replies →
I've found using a subdomain helps with that, spammers will try everything@domain.tld but won't bother trying to brute force subdomains.
However be warned some surprisingly large websites don't support subdomains, for example eBay will silently send user@sub.domain.tld to user@domain.tld and you'll only figure it out by looking at your server logs for rejected mail.
In those cases I have to specifically alias that username@domain.tld to the subdomain.
With this new Apple privacy subdomain maybe eBay will finally fix this.
2 replies →
> Also, another downside is that you will loose privacy by using your own domain.
Not really no. You can absolutely create a domain using bogus WHOIS information. No one will bat an eyelid.
3 replies →
> The problem is if someone figures it out and starts sending you spam to {random}@domain.tld.
It's a non-issue. I've been using a catch all domain for at least a decade. I get a small amount of spam to random made up emails but not enough to care about plus it all gets caught and filtered.
The mechanism I use is ordered. All specific aliases are tried first and then it falls through to the catch-all forwarding rule.
So, it's a piece of cake to add "{random}@example.com" to the block list. Usually it's something like "msg-bestbuy@example.com".
I do this. The awkward thing is when I am in person or on the phone and have to explain that my customer email address is [their_business_name]@my_weird_domain.tld
But the people usually just nod along.
The other downside is that it's forward-in only, wish I could proxy responses without setting up a whole new inbox (and outbox).
> The only awkward thing is when I am in person or on the phone and have to explain that my customer email address
I had one small business aggressively threaten me that they fully owned their business name and I wasn't allowed to use it in my email address.
My solution was to keep my wonderful aliases and dump them. If a business is concerned but nice about it I'll offer an alternative such as plumber@
> The other downside is that it's forward-in only, wish I could proxy responses without setting up a whole new inbox (and outbox).
If you have your own domain most mail providers don't care what username@ you use on your sent mail so you shouldn't need any additional mailboxes (especially if they already offer inbound catch all)
I also use the ReplayAsOriginalRecipientUp [1] extension in Thunderbird which takes the recipient address and puts it as the sender for ongoing communication.
[1]: https://addons.thunderbird.net/en-US/thunderbird/addon/reply...
3 replies →
So I guess I'll take a moment and plug my email provider, Fastmail. Their integration with 1Password to enable creation of Masked Email at account creation time is really fantastic! I have several hundred of these at this point, it's made my digital life appreciably better.
But to the point of forward-in-only -- I use the fastmail web client and iOS client. Both of these respond using the Masked Email address if you choose to respond to an email. In fact I can choose any of my masked email addressed as I am composing mail to initial communication from that address.
In short, "it just works". I really can't say enough good things about Fastmail!
Just happened to me today! I was at the Verizon store and my address was verizon@... Sometimes it leads to confusion, but sometimes it leads to getting extra special treatment actually! They think I'm someone important.
They act as if I discovered fire when I give them a plussed address.
You can proxy responses with a ton of e-mail clients, even Gmail supports it once you verify you can get a message sent to that address.
2 replies →
sometimes I'm lazy and I just have it as spam@firstlast.com or noreply@firstlast.com and they get quite puzzled
Its not the worst.
I was once on the phone with german insurance provider and they dictateted me email to send documents to: kundenbetreuung@passportcard.de
I dont speak German so it was both tough and funny EuroTrip-like moment.
Yes its really email they use.
I do something similar, use an open source service called addy.io, bought a domain but you can also use their domains too, and each website has a separate login i create through bitwarden with the addy integration.
addy.io and proton pass are both great, affordable options. (Proton pass has a built in hide-my-email feature that supports custom domains)
1 reply →
[dead]
Services like DeepSeek have an email domain whitelist rather than blacklist. So creating your own domain just guarantees a lockout
That's nonsense. I have a DeepSeek account, of the form ai+deepseek@mydomain.com.
1 reply →
I’ve been doing this for years. It works fine and it’s fun to see who is selling your email.
But keep good records!!
It gets really awkward when you’re trying to recover an account and can’t remember what custom email you used.
Yeah, I think I only record maybe 10% of them that actually have logins associated. For the others I just search through my email.
Doesn't work when some service providers only allow email addresses that are on a whitelist of domains. And I have run into more than a few.
This lacks the easy control over blocking the “aliases” you’re done with. The real pro tip is to use this domain with something like addy.io (paid or self-hosted) where you can either pre-create the aliases or have them dynamically created for you as they become used for the first time - and having control over each of them so you can block it when you want.
I have never had to do this in my years of using this scheme. And if I did, I would create an email filter. Which I consider to be more standard and scalable then managing a bunch of individual aliases.
Gmail will block messages that fail SPF/DMARC alignment unless the forwarding mail server supports SRS.
SPF/DMARC/DKIM make this all a bit more complicated now. There are plenty of MTAs out there that will refuse to send you mail if it's not all correct.
This is absolutely not difficult to get right. Run OpenDKIM and OpenDMARC on your server along with your email stack (I use Postfix and Dovecot). Use a tool such as mail-tester.com to verify compliance.
iCloud itself does this for you if you bring your own domain fyi
> 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 Email on the same domain would make a blanket ban easier rather than harder? What am I missing?
Before, the emails were "me@icloud.com", the default for all apple users. There was no way to distinguish normal emails from generated private emails.
Now, they will be "blah@private.icloud.com", so it will be easy to ban the generated/private email that reduces the ability to associate logins across services.
Unclear why Apple would shoot themselves in this way; I hope it's not Ternus complying with anti-privacy.
Now, they will be "blah@private.icloud.com"
I've been in the ecosystem long enough to have .iCloud.com, .me, .mobileme.com, iTunes.com, and probably one or two more addresses all assigned by various Apple services over the years before they started unifying the systems.
They all work, and independently of one another.
I wonder if all the domains will be migrated, and how namespace collisions will be handled.
1 reply →
maybe to avoid getting their legitimate email servers banned by other servers since they host (i.e. being exploited) a growing number of spam accounts.
5 replies →
But it’s not? Like if they block that subdomain, they will completely block Sign in with Apple.
5 replies →
I see – somehow the Apple UI for this gave me the mistaken impression that privaterelay.appleid.com was the domain used by the alias, but I see now that it was always just icloud.com.
Apple was generating (something)@icloud.com whenever you used that service. Now, it will use (something)@private.icloud.com instead. So you can ban this subdomain instantly, knowing people will be "hiding" with this service by default.
It's like blocking anondaddy, simplelogin etc but not protonmail.
I guess their thought process is, both alias and non-alias accounts use @icloud.com
You were always able to reserve a normal icloud email address just like you would a GMail account, so banning all icloud email addresses would be banning non-alias Apple customers
That being said, I'm not convinced anyone who wanted to ban aliases couldn't have already. The alias emails look weird enough I'm guessing you could ban them with few false positives.
> The alias emails look weird enough I'm guessing you could ban them with few false positives.
While this is true not all of them been weird. Some can be just word + number + word without dots or underscores.
Also blanket banning whole domains is just much easier and already done for temporary emails. No false positives.
1 reply →
I highly recommend either SimpleLogin or Fastmail aliases. The latter are superior because they can be used to reply directly to any received email without needing to set up reverse aliases.
When you own your own domain, the switching cost between providers is small. You can make a dedicated domain just for aliases
Both SimpleLogin and Fastmail have excellent integration with password managers as well
"Useless" is a leap. The kind of site that would block private relay emails is the kind that was already getting my burner anyway. The private relay is for sites I want to hear from, but also want a failsafe in case they're hacked later.
Exactly. No reasonable business will ban emails from this subdomain.
Thankfully, we live in an unprecedented time of reasonable businesses lead by reasonable people. Close one. Nice save.
2 replies →
For me personally, Hide My Email is binding me to the Apple ecosystem more than iMessage (but I'm European).
It’s unsettling, you’re either an iCloud customer for life or hundreds of logins could break.
Nothing breaks when you switch. You just can't create more private icloud addresses. I recently switched back to Android and can still use my old icloud logins.
5 replies →
Does it? I use Hide My Email largely without integration to the Apple ecosystem - I generate new emails on icloud.com and copy/paste them to login forms before saving to 1Password.
Same, Hide My Email is pretty much the only Apple service I use and the aliases are only for accounts I don't really care about.
I use this wonderful extension to make it easy to generate aliases https://chromewebstore.google.com/detail/icloud-hide-my-emai...
This is one reason I never used it, but another reason is that I never felt that the privacy benefits were worth the hassle of randomized emails.
If I need to make an account with someone I don't trust enough to hand my email over to, usually the right answer is to just not create an account with them.
I have also tried things like having email aliases but what ends up happening is now I have more email accounts aliases to maintain/think about. It's annoying.
I don't personally find the prospect of "receiving spam email" or "having my email account leaked in a hack" to be particularly threatening. Spam just goes to the spam box, it's usually not my problem.
And besides, my real email can get exposed by my own legitimate companies that really should have my real email getting hacked. See also: EquiFax.
Like yes that, but also. Why would I want to hide my email from someone but not from Apple? And why can’t I turn it off and choose not to hide my email? This is one of my top Apple ‘features’ that would make me migrate away, if not for android being similarly awful
Determined sites could already easily do this. Just detect the patterns used. I agree it's a useless change though.
heave_balks_0g@icloud.com
It shouldn't matter for the sign in with apple because sites are already expressly supporting that.
Email aliasing is hard because you want privacy from a herd of users, but then you're locked into that ecosystem versus a domain you control has no herd, but the upside is no lock-in.
Not all aliases it generated look like this, some look like these:
In any case fact that some services banned alies is not the reason to make them completely useless instead of making them better.
Apple is one of few companies that ia able to push for this with market share.
> Determined sites could already easily do this
They already DO do it, I don't know how they're currently determining it
I think the NYT might be one detecting them which is funny because their editorial staff have promoted the use of aliases.
I use Proton aliases everywhere...Well not everywhere, there are indeed quite some places that don't accept a passmail.net address... So I can imagine this becoming a useless feature, at least on some sites.
Btw I only use these aliases for sites where I don't mind loosing the login, otherwise it would the mother of all lock-ins... Would have been nice if I could opt for aliases on my own (secondary?) domain... At least then I could still move them (using wildcards or some exported list).
You can create custom aliases on your own domain. I do this for every log in and am migrating old emails to my custom domain aliases.
In the flip side, someone who blocks private.iCloud.com will block the ability to do SSO with Apple, thereby cutting themselves off from Apple’s ecosystem.
Not really. You could allow private.icloud.com only if they're using Apple's SSO. If someone tries to create an account not using Apple's SSO, then you don't allow private.icloud.com email addresses.
Maybe they've started seeing sites ban @icloud.com addresses
Which has more market pull: Some web site or Apple?
iCloud email isn't very popular. I always have to spell it out verbally if someone asks, and sometimes they end up emailing @gmail.com anyway.
I guess the new subdomain address implies a paid iCloud user, not a free mail freeloader, and that could be a positive thing.
Almost surprised it lasted this long but quite disappointing
Almost all of my iCloud relayed addresses are already @privaterelay.appleid.com, and they've been working perfectly. So I don't expect this to change any time soon.
That domain is only used for Sign in with Apple.
I would bet that doing so would be a pretty quick way to have your app pulled.
They already require that you use Sign in with Apple, I would think that it working fully is also a requirement?
You can use Hide My Email on any website though, whereas Sign In with Apple is limited to just those websites and apps that support it. Sign In with Apple isn't nearly as popular on the web, so it's a lot easier to just ban "@private.icloud.com" from your web service there.
Hide My Email isn’t particularly related to apps. You can use it on any web form that asks for your email address, or as the sender of any email message you send using Apple Mail.
> They already require that you use Sign in with Apple, I would think that it working fully is also a requirement?
They require apps offer a service which meets their privacy requirements if they use any 3rd party or social login service.[1] And apps could block private.icloud.com for email and not Sign in with Apple.
[1] https://9to5mac.com/2024/01/27/sign-in-with-apple-rules-app-...
The rate limit seems to be 20/hour and not 30/hour as mentioned in the article.
Just wait 20 minutes. I generated like 40 in under an hour. No idea what limits are though and how they refresh.
I got stopped after 5
I have a cron script which configures a today-only email address in Postfix.
Mail sent to t20260617@foon.uk will reach me, but only for today.
So, any time I'm giving away my email address against my will, which is most of the time, they get to spam me for exactly one day.
Shameless plug - I created a chrome extension that allows to create unique email addresses that forward to your real inbox. It uses Cloudflare email routing, simplifies creating/labeling of new addresses and keeping track of them. Always 1 click away.
The addresses are pre-allocated and recycled when deleted so creating a new one is faster that with Apple's hide my mail.
https://github.com/webmonch/hide-my-mail-cloudflare
With cloudflare you can also just setup catch-all and be done wirh it.
I personally doing catch-all already, but problem is that using your own domain for website registration basically gives everyone unique id to eaaily connect all the information that ever been leaked for your accounts and something always gets leaked.
Not a very good idea for privacy.
The biggest upside for me of having separate labelled mailboxes is I can use one, delete it later and never receive mail from it again.
2 replies →
Spammers aren't going to make that connection. Your custom domain will be like any other corporate entity as far as their scripts are concerned.
Pretty good way to harvest magic links and email codes!
Doesn't owning the domain kind of defeat the point?
Not really, at least if you register the domain anonymously. You get unlimited emails, and I assign one to each website or registration.
I guess I don't understand the concern... what does it matter if a different domain is used for Sign in with Apple and Hide My Email?
Because many sites check the domain part of your email address against a blocklist, which contains entries like trashmail.com to prevent users from signing up with ad-hoc throwaway accounts. They don't want that, because they'd like to get a proper lead they can either track, sell, or reach out to.
Now Hide My Email allowed you to do just that: Create an account with an email that wasn't tied to your identity, and that you could just decommission if you didn't need it anymore. Sites had no way to detect these either, because all of the randomly generated addresses Apple provided you with just ended in @icloud.com, which is also used by tons of regular accounts - so if you blocked this domain, you'd invariably preclude millions of people from your service.
But by separating the domains, sites can simply add private.icloud.com to their trash mail blocklist, preventing the use of Hide My Email, while regular @iCloud.com addresses will continue to work. It makes the entire service useless at once.
But that will completely break Sign in with Apple, which no service is ever going to do. I really don’t get the problem here.
2 replies →
Right now it’s the same @icloud.com domain as normal personal emails. Now all auto-generated emails will use a separate domain name, so sites can block emails with that domain, without worrying about blocking people’s main personal email.
Websites block certain throwaway email domains from signups. The concern is that this will happen with private.icloud.com
A good example of a throwaway email that is now useless because of these blocks is mailinator.com. Originally, you could just make up a random email on the spot like gregsrightfoot@mailinator.com, visit mailinator.com, and get the needed signup verification email. These services autodeleted messages and required no signup so they were a black hole for spam. However websites eventually got wise that their spam wasn’t being seen and started blocking the domain. Mailinator came up with alternative domains and there was a brief back and forth before the throwaway email domains all ended up being blocked.
I guess I'll go back to mailinator. That thing has 100s of aliases by the way for some that don't use that yet. Great service. Not guaranteed private really so don't depend on it for that. (Though if you use a strong has for a hash@mailinator.com address, is it pretty secure for "email purposes"?)
Emailfake.com
Fastmail also has wonderful random email functionality you can link up to your Bitwarden client or use the Fastmail API.
Did Hide My Email addresses cause problems for deliverability for actual emails/users on iCloud?
Okay but banning private relay emails would also mean your site is blocking Apple sign in?
That was always opt-in from the sites, and many never bothered - me included, because I refuse to pay Apple $99 per year for the privilege to offer easier authentication to their users.
This is a big downer for me, I have started using Hide My Email religiously.
I pay for Fastmail just for masked email and its integration with 1Password.
I frequently run into scenarios where it won't let me generate the email within 1password on a website, and I have to go to Fastmail and then manually do it. Is this something you have bene able to work around?
Unfortunately not really.
I scripted something to hit Fastmail’s API + 1Password API to generate emails and make accounts in these scenarios. But it’s still annoying.
Same problem here.
I sure wish 1Password + Fastmail would let you generate them within the 1Password app without requiring a browser sign-up page in the middle.
I wonder if the existing hidden emails I already have in iCloud will be changed over too. If that's not the case, I'm just going to use one of the 50 throwaway addresses I already have.
The announcement the article linked said Existing addresses on the legacy domains will continue to work and forward mail to users without interruption.
Guess I missed that part, my mistake
It is limited to around 600 addresses, it’s already useless.
Well, 600 is probably more websites than most people ever use in a decade.
Fastmail still generates theirs with @fastmail.com. And 1Password has an integration with them to quickly generate an address when creating a new account somewhere.
email isn't really a decentralized system at all. Google, Microsoft and Amazon own e-mail delivery. Perhaps Google ads customers complained that they could not correlated private @icloud addresses, and we are now witnessing the consequences. What Apple got in exchange from Google, I don't know, I'm sure it is related to their Siri deal.
[citation badly needed]
Come on. Most likely this is just a result of some manager pushing for "improvement": "Why we have two different privacy email alias systems? Lets make unified one, save on maintenace and I get promotion".
And might be there just no one remain as owner of feature to explain them why its bad idea.
Oh fuck. I love Hide My Email and it's been the best feature about iCloud ever since it came out.
It's actually useful compared to Gmail's useless "yourrealaddress+alais" that gives away your actual email anyway, and it helped me catch quite a few spammers/data sellers.
Hide My Email addresses already have a peculiar format that others could guess, and some do block those, and there's no reason to add a blatant "private." tag.
This is a win for privacy-intruders, not users, just like Apple's iCloud Keychain API that has allowed Facebook, TikTok etc. to secretly track users across multiple devices and device reinstalls for years.
FWIW it's not a gmail thing for privacy, but rather just part of the email spec. RFC 5233 talks about it.
https://www.rfc-editor.org/info/rfc5233/
It all dates back to the Andrew Messaging System at CMU, developed in the 1980's. Originally the format was "<username>+<keyword>+<args>@example.net" where the mail server would interpret the keyword and arguments to route the message in whatever unique way that keyword would dictate (e.g. bob+dist+~/mailinglist@example.net would read the file mailinglist in Bob's home directory and deliver the email to addresses listed in it). If the keyword was not recognized, it would just deliver normally. So bob@example.net and bob+alias@example.net were equivalent, and could be used to filter after the fact if desired.
1 reply →
Did the RFC editor get a makeover recently? It looks familiar, but also kinda… polished. Neat.
1 reply →
How is that different from “privaterelay.apple” that has been used?
simplelogin from Proton works great, can recommend; for Uber I generate uber.random-word@simplelogin.com, for Slack slack.random-word etc to easily see who leaked my email
Urgh, that's a huge downgrade. What a shame.
Where do I sign to show my opposition to this change? Hide My Email has been essential to keep my digital life protected from abusive mail lists and frankly one of the features that make me associate icloud with a premium service
Just use fastmail
This is so dumb. They randomly generate them anyways it’s not like they are likely to collide with other users. They should allow you to use your own domain for private relay but it doesn’t let them build a moat so they wont
[flagged]
My dog thinks it's because we're running low on milkbones, but my cats aren't convinced.
ah. techcrunch must have alluded to you not having milkbones
https://techcrunch.com/2026/06/16/apple-plans-to-change-its-...
1 reply →