Customer Match is a new product designed to help you reach your highest-value customers on Google Search, YouTube, and Gmail... Customer Match allows you to upload a list of email addresses, which can be matched to signed-in users on Google in a secure and privacy-safe way.

Click to expand...

Let's say you’re a travel brand. You can now reach people who have joined your rewards program as they plan their next trip. For example, when these rewards members search for “non-stop flights to new york” on Google.com, you can show relevant ads at the top of their search results on any device right when they’re looking to fly to New York. And when those members are watching their favorite videos on YouTube or catching up on Gmail, you can show ads that inspire them to plan their next trip.

To accomplish this customer matching, Google will be cross-referencing brands' email lists with the email addresses tied to people's Google accounts, the majority of which are Gmail addresses though people can use other email providers to sign up for a Google account... Google will use a process called "hashing" to disguise the email addresses on both sides of the match and prevent any personally identifiable information from being exposed.

Click to expand...

Google's Customer Match targeting option is similar to Facebook's three-year-old Custom Audiences and Twitter's two-year-old Tailored Audiences, but more pared down than the social networks' versions. All three products let brands target people based on their email addresses. However Facebook's also includes people's phone numbers, user IDs and mobile ad IDs, and Twitter's includes people's Twitter account handles.

Click to expand...

I was very tempted to exclude that "secure and privacy-safe way" assertion from Google.

It sounds bad but upon reading it I realized that what I'm doing already completely defeats it. I have serious adblocking in place at the receiving end and have numerous compartimentalized accounts with Google and any email addresses I have that got into this system would be shells.

Yes, but most people don't do stuff as we do. So there's potential for truly creepy and disturbing ads. Google says that they'll police it. But there will be violations. Just imagine the sorts of ads one could craft, based on the Ashley Madison dump

At a high level, I think this is the type of thing that privacy valuing people don't want to see: Companies sharing information about their customers with other companies, especially for secondary purposes such as targeted advertising. So in addition to any/all issues with this move, there is also the "hashes today, what tomorrow?" aspect to it that creates a shiver in those who appreciate slippery slopes.

I can't tell if there will be an option to upload plaintext email addresses for hashing on Google's side, but based on what I've come across it appears that if a company uploads hashed email addresses it is to use SHA256. I'm not sure how the math plays out on email address space, but I think that results in companies sharing a highly unique identifier. One that may become even more reliably unique if/when other factors come into play. What are the chances that two companies that serve the same relatively small area would upload the same SHA256 for different customers?

Google has personally identifiable information (plus a whole lot more) for how many email addresses and Internet users? If you count not only those who directly expose such information to Google, but also those who indirectly expose such information to Google (ever emailed a Gmail user or company using Google services under your real name?), I think the database would mushroom. Google has likely already generated the SHA256 hashes for whatever email addresses it has, and looking up other info related to the SHA256 certainly shouldn't be difficult for Google. I'm disregarding any "promises" not to do so, of course.

Lets say Company X uploads SHA256 264e53d93759bde067fd01ef2698f98d1253c730d12f021116f02eebcfa9ace6. Google could lookup that hash in an email/hash database, and determine the email address for it (which just happens to be example@gmail.com). Then access any other information that is associated with that email address. Lets say it belongs to Foo Bar, Jr and Google knows that. Has not Company X effectively told Google that Foo Bar, Jr. is its customer simply by uploading that hash?

In that particular example, Google may already know that Foo Bar, Jr is a Company X customer as a result of Company X having sent client emails to example@gmail.com. However, what if the email address weren't a gmail address? What if Company X uploaded secondary email addresses too? What if Google does include non-Gmail addresses in an email/hash database?

I think we'd also have to consider what information might be correlated to the SHA256 hash and exchanged that way. Can companies setup specific types of campaigns that reveal more fine-grained information about customers? Will there be information flowing from Google (as a result of ad views, ad clicks, and/or other things) back to participating companies, in a way that would allow them to append the information to their client database?

This hashing business seems like an attempt to skirt the "email addresses are usually recognized as PII" issue in a way that seems privacy friendly but really isn't. Companies can generate hashes using a common algorithm, exchange those hashes (possibly along with other very revealing information), and supplement their databases, all while CLAIMING to never share personally identifiable or personal information.

Very scary and not at all surprising. Id also guess they look at the email addresses of the people you talk to as well as part of this service.
Personally Iam not too concerned, but the general population is really up just another piece of their soul.

I think you'd have to give a unique email address to each company you interact with. Given how many individuals are likely to be mishandling other peoples' contact information, and the general risk of email datamining, it would arguably be wise to give individuals unique email addresses as well.

Email addresses in the file are hashed (if necessary) and separated by a comma or a line break

Click to expand...

and postulating that the hashing is entirely voluntary and unlikely to be used in practice. Either way, it would also seem prudent to avoid using your real name and/or known nicknames in the email addresses you give out. Overall, such steps would practically require the use of a password manager.

Choosing a sufficiently ethical and privacy-friendly email provider that allows ample numbers of aliases, or getting an email server setup, is the toughest part. I think someone moderately tech savvy could get over that hump and handle the rest.

Is anyone aware of a random email address manager akin to a password manager? That could provision email addresses (say within a domain) on demand, and keep records of which site were which? I mean, I have scratch or throw-away ones, but cannot be asked generating and storing them (though Lastpass would help with that).

Is anyone aware of a random email address manager akin to a password manager?.

Click to expand...

Why don't you use a password manager? Keepass for instance has a "Notes" field that you can use to store the email for each domain/site that you use. If you also want a random email generator that is more complicated, since most sites will require some form of email verification...

@deBoetie: I've used several such systems over the years, but each was designed to suite my own context at the time and I wrote whatever code was necessary. I can't point you to an off the shelf solution, or necessarily point out something you aren't already aware of, but a few thoughts anyway...

Generating random email address strings is trivial. There are some other options worth thinking about for a minute. Such as incorporating an encoding scheme so that even without a database lookup you can tell whether the email address is one that you generated. You could also choose a scheme that when decoded will provide a clue as to where the email address was [and wasn't] used. Perhaps even when it was assigned. Any such scheme should support multiple email addresses being given to the same site. It would not be good if others could figure out the scheme and guess correct email addresses for sites. No matter what the approach, you'd want to avoid generating dupes.

One alternative to more complex systems would be to use a tool to generate a block of email addresses, save that "available list" somewhere safe (special area of password manager or whatever), and manually provision those email addresses in one sitting. Then, when you need an email address, you just cut from that list of already setup and working addresses, and paste into the password manager entry you are working with. If your password manager supports searching, you'll be able to find the entry that goes with a given email address. There will be times when you want to lookup an email addresses that was used in the past, either to assure no collisions and/or know where one was used. A password manager with a searchable history feature would help. Alternatively, you could manually keep a history list in each entry or when changing/deleting email addresses you could save info to your "previously used list".

On the provisioning side, you'll have to narrow down exactly what you want to do. Provision email address accounts, aliases, both? Deprovision as well, presumably. Local or remote? Is there a web interface restriction or can you use SSH? This piece is a somewhat generic problem, in that there are many tasks admins want to automate. Many use local, or at least central, scripts/tools to remotely manage their servers. So one should be able to find reference material, closely related example code, and perhaps even [near] complete examples of setting up addresses and aliases.

Any kind of database/storage could be used to hold such information [in encrypted form], and a simple solution would be simple to interact with via a script that could also take care of the provisioning. Very few people do this type of thing we're discussing, but there are other scenarios where an admin might want to maintain a database that holds information related to an email address. Here again, a search might turn up example code... if you don't feel like writing something from scratch.

If you want the information to be stored in a particular password manager, then you'll have to investigate the interface options. Does the password manager have a feature, or support addons that could provide a feature, that can interact with a local or remote script? Can a script drive the password manager, pushing/pulling things via cmdline or API? Is there a way to leverage custom URLs within the password manager to do provisioning through a webserver?

I think you'd have to give a unique email address to each company you interact with. Given how many individuals are likely to be mishandling other peoples' contact information, and the general risk of email datamining, it would arguably be wise to give individuals unique email addresses as well.

Click to expand...

Precisely why I use email alias for every site I interact with. Many of the privacy conscious email providers over this service.

@TheWindBringeth - thanks a lot for your thoughts, I think the block allocation thing is likely the most sensible, and restricts the amount of scripting I'd have to do. Can manage the blocks with a spreadsheet and Lastpass and a bit of cut and paste. No biggie.
Also, perhaps I'll suggest it as a feature for Lastpass - I mean, if they could offer an add-on mail service under a domain owned by them, then it could be integrated into the tool in the same way as password generation. I don't particularly mind them seeing the emails from the kind of people I'd do this for, but then maybe it's too much of a risk, though probably better than what I do at the moment anyway....

@driekus: I don't know whether I saw you say that before, it was your expressing confidence, or both, but I figured you were doing so. I just wanted to see some stuff explicitly mentioned in the thread, for the potential benefit of anyone that might not be aware of it.

@deBoetie: The whole thing can actually be done by hand, and if you convert over in stages (a chunk one day, a chunk some other day, ...) it wouldn't be too bad. Automate what you can though, right? The part that would be most annoying would probably be changing the email address at numerous sites and confirming the new addresses. On that note, and since I failed to mention it...

Having delays between 3/4 and 4/5 can be useful, especially if you don't use a catch-all. Such delays could be part of a manual process. If one is going to automate, they might want to implement a feature which takes care of these mundane chores.

@driekus: I don't know whether I saw you say that before, it was your expressing confidence, or both, but I figured you were doing so. I just wanted to see some stuff explicitly mentioned in the thread, for the potential benefit of anyone that might not be aware of it.
.

Click to expand...

I am assuming that you are referring to the comment on using email alias.

Countermail offers the ability to setup up to 20 email alias (https://countermail.com/?p=alias)
Neomailbox handles it differently and lets you setup a subdomain. Anything sent to that subdomain will forward to your main email. I handle the email addresses by setting up my amazon account to go to amazon@mysubdomain.neomailbox.ch