An Ode to Apple’s Hide My Email(empty.coffee) |
An Ode to Apple’s Hide My Email(empty.coffee) |
Thanks for using our crappy (app or web site) and Preserve Your Privacy With Apple.
Please enter your mobile number for account verification. Your number must be capable of receiving SMS messages.
We need your mobile number in order to verify that we can track you, personally identify you via data brokers, and send you SMS spam and robocalls.
To help us verify this, please log in using your password and the single-use code we will send you via SMS.Way too frequently I have to dig this feature out of the settings menu, copy the address to the site, copy the site back to Hide My Email as a label, and then usually do the same hoop-jumping with my password manager.
I would welcome this feature to be more front-and-center on the keyboard somehow.
In fact the duck email service is nearly perfect, except for the fact that the extension forces you to use duck as a search engine and so you literally have to modify the chrome extension and store it locally if you just want the email service.
I ask for learning, not for skepticism.
TL;DR - Cloudflare email works great if you have your domain on Cloudflare, Firefox Relay is cheap and will work with emails up to 150KB and a number of email providers give you the ability to create aliases (Runbox allows up to 100 aliases).
(Disclosure: Relay engineer.)
Why not?
I just used Hide my email for a non-critical but real-life situation. I had to learn my new email address and I’ll have to remember it forever. I’ll probably change it back to my regular address at some point.
People are better off not using Apple’s HideMyEmail. There are better ways that allows this on your domain - no lock-in!
Or no lock-in with a device or browser (because without that it’s a bigger pain).
Edit: also with custom domain you can switch email providers.
But you can also deactivate the email address and be done with it.
It's the easiest Postfix config in the universe, essentially just:
virtual_alias_domains = domain1.com domain2.com
virtual_alias_maps = hash:/etc/postfix/virtual
phil.equifax@domain1.com firstname.lastname@gmail.com
phil.experian@domain1.com firstname.lastname@gmail.com
... (hundreds of these)
Gmail seems to be fine with this, emails do not usually end up in spam. Every full moon maybe, but usually it's alright.
It's not as shiny as Apple's thing, but it's 100% selfhosted and I own the domain.
I'm also not trying to stop tracking, so much as I'm trying to have my own semi-permanent equivalent to mailinator that nobody will recognize as such, that I can use to cut back on the amount of spam I get.
- Only use one email address: hi@example.com
- Always add a filter: hi+hn@example.com
- Send all emails without a filter to SPAM
Since it's not a common strategy, it is much more likely that spammers remove the +hn before sending an email than add one.
virtual_alias_maps = mysql:/etc/postfix/mysql_virtual_alias_maps.cf,
mysql:/etc/postfix/mysql_virtual_alias_maps_wildcard.cf,
hash:/etc/postfix/virtual
user = mail
password = <password>
hosts = 127.0.0.1
dbname = maildb_postfix
query = SELECT a1.goto FROM alias a1
LEFT JOIN alias a2 on (a2.address = '%s')
WHERE '%s' LIKE a1.address
AND a1.active = '1' AND a2.address IS NULL
Note: with the above code SQL injection could be possible through an alias name, but given that in this setup I am the only one managing the mail accounts, I was willing to take this risk. :-) Postfix Admin might do some cleaning/validation, but I haven't checked on it.
Apple's system is "shiny" because it provides near total anonymity, whereas your setup has all the deliverabilty issues of a self-hosted domain and rather uniquely identifies you...at the domain level?
I'm not sure why you are maintaining a hundreds-of-lines virtual table and a web UI, instead of just using a regex or two to capture phil.*@domain2.com or something along those lines (maybe you want to do one including a year or something to cut down on spam), or blacklisting as needed by having postfix reject during the SMTP session so the email is marked as invalid and is removed from the spammer's database.
Or, I dunno, just use VERP? I don't think I've yet run across anyone smart enough to drop VERP from email addresses.
I still want to use random unique addresses even for important and trusted services, not just for throwaway uses. So third party domain is not an option.
I use self-hosted unique addresses mostly for registering to services, so forwarding those messages in both directions through Apple's service would expose all those services to a silent takeover via password reset by Apple's employees in control of this service. So this service is exactly as useful as those random throwaway email inboxes available on the web. More polished maybe.
Otherwise everyone @example.com is the same person.
Thanks to this setup, I've already encountered one instance of a company either leaking or selling their customer information.
Bonus: a ghetto alias generator:
dd if=/dev/urandom bs=1 count=10 | base64
Square also makes this incredibly difficult because if you enter a merchant specific email they permanently tie it to your card. So now any time I ask for an email receipt I get an email to my hairdrstylist’s “unique” email.
Never had it go that far but I definitely had some odd reactions e.g. a support agent thinking I was a colleague.
On the other hand, if you have a relatively common name it avoids people giving your email address then behaving aggressively when you tell them to stop. I’ve had a few friends hit this issue.
n.ame@gmail.com or nam.e@gmail.com . Many SMTP servers respect periods as differentiating emails, so services can't delete them. It doesn't help you stop spam, but you can add a gmail filter that n.ame@gmail.com is put in a separate label. And it's very fast to type, easy for non tech-y people
For example, to enable plus addressing in postfix is only a matter of defining:
recipient_delimiter = +
Though I had originally made this because with the "+" approach, you can easily get the original address by simply removing everything after the "+", while with mine you cannot. On top of that, sometimes "+" does not work in services that do "strict email validation".
[1] https://github.com/simple-login/app/
[2] https://github.com/anonaddy/anonaddy
[3] https://protonmail.com/blog/proton-and-simplelogin-join-forc...
Hide My Email is very good and I'm using it a lot.
They're even slightly pre-filtered for Apple's convenience, as the times you're likely to use Hide My Email are for shopping and social media - nice, ripe marketing targets.
If you use virtually any email provider this is true.
Also, unless you're encrypting your emails, can't everyone read your emails "on the way though" anyway?
It would be fine if you were allowed to use normal MFA options, but no, that is not possible. Instead, you MUST confirm your logins via already signed in Apple-devices only. There is no other way. Cannot use phone number (for good reason, but that is besides the point), cannot have a secret key based TOTP.
https://support.apple.com/en-us/HT204915
Google on the other hand… I’ve seen two people lose their Gmail accounts even they knew the password because google required verification from a mobile device that no longer existed. :|
Now I just need to work on untangling 15 years of other services from my main account.
In macOS Mail and iOS Mail, when you reply to an email or send a new one, you can choose the "From" address: The options are the usual accounts you have set up, plus, now, a "Hide my Email" proxy generated on-the-fly. I've found it very handy on several occasions.
* accidental semi-spam (people sending emails to someone at one of the domains I own, mistakenly) where I wish to notify them that they got the wrong email, but don't want to divulge my main email (and name).
* support emails from services that I signed up with using "Hide my email". When replying, the "From" defaults to my main email, but again, I can switch to "Hide my email".
Some sites have never worked properly with the email+tag@gmail.com thing and some have even become wise to it and wont accept addresses like that (car dealers are the worst).
I hope someday apple allows 3rd party integration with this feature.
I tend to use it when signing up for something IRL that wants an email address. I wish there was a way to use Shortcuts to generate a new email in one tap.
I’ve been keeping an eye out for a settings URI that will take you there directly https://github.com/FifiTheBulldog/ios-settings-urls/issues/1...
The nice thing with "hide my email" and Fastmails "masked addresses" is that the two services use a popular domain, so sites can't easily block it.
Even myname+random@gmail.com and similar can get blocked from registration on some websites now.
The difference here is the power of iCloud. Services can't afford to block it.
This is similar to Domain Fronting [1]. Maybe we should call this email fronting?
The other benefit for apple is that if a generated email address for Home Depot has non Home Depot content, it's easy to block, since it's clear it got sold to a email marketing company.
And then Apple can then threaten the corporations to not sell their mailing lists or risk being cut off from sending to icloud, or worse, having a header in the email from Apple saying that "Home Depot doesn't respect your privacy and sells your email address to 3rd party marketing companies. Here's a telephone number where you can complain."
The worst thing is that so many sites have stupid email validation rules. Even cameo.com, which is a mid-size ecommerce site, doesn't accept a lot of TLDs created in the last 8 years, including mine.
I’ve been happy with the Fastmail+1Password integration as that “feels” less painful to migrate off the in the future.
The result is bad either way. It's either A or B. (A) Canceling iCloud+ doesn't remove existing Hide My Email addresses - which makes it possible to abuse by creating tons of extra addresses before canceling. Or: (B) Canceling iCloud+ deletes all of your Hide My Email addresses, locking you out of dozens of services (e.g. anything that sends an email as a MFA).
I suspect that it is actually (A). Someone just needs to test this and report out.
You can also export your setup through their API so you can very easily migrate to a self-hosted instance if ever necessary:
wget --header "Authentication: YOUR_API_KEY" https://app.simplelogin.io/api/export/aliases -o simplelogin-export-$(date +%s).csv
And given the author talks about Have I Been Pwned, I feel I should mention that SimpleLogin has built-in HIBP integration (contributed by me in https://github.com/simple-login/app/pull/472)
Sure, there were many services like that before, and many of us have used them. But making it an integral part of iOS can drive mass adoption. You have to credit Apple for that.
My only wish is that it were easier to send an outgoing email via a Hide My Email address (rather than only being about to reply once the other party has sent the first message).
Not totally intuitive but pretty decent.
Technically you can do the same with SES on AWS as well, they verify just a single email address this way (domain is with dns records), and they have SMTP gateways to connect to a mail client .
Discussion here:
The concept is fundamentally the same as Hide My Email or DuckDuckGo's service, but it's libre software and has (IMO) a better UI to manage addresses. It also stops tracking pixels, which Hide My Email doesn't do unless you also use Mail.app. It's hosted in the EU and runs entirely on renewable energy.
Some other services (like Firefox Relay) will use AWS' Simple Email Service for everything. I opted to go for [MailPace](https://mailpace.com/), an independent, privacy-focused provider instead, which is an improvement but still not ideal. I believe that SimpleLogin lets you self-host your email, which is best from a privacy perspective, but I'm slightly concerned about the UX of having to think about email deliverability. Still experimenting with that!
Apart from our early integration to send and receive Bitcoin on Coinbase, Cloaked Email was the most successful part of our privacy focused startup, not only in its ability to attract press coverage but in generating revenue as well.
We believe our work contributed to forcing criagslist to introduce their email relay service. Craigslist went so far as to block email from cloaked email users. [2]
Doing this well and to take on the responsibility of maintaining ~forever is a huge thing.
It is great Apple has recognized the importance of this matter and brought it into their platform in such a straightforward way.
One of the most engaging actions we had was people re-rolling for a different random email address. People just loved seeing what they might land on next.
[1] https://blog.gli.ph/2012/08/14/delivering-privacy-gliph-cloa...
[2] https://blog.gli.ph/2013/07/22/cloaked-email-and-craigslist-...
Until this, it was just a handful of privacy-conscious folks using services like AnonAddy.
Anonaddy is a godsend to me, for having an additional feature to set which alias are allowed to forward (albeit limited just enough for essential services I can use) and also recently you can reply a message from your alias email
When using keychain as a password manager, once in a while when creating a password for a new site, it would generate it and complete the account registration, without properly saving the generated password.
I'd hunt for the site item through keychain's list and not find it, and go through the "Reset My Password" for the site, except if time passed I might not even remember which email I used to register.
It was annoying enough for passwords, but not critical. For emails there's probably situations where the account is just lost and the only option is to create a fresh new one. How good is their implementation for this ?
Easy to set up on a rpi/cheap VPS, as long as you have a hostname. And while you're there, look for a short domain name so it's fast to type (on credit card kiosks). You can get cheap short non-standard TLD's like .li. I got a 3 character domain for $5 a year, as short as bit.ly, but just for me
Social media is high on the list of use cases for such addresses to help preserve one's privacy.
This means that you shouldn't use iCloud (even if you have nothing to hide). The fact that there is no probable cause required means that the state can demand this data as part of a fishing expedition to abuse/harass even the totally innocent.
This means that features like this, which lock you in to using iCloud in the long term, should be assiduously avoided.
Get your own domain name and get your own email hosting (not from Apple) and use that. You can setup a catchall to have unlimited unique email addresses. You can use multiple domains if you like. Step by step instructions on how to do this are on my website.
So yes, this feature is super useful, and kudos to Apple for introducing this to their customer base.
(Disclosure: I'm on the Relay team.)
When comparing Relay with the other two, I get the impression that SimpleLogin/AnonAddy actually interact with the community and understand that self-hosting is something people want to do and provide approachable documentation and support for that, whereas Firefox Relay seems built only with a single global prod deployment in mind and is more like "well theoretically you could but you're on your own and who would do that anyway?". Even if it's public and under an open license, the intended audience is Mozilla internal, e.g. [2]
Like, if a user signs up for Relay today and in 2 years Mozilla sunsets it, the way things looks today I think it wouldn't be viable even for most seasoned self-hosters to migrate to their own deployment.
I do appreciate the work you guys are doing and I think the engineers seem to have good intentions, so don't want to be overly critical. But mentioning it as open source alongside SimpleLogin and AnonAddy comes with some major caveats IMO, and I'd wish that some more priority is put on keeping docs complete and up to date and making the stack realistically approachable for outsiders.
[0]: https://news.ycombinator.com/item?id=30727935
[1]: https://news.ycombinator.com/item?id=30315816
[2]: https://github.com/mozilla/fx-private-relay#optional-enable-...
For example, my custom domain is foo.mozmail.com. I enter my on the fly email address bar@foo.mozmail.com on attackers website. Voila. Now they know my custom domain name "foo" and can use it to send email to all possible on the fly addresses. e.g. 1@foo.mozmail.com 2@foo.mozmail.com so on and so forth.
Now my custom domain name as a whole is compromised but I can not change it anymore and lost all benefits of Firefox relay.
All I got was "not a valid email" or something like that.
One never let me change my email or password when I used the +.
OP also could have just used a regex in the virtual file.
I once ran my own email server for several years off a domain from no-ip.org running from a local server in my home. Most places accepted email from it just fine, occasionally though some places had their mail server reject my IP because it was in a DNS black hole.
Then you had the spoofers pretend to be att.com/verizon.com so they had to implement SPF and DKIM.
Then you had to uphold your reputation and the security of your servers otherwise your address would get put on one of the DNS black hole blocks.
Worse was if your IP address was already used to send spam -- you somehow had to get the black hole lists to remove your IP.
At some point about 15 years ago, I gave up and moved to gmail, and I never really looked back on it again.
I agree with sibling that the problem is with Email marketing, but for different reasons.
Companies are so addicted to spamming users and selling user data that it becomes unacceptable that users might not want to give away their email.
Another problem is emails being required for signing up to accounts.
Honestly IMHO we gotta get rid of email for signups. I don't know what to replace it with. Hardware keys, maybe?
This is different than "Reachable at" phone number which must be unique and is used for iMessage and Facetime, and if it's blank other people can only reach you via iCloud account email.
(It makes sense if you think about it, parents setting up iCloud accounts for their children's iPads who might not have their own phone).
If a domain only occurs once in a user database, it's likely to be a personal domain. A data broker that sees the same domain in a few different datasets (once in each) can be quite confident that the domain is an individual's.
A service that doesn't accept an email proxy during registration is not going to respect my privacy, so IMO not worth of using.
But yes, definitely a concern that is constantly on our radar.
Your complaint is similar to using RFC 822 "me+site.com@domain.com" style emails and then worrying that sites are going to learn that your real email is "me@domain.com" by stripping off the part after the plus sign. Call me optimistic or naive, but I don't think that sites are doing that...
https://people.cs.rutgers.edu/~watrous/plus-signs-in-email-a...
Additionally, they spend a ton of money lobbying and otherwise unfairly impeding competition, so in many places in the US, they are the only option, so it's give up your civil rights to lawsuits, or stay offline (or pay a wireless carrier who does the same anticompetitive scumbag shit a heinous price per gigabyte).
The state of both wireless and wireline broadband in the US is totally broken, and it's not getting fixed because it's broken by design, as part of the general attitude by large corporate interests and cooperative legislatures and regulatory bodies to treat the US population as a sort of natural resource like a flock of sheep to be fleeced rather than as legitimate customers to be serviced (or a legitimate market to be participated in on merits).
They do this by ensuring that there is no meaningful competition, and ensuring that if you do "willingly" engage in service with them, you have no meaningful legal recourse if they abuse you.
"We're the phone company. We don't have to care."
You have no real power against them because the people who control the system have decided that you should not have any real power against them.
Theoretically, probably none. Otherwise, you'd be able to hire a hitman on yourself, have slaves, or restrict a person's free speech because they're an employee.
The reason companies went with this approach was to stop class action lawsuits from happening, which is where the real damage happens. One enterprising law firm started doing pooled Arbitrations (filing for hundreds or thousands at a time), which costs the company more than a class action would. Some companies have removed such clauses because of this.
So far the most spam I’ve gotten has been to the address I used for Amazon (probably leaked by a third‐party seller there).
I mean you can pick any format you want before the "@", but yeah my format is trivial. Nobody has tried to do it automatically yet though, as far as I can tell.
I’m sorry, I can’t parse this. Can you try again?
I used <dentistbusinessname>@<mydomain>. My name was never involved in the address.
That's the point, if you don't use your name in your address, you can't be <genericname>@<genericdomain>, which third parties will provide as their email,
Because I use the same scheme you do I've never had that issue, but several friends with common names have hit the issue having registered to more "normal" hosts, often as somewhat early adopters and thus having gotten their pick.
The annoying thing is the number of services these days that don't seem to require you to verify your email. Examples of the above included eBay and Spotify. On both occasions I had to contact support to ask them to delete the account.
I’m still not following. Who is this third party and what does it have to do with a confused receptionist?
It looks like they still have recovery codes. I think it’s a good idea to have a set stored in a safe place.
I'd love to use Apple's keychain for credentials for convenience but it can quickly become the weakest link, when it should be the strongest.
But you're absolutely right, the caveat is indeed that the reason you care about open source does matter. If you want to self-host, you're probably better off with another product. If you want to be able to see what code is running, or even be in control of the running code yourself (even if it's running on someone else's servers), then Relay might be interesting too.
Is there any way to verify what code is actually running on your servers?
In my case, it costed me two offers. One from Google and one from GitHub. Come to think of it, yeah I will begin migrating everything away from FastMail and stop using it completely.
Also I think they are still based in Australia? Would be happy to hear about alternatives.
Isn’t it so bad that it’s overly hard to move away :(
You can email anyone on the internet as anyone and it will be delivered with NO validation. Clients may/may not validate any DKIM signature and the may/may not validate that it actually came from the domain. It's literally the easiest thing on earth to spoof.
Email is sent over cleartext, it is not encrypted. Anyone can read email if they can inspect packets.
That's obviously false if you bothered to do a bit of searching: https://en.wikipedia.org/wiki/Simple_Mail_Transfer_Protocol#...
>You can email anyone on the internet as anyone and it will be delivered with NO validation. Clients may/may not validate any DKIM signature and the may/may not validate that it actually came from the domain. It's literally the easiest thing on earth to spoof.
That might be true for some systems, but for most services out there, having missing/invalid anti-spoofing measures will result in your mail ending up in spam or not delivered at all.
You would think so.. but its remarkable how easy it still is to forge email.
My mum was recently the target of such a campaign. She's in the executive team at an international NGO. An attacker found her email address and a bunch of her contacts via the NGO's webpage. Then they forged emails from her email address, with a gmail address set up in the reply-to field. The emails all said it was an emergency, and asked for her colleages to transfer money.
As far as we can tell, most of the emails were delivered and lots of people were fooled - at least for awhile.
Her email address has DKIM and SPF set up, but (like most email providers) it has a lax DMARC policy. It turns out thats all it takes to be vulnerable to this sort of attack.
Technically correct, best kind of correct.
Sure, it is not plaintext, but anyone with the access to the wire could MITM the connections. Maaaaybe something changed in the last ten years, but I never seen someone not accepting a connection with a self-issued certificate and any warnings (to the end user) if the receiver uses self-issued cert. Which makes the whole point quite moot.
I prefer the system of using a basic abbreviation in the email address to avoid these types of filters but still make the email easily traceable later. Say your name is joe smith and you're buying from Sports Online. Something like Joe_spo_smith@yourdomain.com works well for later confirming whom you gave the address to.
I like this approach because one doesn't have to track all of the catch-all emails made on the fly, since finding out who you originally gave that email to is just a matter of searching your past email and noticing that "spo" looks more like those old Sports Online emails and not the new spam from discounted wholesale fancy rugs.
Apart from seeing who a company has on-sold your information to (or more rarely had a staff member steal their database), it's also an easy way to see who has been hacked.
One other reason not to use something like SportsOnline@yourdomain.com is that some websites exist merely as credential honeypots and those types are usually aware of this approach and will then typically exploit the catch-all for spamming. The shady All on MP3 service was known for doing this. (I'm pretty sure that site existed solely to exploit the fact that most people used the same password for everthing.)
While I never had that issue, I had Foo’s legal service contact me about using their trademarked name in my email (a short explanation cleared it up)
name_nospam@blah
not only can you not sign up to many services, customer support can often get confused when you need to email reply to them and you cannot email from your aliased email. they see you as a separate user not in their system, or the wrong person replied to the support ticket, etc.
[0] In their webmail client, of course
Capitalisation could also be used for such a purpose, but may be more likeely to accidentally get stripped.
The section on MTA-STS describes how that attack is mitigated.
For this attack to be mitigated everyone should implement it. Gmail and Live.com has MTA-STS records, Fastmail doesn't, one regional provider with millions of accounts doesn't have it too.
And finally your MTA should support it and be configured to deny the delivery if MTA-STS validation fails (and adversary, who is happily MITMing your traffic, shouldn't fiddle with DNS and HTTPS and of course blocking HTTP/S from the MX would be considered cheating!).
All in all, SMTP traffic is encrypted, but it is not secured.
(Disclosure: I work at StartMail.)
Outside of a few niche hardcore technologists, nobody knows what PGP is or how to use it. It would be hard enough getting my mum set up to PGP sign her own emails in Outlook, on the desktop and from her phone. (Is that even possible?). Let alone require anyone emailing her PGP sign their email too? Thats never going to happen for so many reasons, both technical and social.
I'm a software engineer and I tried setting up PGP years ago in thunderbird and it only worked for a few weeks, then it somehow broke. And then later I lost my PGP key. Oh, and then I started using webmail and PGP didn't work there at all.
And then later still I realised my public PGP key (signed by my web of trust) leaked details on the identity of my social network; which bothers me a lot more than any problems I've personally ever had with a forged identity.
PGP is dead. Let it go.