> 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 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.
Problem is that using of own domain is creating huge privacy and cybersecurity risk since you can track all the person profiles across all the databases ever leaked.
Its nice as vanity item, but it's better not to use same domain across banks, online forums and porn sites. ;-)
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.
In the UK, I believe parking companies need to have a way to pay without the app but it's usually so bloody inconvenient that it's about the same as requiring it.
IDK I’ve appreciated Reddit killing off good features like old version, putting a time-lock banner on mobile while logged out, trying to block VPNs when logged out, etc.
I want that company devalued and bought by Verizon or AOL to die a Yahoo death.
What is insane to me is how few people realize their stock has a higher P/E than nVidia… and it isn’t because of some bullshit minor AI data deals. It’s a youth-forward narrative machine, and everyone knows 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.
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.
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.
> 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.
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'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.
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.
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.
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 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?
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.
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.
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
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.
My email addresses been public for years and spam was never a big issue.
But yeah it mostly opposite problem I would say - spam filters eat usefull stuff sometimes. Just today I found one more job related email in spam, but its from public mailbox damn.
Privacy is kind a bigger issue and having aliases on icloud is just much more convinient than having 10 accounts.
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.
> 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.
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.
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.
myself just in case and fellow hackers
If you were a hacker, you'd have your own domain.
The bar for calling oneself a "hacker" gets lower each day.
You could've at least checked my profile...
Problem is that using of own domain is creating huge privacy and cybersecurity risk since you can track all the person profiles across all the databases ever leaked.
Its nice as vanity item, but it's better not to use same domain across banks, online forums and porn sites. ;-)
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.
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.
In the UK, I believe parking companies need to have a way to pay without the app but it's usually so bloody inconvenient that it's about the same as requiring it.
Essentially too bad. Look at the parkmobile disaster.
you can pay at the parking meters directly, no need for a 3rd party app
Unfortunately sometimes we are at some specific provider’s mercy for whatever reason like lack of appropriate alternatives.
COUGHredditCOUGH
I think Reddit falls under this category.
> If your website will block me out because I used a privacy friendly email, I want nothing to do with your website.
IDK I’ve appreciated Reddit killing off good features like old version, putting a time-lock banner on mobile while logged out, trying to block VPNs when logged out, etc.
I want that company devalued and bought by Verizon or AOL to die a Yahoo death.
What is insane to me is how few people realize their stock has a higher P/E than nVidia… and it isn’t because of some bullshit minor AI data deals. It’s a youth-forward narrative machine, and everyone knows it.
FWIW, old.reddit.com is still there and working
RedReader still works. For now.
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.
Even .us ??? Pretty sure I used my usual domain (enslaves.us) with them for wireless and california landline and u-verse.
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.
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.
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.
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
> 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.
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.
You cant send mail from Hide My Email aliases. They are only work one way.
You can send from Hide My Email addresses:
https://support.apple.com/guide/icloud/use-hide-my-email-in-...
I think I've also seen this in Mail.app but that's not shown on this page.
Wow my bad I wasnt aware its possible. I remember someone in HN comments complaining about it being one way only back in 2024.
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.
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.
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.
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.
For me personally, Hide My Email is binding me to the Apple ecosystem more than iMessage (but I'm European).
Maybe they've started seeing sites ban @icloud.com addresses
Which has more market pull: Some web site or Apple?
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.
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 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?
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.
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.
Did Hide My Email addresses cause problems for deliverability for actual emails/users on iCloud?
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
Emailfake.com
Fastmail also has wonderful random email functionality you can link up to your Bitwarden client or use the Fastmail API.
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.
My email addresses been public for years and spam was never a big issue.
But yeah it mostly opposite problem I would say - spam filters eat usefull stuff sometimes. Just today I found one more job related email in spam, but its from public mailbox damn.
Privacy is kind a bigger issue and having aliases on icloud is just much more convinient than having 10 accounts.
Doesn't owning the domain kind of defeat the point?
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.
Did the RFC editor get a makeover recently? It looks familiar, but also kinda… polished. Neat.