NNSquad - Network Neutrality Squad
[ NNSquad ] Re: [ PRIVACY Forum ] Technical explanation of why Google's Wi-Fi payload collection was inadvertent
Privacy International seems to relish every possible opportunity to attack Google. The actual *facts* of a situation appear to often take a definite back seat in PI's analysis of any Google-related matter. I personally don't know if this is due to a seeming lack of technical sophistication on the part of PI's primary management, or perhaps is the result of some other causative factors. Just my opinion, of course. --Lauren-- NNSquad Moderator ----- Forwarded message from Jay Libove <libove@felines.org> ----- Date: Sat, 19 Jun 2010 14:09:57 -0500 From: Jay Libove <libove@felines.org> Subject: RE: [ PRIVACY Forum ] Technical explanation of why Google's Wi-Fi payload collection was inadvertent Hi Lauren. Attached is a post I just made to my Facebook wall and to one of my Privacy oriented LinkedIn groups. I think it does a much better job than any other post or article I've yet seen as to why conclusions that Google had evil intent are premature. Feel free to use it, with attribution please, if you wish. -Jay - - - Date: Sat, 19 Jun 2010 14:07:18 -0500 From: Jay Libove <libove@felines.org> Subject: posted to LinkedIn and Facebook re: Google Street View Wi-Fi data collection To: Jay Libove <libove@felines.org> Privacy International has - inappropriately, in my view - drawn the "conclusion" that Google acted with ill intent, privacy violation aforethought, in its design of the Street View data collection vehicles' Wi-Fi data collection code. They base this on the Stroz Friedberg independent report on the data collection code. I've read that report. I don't come to the same conclusion that Privacy International did. I come only to the conclusion that a legal investigation, looking at Google's internal business processes and documents leading to the Wi-Fi aspect of the Street View program must be performed. Separate from "conclusions", the Stroz Freidberg report leads me to think that Google did *not* act with intent to breach the privacy of wireless communications with its Street View vehicles' Wi-Fi data collection. What bothers me so much about the reaction to the Google Street View Wi-Fi data packet capture situation is the proclamations e.g. from Privacy International that there is "proof" of Google's "criminal intent" in the way Google built the Street View data collection program. I've found the specific audit report, by Stroz Friedberg, here http://static.googleusercontent.com/external_content/untrusted_dlcp/www.google.com/en//googleblogs/pdfs/friedberg_sourcecode_analysis_060910.pdf<http://static.googleusercontent.com/external_content/untrusted_dlcp/www.google.com/en/googleblogs/pdfs/friedberg_sourcecode_analysis_060910.pdf> (attached) to which Privacy International was referring in their complaint, http://www.privacyinternational.org/article.shtml?cmd%5b347%5d=x-347-566346 (copied below in this email). I've just finished reading the entire Stroz Friedberg report. Privacy International says this about the analysis of the gslite package (the custom core component of the Street View data collection program relating to Wi-Fi data capture): "This means the code was written in such a way that encrypted data was separated out and dumped, leaving vulnerable unencrypted data to be stored on the Google hard drives. This action goes well beyond the "mistake" promoted by Google. It is a criminal act commissioned with intent to breach the privacy of communications." The report makes quite clear that the gslite code, as written, without any question does keep and store the payloads of data packets which do not have the protected flag set. (That is, are not encrypted data packets). What the Privacy International indictment infers, and it is this inference with which I take issue, and which can only be justified by a further investigation in to the internal engineering and business documents of the Street View data collection program, is that it is a "criminal act commissioned with the intent to breach the privacy of communications." There is a wide gulf between the commissioned intention of a program and the specific way in which the program is implemented. The Stroz Friedberg report analyses how the program works. It wisely does not attempt to draw any conclusions about how the program was commissioned, nor the intentions of the program. Reading the report's detailed review of the program structure, and putting back on my programmer's hat (which I had to dig around in my closet to find, and then dust off heavily, as I haven't been a programmer in more than a decade), it seems much more likely to me that the programmer decomposed his problem in a way to make for the easiest re-use of available code, and then stupidly (in fact, possibly criminally stupidly, but still stupidly rather than intentionally, and rather than by commissioned instruction from his business managers) left the code in a state which resulted in unencrypted data packets' payload buffers being written to disk, than that the programmer was "commissioned" to "breach the privacy of communications". I now move away from the actual findings of the technical report on the gslite code, and begin to try to divine the intentions of the programmer and his bosses in the construction of this code. That truly is what we're doing, trying to divine, to read the minds of people from four years ago when this code was commissioned exactly what they intended to accomplish. The report on the gslite code shows quite clearly that certain potentially very interesting information is deliberately discarded from data frames (in particular, the "to DS" and "from DS" fields, which identify the sending and receiving wireless devices' MAC IDs). If I as a programmer on my own or by commission of my bosses, had the intention to breach the privacy of communications, then I'd have very much wanted to keep the source and destination addresses of the data frames for future reassembly and for deeper analysis of what I might learn about those devices and their relations. I also wouldn't have set up channel hopping as this code does; I'd instead have built the Street View data collection devices with 11 or 14 Wi-Fi receivers - enough to keep one receiver locked to each specific available channel. These receivers are quite inexpensive, so having 11 or 14 is not a substantial cost impediment for a company like Google if they actually wanted to capture wireless session data. I infer that the Street View data collection vehicles had only 1 Wi-Fi receiver device from the evidence that the gslite code (actually, the underlying kismet) was configured to scan all 11 or 14 available data channels every 2-2.5 seconds. Note that the "11 or 14 instead of 1" is the result of needing, if we had the intention to capture session data, one receiver per licensed data channel; and the fact that the number of licensed data channels varies around the world. The above leads me to believe that the program was commissioned to do just what Google says it was - to map wireless networks as the Street View vehicles gathered photo data, to better locate the photos. The above further leads me to believe what Google has said about why the unencrypted data packets' payloads were kept - that it was a stupid mistake. Only a further investigation in to the business and engineering project management documents around the program will tell us what people were actually saying about how the project was to be designed, and the degree to which this specific code path was analysed and intentioned, and therefore only that further investigation would allow us to discern criminal intent or lack thereof. I analogize a bit: For these purposes, I had to find a European privacy law which specifically deals with sensitive categories of personal data. Neither the EU DPD itself, nor the UK DPA delves to the level I'm looking for. The Spanish Royal Decree 3/2010 published in the BOE 29/01/2010 has what I was looking for. As background, Spain has unusually detailed regulatory requirements for the protection level of personal information based on the sensitivity or risk levels of that information. Normally, any processing of sensitive personal information (e.g. sex, health, trade union membership, political ...) requires that the data be protected at a 'High' level. (There are three protection levels defined, 'Basic', 'Medium', and 'High', with a fourth 'Medium-High' level lately added specific to geolocation data in telecom). RD 3/2010 clarifies that any purely incidental processing of sensitive categories of personal data need not raise the security protection level of the data above 'Basic'. This is a useful guide, based on risk management principles, to how we might think about the criminal penalties to apply to a case where an incidental (stupid) rather than a directed (intentional, commissioned) unlawful processing of personal data occurs. It is likely that Google's act of storing unencrypted data packets' payloads crosses criminal lines in some jurisdictions. It remains to be seen from further business process investigation whether this was the result of incidental stupidity vs. of intentional commissioned criminality. In the case where it is found that this was the result of incidental stupidity, and especially if investigation shows that the collected data was not used, then just as the level of protection demanded even of a sensitive category of personal data remains at 'Basic', the penalty for incidental processing should also remain at a low level. It is unbalanced - and I assert counterproductive - for privacy advocates, among whose ranks I proudly consider myself, to scream "proof of criminal intent!" when the case is not yet analysed to the level necessary to divine intent. It smacks of "crying wolf", which puts us at risk, when a real criminal intent is found, of the world being less willing to listen and take right action. What do you think? Have some of us gone too far in indicting Google on its *intentions* (which I assert we don't know yet, and won't know until deeper investigations are completed)? Does that shoot us in the foot - harm our own cause - by getting ahead of the known facts? I strenuously join the calls for the necessary investigation in to Google's internal business and technology process documentation to truly divine their intentions and how the Street View vehicles' Wi-Fi data collection code ended up written and working exactly as it did. Only then can we assign the correct responses and penalties. Privacy International's actual posting, as linked above: Description: Privacy International<http://www.privacyinternational.org/index.shtml> Description: http://www.privacyinternational.org/images/blank.gif Privacy International Google Wi-Fi audit reveals criminal intent by the company 09/06/2010 Google today published an audit on its blog<http://static.googleusercontent.com/external_content/untrusted_dlcp/www.google.com/en/googleblogs/pdfs/friedberg_sourcecode_analysis_060910.pdf> of the code used to collect Wi-Fi data as part of the company's global Street View operation. The report asserts that the system had intent to identify and store all unencrypted Wi-Fi content. This analysis establishes that Google did, beyond reasonable doubt, have intent to systematically intercept and record the content of communications and thus places the company at risk of criminal prosecution in almost all the 30 jurisdictions in which the system was used. The independent audit of the Google system shows that the system used for the Wi-Fi collection intentionally separated out unencrypted content (payload data) of communications and systematically wrote this data to hard drives. This is equivalent to placing a hard tap and a digital recorder onto a phone wire without consent or authorisation. The report states: "While running in memory, gslite permanently drops the bodies of all data traffic transmitted over encrypted wireless networks. The gslite program does write to a hard drive the bodies of wireless data packets from unencrypted networks." This means the code was written in such a way that encrypted data was separated out and dumped, leaving vulnerable unencrypted data to be stored on the Google hard drives. This action goes well beyond the "mistake" promoted by Google. It is a criminal act commissioned with intent to breach the privacy of communications. The communications law of nearly all countries permits the interception and recording of content of communications only if a police or judicial warrant is issued. All other interception is deemed unlawful. Some jurisdictions provide leeway for "incidental" or "accidental" interception. However where intent to intercept is established, a violation of criminal law is inevitably created. This action by Google cannot be blamed on the alleged "single engineer" who wrote the code. It goes to the heart of a systematic failure of management and of duty of care. ----- End forwarded message -----