Nettime mailing list archives

<nettime> Google, PGP & the Metadata
William Waites on Wed, 4 Jun 2014 18:05:52 +0200 (CEST)

[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]

<nettime> Google, PGP & the Metadata

Hash: SHA512

                                                  Edinburgh, June 2014

Google  has  announced that  they  are  working on  a  way  to do  PGP
encryption inside web browsers. When it's finished this means that, if
you use  the GMail web site,  your messages can be  enciphered by your
web browser and deciphered by  the person who is receiving the message
in  their web  browser or  email program.  This is  a good  thing, and
something  that we  have  been trying  to  encourage for  a long  time
because the  more encrypted messages flying around,  the better. Right
now using encryption is like raising a flag and shouting "look at me".

But there are a few interesting observations to be made. The first one
is about  Google's business model  of data mining and  advertising. If
they cannot  read the messages, they  cannot do this.  Perhaps this is
changing. Perhaps  the other revenue that  they have has  grown to the
point  where  they can  afford  to forego  the  this  extra source  of
information.  Perhaps emails read  and written  on mobile  devices are
numerous enough  -- they  cannot use this  facility yet  without third
party programs --  that the traffic from the web  site is small enough
to not significantly impact their  bottom line. Whatever the case they
have made  the judgement  that the loss  of visibility and  ability to
derive revenue  from the content  of people's email messages  is worth
the benefit of better privacy.

How are  the keys kept secure?  With PGP you  have a public key  and a
private  key. The  private key  is  meant to  be kept  private and  is
normally stored somewhere and itself  kept encrypted with some sort of
symmetric cipher  using a passphrase.  People do not,  generally, like
typing in long  passphrases so are likely to either use  a weak one or
to  have it  stored in  the  clear or  at best  protected by  whatever
mechanism  they normally  use on  their computer  or phone  (when this
stuff is  available for phones).  The poor state of  endpoint security
and prevalence of all sort  of automated exploits and phishing used to
retrieve information from people's computers and telephones means that
we can expect  an increase in this kind of  activity. The black market
price for  exploits of this  kind might rise  and the botnets  used to
deliver them to grow in size.

Another  weakness arises from  considering how  Google might  handle a
warrant   or  order  requiring   them  to   divulge  the   content  of
messages. When  using a web  site such as  GMail a lot  of proprietary
JavaScript software  is delivered to the  browser to run.  It is quite
conceivable  that  they add  a  function  to  encrypt messages  to  an
additional,  hidden, recipent.   It is  easy enough  with  the OpenPGP
protocol to make the web browser  add a recipient and then to strip it
out within  Google before sending the message  along without violating
the integrity of the message.  That way the recipient would be unaware
that the  message had been intercepted.  Simple.  With some cleverness
and a pocket certificate authority the same thing could be done with a
man in the middle setup by  a nefarious third party. The moral here is
trusting secure communications to proprietary software delivered "as a
service" is foolish.

And the  elephant in the room is  the metadata. It is  well known that
PGP  does not  address keeping  the sender  and recipient  of messages
confidential.  They could not  be delivered  as email  otherwise. This
information, coupled  with other sources  such as location  and search
history and so forth, the so called "pattern of life" analysis that we
have been hearing about recently, is very valuable. Too Google perhaps
it is sufficiently  valuable to overcome the loss  of information from
mining  the content  itself.  Certainly it  is  revealing enough  that
though  it might  hamper those  organisations engaged  in  "full take"
recording of every  bit sent along important paths it  is likely to do
so only slightly.  To fix this we need to also  replace our aged email



#  distributed via <nettime>: no commercial use without permission
#  <nettime>  is a moderated mailing list for net criticism,
#  collaborative text filtering and cultural politics of the nets
#  more info: http://mx.kein.org/mailman/listinfo/nettime-l
#  archive: http://www.nettime.org contact: nettime {AT} kein.org