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?
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.
> Existing addresses on the legacy domains will continue to work and forward mail to users without interruption.
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.
UPD: apperently this supposedly only work if someone message you first. So you still cant spam from aliases.
But otherwise, you're right, any website that wants to accept Sign in with Apple will almost certainly be agreeing to Apple's TOS for Sign in with Apple I presume will stop you from blocking this service.
It's like blocking anondaddy, simplelogin etc but not protonmail.
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.
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.