Does Google Plan to Create Email Aliases for Apps to Fight Spam?

Google appears to be working on an email-forwarding alias system, according to the blog Android Authority, giving users a new way to "shield" their main email address.

The site performed a teardown on the newest Google Play Services' APK looking for work-in-progress code , and spotted "a whole boatload of strings referencing and in support of something called 'Shielded Email'." Just from that text, we're able to infer quite a lot about what we're looking at here, and it appears that Shielded Email consists of a system to create single-use or limited-use email aliases that will forward messages along to your primary account. And while we could imagine that something like this might be pretty useful in Chrome, here it looks like Google is building it specifically to address apps that ask for your email address. The messages in there touch on a couple reasons beyond spam that you might want to keep your main email private, like reducing the extent to which your online activities can be tracked, and mitigating your personal risk from potential future data breaches.
They also sighted a reference to "Shielded Email" in the Autofill settings menu — though their article acknowledges that even features hinted at by work-in-progress code may not ultimately make it into a public release.

But Forbes suggests that the idea sounds similar to Apple's Hide My Email service, which "provides an automated random email address creator to help keep your personal email address private when subscribing to services."

Free service

[africanrhino]

Come use our service for free, develop a dependency with it that we absolutely promise we won’t bait and switch with a paid service. You can trust us, my little crack addict.

Good idea

[Kernel Kurtz]

Having my own domains and the ability to create and manage virtually unlimited addresses, I've been doing this for decades. I'm actually surprised it has taken this long to make it easier for everyone. I probably have hundreds of addresses transparently forwarding to my main one, and they can be deleted at will. It also makes it a lot easier to see which ones end up with spammers, and thus where they got it from.

Plus addressing

[klubar]

This already partially exists with + addressing. You can create disposable addresses by inserting a +;after the local part and before the @. Will not fool a human but useful for random list sign ups.

Also works with Office 365.

Re:

[buss_error]

The + on the LHS is RFC 2822 permitted. If folks are rejecting it, they are running borked MTAs.
I see some chatter that it's a "security risk". It isn't on Sendmail or Postfix, as I've run many thousands of servers with those two software packages and never did have even one server hacked. Accounts, yes, but that was always traced to the MUA and not the MTA.

Don't know about Exchange. Never dealt with that hot mess as an MTA.

one wonders why

Standard answers:
If asking "why" for a business, the answer is almost always "money"

Re: Plus addressing

[madbrain]

A large number of web sites and apps either reject the + addresses, or just strip what's after the +, unfortunately.

Re:

[lsllll]

You mean like mailinator [mailinator.com]? I usually md5sum a file I have on my HD which I know is not going to change and use so many characters of [e-mail]. Some places have caught on, so they won't accept @mailinator.com, but they have over 200 other domains that can receive mail.

There's a more important use for this

[Arrogant-Bastard]

Some of us started deploying this tactic on our email servers back in the 1990's, and provided it's done correctly, it's does help out quite a bit in stopping spam from being delivered. (But of course it doesn't stop it from being sent, and spammers can/will continue to attempt delivery to no-longer-working addresses for years, and even decades, because there's no reason for them not to: it would cost more money, time, and effort to trim their lists than it does to just keep hammering away.) Note that part of "correctly" above requires judicious selection of addresses, and another part requires returning SMTP 5xx responses when they're turned off, and another part....well, let's just say that doing this correctly requires a little thought.

But that's not why I wrote this: as the subject line indicates, there's a more important use for these, and that is: early notification of security breaches and dataloss events. If you have a unique address known only to you and business ABC, and you've properly secured it on your side, and the email server has properly secured it on their side, and it starts getting traffic from anyone/anything other than ABC...then something bad has happened. Maybe they gave away the address; maybe they sold it; maybe they were hacked; maybe something else. Having used this tactic personally for about 1500 such addresses for about 23 years (and on mail servers that I personally run) I can report that it doesn't happen often, but when it does, it's often followed by a breach notification weeks to months later. (There are exceptions, of course.) That's why I recommend doing this with the addresses/accounts that are critical, like financial institutions, and further why I recommend being meticulously careful when doing it -- it's worth it.

In a better world, we wouldn't have to bother with this. But in a better world, spammers would be shut down promptly (as once upon a time they were) and businesses would spend more money on information security and less on endless, worthless vice presidents. But here we are.

Here's an idea:

[newcastlejon]

Don't deliver misaddressed emails.
If I have the address [e-mail], I will get emails sent to [e-mail] and similar. Every. Single. One. is spam.

Here's another idea: don't reward bad app behaviour.
If an app asks for my email address for no reason and won't work until I confirm it, it gets uninstalled.

Re:

[gweihir]

One of the reasons I run my own MTA: gmail sucks.

fundamental theorem of software engineering (FTSE)

[CyberSlugGump]

"All problems in computer science can be solved by another level of indirection" (A famous aphorism of Butler Lampson that is attributed to David Wheeler)

Hide my email

[Paradise Pete]

Apple's Hide my email works really well. It offers to create an address for you on the spot any time you're entering one, and the service has been flawless.

The downside is it's not free, but rather bundled with other things. I'm fully sucked into the ecosystem, so for less important uses I find it very handy.

Like Yahoo Mail's temporary addresses

[MLXXXp]

This appears to be very much like Yahoo Mail's "Temporary email addresses". There, you choose a single prefix (that's different from your primary address) that is followed by a dash and anything you choose, followed by @yahoo.com. E.g. [e-mail]. You can have multiple addresses each with a different string in place of the xxx. Mail for all of these aliases is sent to your normal inbox but you can filter them to different folders if you wish.

If you start to get spam on one of these addresses, you can delete that address (and create a different one in it's place, if you wish). The unique address might also give a clue about how it became used for spam.

Re:

[pepsikid]

I have my own domains so I like to generate unique emails for each merchant or other resource I sign up with. I also add a numeric code at the end.
Most of them hate it when you use their own name in YOUR email address, so I just reverse it. Yahoo would become [e-mail].
But the numeric code isn't random. I grab today's Julian day number and use that so I can also see how long it took for my address to be compromised.
[e-mail] is what I would use if I had to provide a "permanent" e

Re:

[pepsikid]

Optimally, your email server would silently drop the connection and waste the spammer's time waiting for timeout. You don't want to return a code for "bad email address", since that just helps the scumbags.

Re:

[buss_error]

You don't want to return a code for "bad email address", since that just helps the scumbags.

Talk to John Levine [johnlevine.com] He had a bit to say (in contravention to your point) at CAUSE in 2005 (if memory serves).
You could talk to me, but I only did a few thousand servers from 1996-2012, and at that time, I never noticed that a 5XX ever did anything to change a spammer's tactics.
SWAT teams at their home, yes.
Hit squads [wikipedia.org], yes.
But rejects? Not once in the time frame above. Of course, they may have gotten more civilized, considerate, and compassionate since then.

Ulterior Motives

[organgtool]

E-mail addresses serve as a unique identifier for users and can be cross-referenced across entities within a conglomerate, or among third-parties who share PII with each other. This service that Google is offering will make it more difficult for these organizations to correlate data among accounts on different platforms, while ensuring that Google remains the primary entity capable of connecting those dots. While Google may not have as much data about the details of the third-party accounts as the organizations that provide those services, it ensures that those providers won't be able to correlate as much data about their users, which will make them more reliant on Google for advertising.

Re: Ulterior Motives

[bradley13]

This.

The difference

[devslash0]

While services like HideMyEmail provide a similar service, the domain of a dynamically generated email gives away the important fact that it's an alias. This allows email validators to very easily disallow aliases and weed out any "shielded" addresses. If Google proceeds with this service, all emails, shielded or not, would be in the same domain which would prevent validators from discriminating against aliases.

Aliases should have been there from the start.

[devslash0]

Too little, too soon. Aliases should have been a part of the email service design from the start. Replacing your real email address with an alias doesn't bring the use any benefit since the company already knows what your real email address is. Would only affect future accounts

1-to-1

[devslash0]

I've been using aliases for years. Initially with a homegrown email server, later with Proton for reduced maintenance. Currently, every single online account of mine is linked to an exclusive email address, on a 1-to-1 basis. When your data leaks and/or you start receiving spam, you know exactly which company leaked/sold your data and you can cut the wankers off.

Fastmail

[Mostly a lurker]

One email service I use, Fastmail, has had this kind of alias capability for over 20 years. It makes spam management a lot easier and (by hiding your account name) also contributes to security.

yourbusiness@mydomain

[madbrain]

Is what I have been using for about 15 years. I give a different one for each app or web site I interact with. If I ever get spam from one of them, I know if they sold my email or they got hacked.

I have it setup with a catch-all mailbox and POP3 SSL server. In my Gmail account, it is configured as an external account.

The biggest problem is that Gmail fetches the POP3 email very randomly. It can in fact take many hours, by which time any 2FA code is long expired, for example. You can refresh manually from a desktop browser. I have not found a way to do so from a mobile browser, even using desktop mode. The Gmail site just doesn't render the same, and the refresh option is missing.

So, I run Firefox on a raspberry Pi with Tampermonkey extension, and a script by Daniel Slaughter called POP3 email fetcher. It's set to refresh every 3 minutes. That is the highest frequency Google will let you fetch.

Federation is the right implementation

[fishdan]

I've been a spamgourmet user for 25 years, and it's been perfect but... Email as designed is fundamentally designed for a friendlier universe and thus easily exploited. To fix this email should deliver ONLY a secure link to its payload that is hosted by the sender. If I send you and email, in your email (or sms or any other delivery protocol) you get a notification: "Fishdan has sent you a message. To read it click fishdan.com/mail?recipient=[e-mail]&secretpin=19700101&othersexritything1=foo&othersecuritything2=bar&clientsecurity=&mysecurityclientid=918273123012 etc etc You could even have a thing where if I want to send you a more secure email I require your browser to have a JWT (or whatever) that you only get by answering a second email. Etc etc. Contentlink is evaluated by your email client AND your browser for safety. IF it's an official certification it gets a better trust rating etc. has to match the send of the email and your email reader assigns a trust rating to it that you see when opening the email and again when following the content link.