Google introduces Customer Match

Discussion in 'privacy general' started by TheWindBringeth, Sep 28, 2015.

  1. TheWindBringeth

    TheWindBringeth Registered Member

    Joined:
    Feb 29, 2012
    Posts:
    2,171
    http://adwords.blogspot.com/2015/09/Google-brings-you-closer-to-your-customers.html
    http://adage.com/article/digital/google-people-s-email-addresses-ad-targeting/300533/
    I was very tempted to exclude that "secure and privacy-safe way" assertion from Google.
     
  2. mirimir

    mirimir Registered Member

    Joined:
    Oct 1, 2011
    Posts:
    9,252
    That's just too much :eek:
     
  3. MisterB

    MisterB Registered Member

    Joined:
    May 31, 2013
    Posts:
    1,267
    Location:
    Southern Rocky Mountains USA
    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.
     
  4. mirimir

    mirimir Registered Member

    Joined:
    Oct 1, 2011
    Posts:
    9,252
    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 ;)
     
  5. Minimalist

    Minimalist Registered Member

    Joined:
    Jan 6, 2014
    Posts:
    14,881
    Location:
    Slovenia, EU
    I never search or browse while logged in my gmail account. Doing that would be insane to me.
     
  6. TheWindBringeth

    TheWindBringeth Registered Member

    Joined:
    Feb 29, 2012
    Posts:
    2,171
    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.
     
    Last edited: Sep 29, 2015
  7. driekus

    driekus Registered Member

    Joined:
    Nov 30, 2014
    Posts:
    489
    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.
     
  8. TheWindBringeth

    TheWindBringeth Registered Member

    Joined:
    Feb 29, 2012
    Posts:
    2,171
    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.

    A day or two after this broke, I searched for additional articles/discussions. Several sources were approaching https://support.google.com/adwords/answer/6276125?hl=en in a critical fashion, focusing on the "if necessary" qualifier:
    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.
     
  9. deBoetie

    deBoetie Registered Member

    Joined:
    Aug 7, 2013
    Posts:
    1,832
    Location:
    UK
    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).
     
  10. Nebulus

    Nebulus Registered Member

    Joined:
    Jan 20, 2007
    Posts:
    1,635
    Location:
    European Union
    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...
     
  11. TheWindBringeth

    TheWindBringeth Registered Member

    Joined:
    Feb 29, 2012
    Posts:
    2,171
    @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?
     
  12. driekus

    driekus Registered Member

    Joined:
    Nov 30, 2014
    Posts:
    489
    Precisely why I use email alias for every site I interact with. Many of the privacy conscious email providers over this service.
     
  13. deBoetie

    deBoetie Registered Member

    Joined:
    Aug 7, 2013
    Posts:
    1,832
    Location:
    UK
    @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....
     
  14. TheWindBringeth

    TheWindBringeth Registered Member

    Joined:
    Feb 29, 2012
    Posts:
    2,171
    @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...

    A typical life cycle might be:
    1. Email address is configured (setup and capable of receiving email)
    2. Email address is assigned (registered at a site)
    3. Email address is de-assigned (no longer used at a site)
    4. Email address is de-configured (no longer working, email rejected or to catch-all)
    5. Email address is old enough to be removed from records (optional)
    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.
     
  15. driekus

    driekus Registered Member

    Joined:
    Nov 30, 2014
    Posts:
    489
    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

    Other email providers use similar solutions.
     
  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.