131–140 of 216 posts
Oh I glad there is still someone at Apple who understood its insanity. If only they made it generate a bit more sensible alias names. UPD: I obviously mean alias addresses template make most of them too easy to recognize.
---
Just checked, they can. Phew. If the forwarding alias was detectable/always used the same schema, that'd also make them borderline useless, just like the `privaterelay` subdomain
Earlier quoted context omitted.
So any mail to anyrandomstring@yourdomain.com is actually received? Sounds like something that works great when only you do it, but might quickly be abused if it catches on?
If you do this you immediately get thousands of emails a day from bots trying common first names etc. Much better to maintain an explicit list of names you're currently allowing.
Earlier quoted context omitted.
Why do you want this. Is it a benefit to you? If it is why should you not pay for that benefit? Nothing is free.
You say nothing is free, but Amazon, Discord, Dropbox, Facebook, GitHub, Google, Instagram, Microsoft, Paypal, Reddit, Slack, Steam, TikTok, Twitter etc all offer it for free. Plus, it's not for the dev, it's for the users of the website.
Oh I glad there is still someone at Apple who understood its insanity. If only they made it generate a bit more sensible alias names. UPD: I obviously mean alias addresses template make most of them too easy to recognize.
Can't the aliases be renamed? --- Just checked, they can. Phew. If the forwarding alias was detectable/always used the same schema, that'd also make them borderline useless, just like the `privaterelay` subdomain
PS: I guess its just misunderstsnding and I really meant addresses themself are not human-like enough.
This is a huge selling point. Private email relays often get blocked, the only lasting solution is to put them on the same domain as, and in the same format as, a significant number of non-private email addresses. As far as I’m aware the only other provider doing this is Fastmail. Comments about lock-in aren’t wrong, but it has to be this way. You can make arbitrary email addresses at your own domain, but anybody who…
> You can make arbitrary email addresses at your own domain, but anybody who feels like it can trivially automatically detect that those are all you. You assume that the domain is used by one person or what? Also, the point of these is typically to prevent spam. Noone is going to spend a fraction of a cent or second to try and figure out who is behind the adress.
Yes. It's not a guarantee but you can identify several strong signals that suggest that.
> point is to prevent spam
also yes
Earlier quoted context omitted.
Case in point: many websites block all VPN except iCloud Private Relay. Thank you Apple!
I don't think websites block Google's VPN either, although that's not quite as popular as Apple's VPN solution.
Its only upside was a fact that it was actual VPN for all the apps while AFAIK private relay limited to Safari.
Earlier quoted context omitted.
Apple is luxury big tech. In this day and age, privacy is luxury, so that's what they sell. I don't think there are any ethical motivations for them (or any other large corporation - none of them have morals so they cannot act morally). It's just that there's a market niche, so it will be filled by someone.
It’s an additional layer of wall for their walled garden to keep the technically proficient users that are more likely to hop walls.
Earlier quoted context omitted.
For the "hide my email" feature, Apple currently and has always used "@icloud.com". This masks you amongst all iCloud users. They were planning to change it to a custom domain, which would allow sites to easily filter out and reject "Hide my email" users based on the email. They have now reverted their plans to change this, meaning "hide my email" is still "@icloud.com".
Except the post says it will be @private.icloud.com Whereas people's Apple emails are often at @icloud.com So I don't think it masks you amongst all iCloud users. I'm confused how this is much better!
These are two separate services. The problem was with the latter not the former. If the service decides to block @private.icloud.com they might as well remove Apple's sign in button.