Privacy risk in using Google APIs

Question

If I use JQuery from Google APIs: http://ajax.googleapis.com/ajax/libs/jquery/1.10.1/jquery.min.js

Is there a privacy risk to my site? E.g. does this link enable Google to read my pages, track my site usage, etc.?

Answer 1

As far as tracking is concerned, this is not any different than linking to any third-party / external resource. Limiting the list to most relevant HTTP request information sent in its header that are read and can be used to track user activity by the content server:

• Cookie - Client software is supposed to limit cookies that the external server can retrieve to only those whose domain and path path attributes match the domain and path of the server receiving the request and have not expired. Additionally, they're limited to presence of a secure flag to only be accessed through a secure connection, when this flag is present in the cookie. Cookies can be read and written to, so technically Google could attach a new tracking cookie to its response and track user agents (web client software) this way. So far, I haven't noticed any request to write tracking cookies, or indeed cookies for any other purpose attached to Google server's response when requesting jQuery API. Most client software also has capability of warning users of presence of third-party cookies and/or block them, depending on client preferences. Since EU's cookie law requires of all website operators to clearly warn of use of cookies on any pages that do so, Google can't really change their mind and all of a sudden start tracking requests by attaching a tracking cookie without triggering alarms.

• Referer - This is the address (URL) of the web page from which the external resource was requested from. The word “referrer” is misspelled in the RFC as well as in most implementations. There is really absolutely nothing stopping Google to use this data for statistical / tracking purposes, as it's a part of the standard HTTP request. While this referer information in the HTTP request could be removed (or changed to non-disclosing URL) by redirecting requests at the server linking to Google's external resource, or by other means of anonymizing external requests, not many web servers actually do so. The information is hardly critical on its own, but could be linked with other HTTP request data to identify request originating client more precisely.

• User-Agent - This request field identifies the client software through the use of a user agent string. They would usually contain all kinds of information about your client software and its capabilities (browser type, browser version, extensions, operating system, operating system's version, libraries used by the web client,...) and can be used to identify a unique web client to a varying degree. See for example the Panopticlick project and test your browser how unique it is among all that were so far tested. User-Agent can of course be changed by the client software to contain less identifying information (something e.g. TOR browser does on each "change identity" user's request), but most users would be unaware of how well their browsing habits can be identified by this HTTP request field alone, and of course do nothing about it. Google can use this information to identify web clients more uniquely and/or for other statistical purposes. This is something you as a publisher linking to an external resource can't control (it is attached to the request headers on client's end and the HTTP GET request to the external resources linked within your documents is not handled in any way by your own web server).

• IP address - Not really a part of the standard HTTP request header, but of a TCP/IP request itself (transport protocol level), this address uniquely identifies the request originating network client so the response can be sent to its intended recipient. There are ways to bypass this identification through the use of the IP address by using various Proxy or VPN solutions. Not all of them will be as effective though, and some proxies will attach additional headers to the HTTP requests (such as X-Forwarded-For) that can lead to revealing request originating IP address, or that a Proxy server was used (e.g. Via) to retrieve server's HTTP response.

All the possible HTTP request header information is listed in this Wiki page, some of them could be used to track fingerprint individual web clients, while most are actually benign in this sense and would remain more or less the same for all web clients, and are thus useless for identification purposes.

It does get slightly better though. Since you're linking to Google API as an external resource via your DOM, the client software parsing its contents and generating external requests will use a GET method to retrive its contents, so none of the data that are a part of POST method's body (such as form data) can be read through such request, regardless of what HTTP request method was used to fetch contents of your document that links to this external resource.

This might or mightn't be a good news though. If you, for example, authorize users through the use of a session token passed to the server via URI field value to access resources on your server, you don't use HTTPS on your server, and you link to the jQuery API using protocol-less URL starting with //, these URI fields will be repeated in the "referer" string and Google will see them in requests to their server. In other cases (you use HTTPS, or authenticate via a POST request and write session tokens to clients using cookies / user storage / session storage), this "referer" information won't be included in GET requests (HTTP body fields used in POST method don't leak into HTTP header fields on new requests), or none of the user data will be leaked through it (HTTPS protocol does not include "referer" information in requests to external resources, no matter what protocol they're served through).

As for the other part of your question - does this link enable Google to read my pages - well yes, of course it would be possible. Basically, what you're enabling by willingly linking to an external resource you don't have control over is XSS type attacks and, technically, Google could easily take over your web pages where you're linking to this jQuery API and completely change them to their liking. They won't do that though, as it would pretty much spell game over for them. Any changes to these libraries Google helps publish are also relatively easy to track by comparing received files that Google publishes to those published on the official jQuery pages, either by calculating MAC signature of the received file and check its data integrity and authenticity against MAC signatures of files on the jQuery pages, or simply comparing files line by line.

So in short, yes it is possible that Google is tracking users' browsing habits through inspecting HTTP and TCP/IP request values associated with requesting external resource such as jQuery API Google helps publish on its servers, but if they're doing that, they aren't resorting to active tracking by attaching tracking cookies to their responses. That will limit their ability to successfully / uniquely identify web clients for any other than statistical purposes. There is no bypassing this short of web clients using TOR / Proxy / VPN servers, or you publishing jQuery API on your own server. Changing this API to include malicious code is however nigh impossible without detection, and would spell disaster for Google's reputation.

Do mind though, that we haven't really excluded any MiTM attacks here, where such linking to external resources does provide for an added bonus to a would-be attacker, that could simply substitute any such request with a location of attacker's choosing and use it as a malicious payload vehicle.

Your best bet in thwarting such threats described would be to simply publish jQuery API on your own server(s). It does come with a bit of cost to each of your users' requests, namely one more request your web server has to handle and adds to the bandwidth needed to serve requests, but it will remove all the risks described, no matter how plausible they might be.

Answer 2

Technically, yes, Google could do a lot of this. Namely, when you "use JQuery" in your site, you actually mean that the pages of your site reference that piece of Javascript, and whoever browses your site will automatically download it from Google's servers, allowing Google to easily know who downloads it, when, and in which site the link was found (because of the Referer header). This is easy to do, undetectable on your side, so one should assume that Google does it (if they are up to their reputation, that is).

Reading your pages is another matter. They could play nasty tricks by modifying the contents of that jquery.min.js file, in order to do various things with your site pages, including reading parts of it and sending them back to some server. However, this would entail a risk of detection, since that would be an active attack. Google's motto is "don't be evil" and they can maintain it only on the condition that they never look evil. Indulging in active attacks could seriously damage their image, and I doubt they would risk that for something as trivial as reading back your Web site (well, I don't know what your Web site does, but I doubt that what it contains would match the net worth of Google itself -- I hope you won't feel offended at the comparison).