<nettime> Google commits privacy seppuku at BT's request

[nettime's_captive_audience <nettime@kein.org>]

< http://blog.al4.co.nz/2014/09/google-commits-privacy-seppuku-at-bts-request/ >

Google commits privacy seppuku at BT's request

   As I'm currently in temporary accommodation I have found myself without
   a permanent internet connection. 3G service in the area is pretty
   spotty, so I bit the bullet and ended up purchasing a single month BT
   Wifi pass, effectively piggy-backing a neighbours connection. I'm
   guessing they see very little of the £39 I paid.

   It is well-known that BT has filtering in place, supposedly for the
   protection of children, as required by the UK government. I don't agree
   with this policy, but accept that many do.

   However when it starts to affect privacy, I feel that BT's meddling of
   my internet connection has gone too far.

   Case in point, when using Google on BT Wifi I happened to notice a new
   message on the side:

     SSL search is off

     This network has turned off SSL search, so you cannot see
     personalised results.

     The security features of SSL search are not available. Content
     filtering may be in place.

     Learn More | Dismiss

   After digging into it, I've found that statement to be demonstrably
   false. In actual fact what it should say is; "We have disabled SSL
   search on behalf of your network provider."

   To which I say, thank you for giving me another reason to use
   duckduckgo.

   Google-SSL-disabled

Why

   I can think of a couple of reasons to block SSL search. One is child
   protection and filtering. Disabling SSL search allows BT to filter
   searches for undesirable terms, and theoretically allows them to append
   "?safe=active" to the search URLs. They don't do this though, in fact
   doing so would require the use of a proxy server, which would be a
   whole new level of intrusion.

   The other reason, and the one I feel is more likely to be responsible
   for this policy, is data mining. It's reasonable to expect that BT
   knows the location of every BT Wifi router within 10-15m, because it
   has a home address for every one of them. Whether or not it knows who
   is signed in to Google (it's reasonable to assume it doesn't unless
   it's actually inspecting the contents of the message body, and that
   would be *WAY* overstepping the mark), knowing what is searched by
   location is a marketing gold mine.

So, I'm being data-mined. Great.

   Now how do I get around this!

   The "learn more" page includes a link to "SSL Search for Schools",
   which describes how network administrators can disable SSL search,
   effectively by redirecting users to specific virtual IP addresses via
   DNS.

   Great I thought, I can just use public DNS and avoid BT's.

   Not quite.

   BT doesn't seem to meddle with Google's DNS entries at all. I even did
   a query to www.google.com from my own server, put that IP in my hosts
   file, opened up a fresh browser profile and SSL search was still
   disabled!

   There's something more to it then.

   Running a request with curl shows that the redirection is happening
   completely within Google's network (I've removed some inconsequential
   lines to shorten it a bit):

   $ curl -vL 'https://www.google.com'
   * About to connect() to www.google.com port 443 (#0)
   * Trying 216.239.32.20...
   * Connected to www.google.com (216.239.32.20) port 443 (#0)
   * TLS 1.2 connection using TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
   * Server certificate: www.google.com
   * Server certificate: Google Internet Authority G2
   * Server certificate: GeoTrust Global CA
   * Server certificate: Equifax Secure Certificate Authority
   > GET / HTTP/1.1
   > User-Agent: curl/7.30.0
   > Host: www.google.com
   > Accept: */*
   >
   < HTTP/1.1 302 Found
   < Cache-Control: private
   < Content-Type: text/html; charset=UTF-8
   < Location: https://www.google.co.uk/?gfe_rd=cr&ei=qPYmVL28J4vDcJbFgLAI
   < Content-Length: 260
   < Date: Sat, 27 Sep 2014 17:40:56 GMT
   * Server GFE/2.0 is not blacklisted
   < Server: GFE/2.0
   <
   * Ignoring the response-body
   * Connection #0 to host www.google.com left intact
   * Issue another request to this URL:
   'https://www.google.co.uk/?gfe_rd=cr&ei=qPYmVL28J4vDcJbFgLAI'
   * About to connect() to www.google.co.uk port 443 (#1)
   * Trying 216.239.32.20...
   * Connected to www.google.co.uk (216.239.32.20) port 443 (#1)
   * TLS 1.2 connection using TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
   * Server certificate: www.google.co.uk
   * Server certificate: Google Internet Authority G2
   * Server certificate: GeoTrust Global CA
   * Server certificate: Equifax Secure Certificate Authority
   > GET /?gfe_rd=cr&ei=qPYmVL28J4vDcJbFgLAI HTTP/1.1
   > User-Agent: curl/7.30.0
   > Host: www.google.co.uk
   > Accept: */*
   >
   < HTTP/1.1 302 Found
   < Location:
   http://www.google.co.uk/?gfe_rd=cr&ei=qPYmVL28J4vDcJbFgLAI&gws_rd=ssl

   This above transcript is indecipherable to any one non-technical, but
   what it shows is that Google itself is redirecting me to http by
   sending a 302 "Found" header when I connect to https.

   It's important to stress that I'm connecting to a Google-owned server
   called "GFE/2.0'' (which could stand for "Google Front End"). We're
   then handed off to "gws" later, which presumably stands for Google Web
   Search (or Google Web Server).

   Thus what I've shown here is that the statement "this network has
   turned off SSL search" is false. BT can't be doing it unless it has
   re-routed some of Google's IP addresses, spoofed its SSL certs, and
   hosted its own implementation of GFE before handing you back to GWS.

   This is unlikely, to say the least.

   What we're witnessing therefore, is almost certainly the result of a
   commercial agreement between BT and Google UK. One that exchanges the
   privacy of my searches for BT and Google's commercial gain.

   Duckduckgo it is then.

#  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@kein.org