devices, payload data, and why Kim is (in part) right.

A few days ago, I wrote about privacy advocacy theater and lamented how some folks, including EPIC and Kim Cameron, are attacking Google in a needlessly harsh way for what was an accidental collection of data. Kim Cameron responded, and he is right to point out that my argument, in the Google case, missed an important issue.

Kim points out that two issues got confused in the flurry of press activity: the accidental collection of payload data, i.e. the URLs and web content you browsed on unsecured wifi at the moment the Google Street View car was driving by, and the intentional collection of device identifiers, i.e. the network hardware identifiers and network names of public wifi access points. Kim thinks the network identifiers are inherently more problematic than the payload, because they last for quite a bit of time, while payload data, collected for a few randomly chosen milliseconds, are quite ephemeral and unlikely to be problematic.

Kim’s right on both points. Discussion of device identifiers, which I missed in my first post, is necessary, because the data collection, in this case, was intentional, and apparently was not disclosed, as documented in EPIC’s letter to the FCC. If Google is collecting public wifi data, they should at least disclose it. In their blog post on this topic, Google does not clarify that issue.

So, Google, please tell us how long you’ve been collecting network identifiers, and how long you failed to disclose it. It may have been an oversight, but, given how much other data you’re collecting, it would really improve the public’s trust in you to be very precise here.

Now, two points:

  1. taking a second look at EPIC’s letter and Kim’s original post, it still seems to me that there’s some confusion of the device identifier and payload data issues: the uproar materialized after Google revealed they had mistakenly collected payload data, and EPIC’s letter and Kim’s original post seem to weave back and forth between both issues, never really mentioning intent. Is this because the payload data story is juicier in headlines, and so bundling the two issues helps make the more important point? Maybe, but still, I think we should be more precise and careful when we attack on privacy grounds.
  2. I agree that device privacy can be a big deal, especially when many people are walking around with RFIDs in their passports, pants, and with bluetooth headsets. But, in this particular case, is it a problem? If Google really only did collect the SSIDs of open, public networks that effectively invite anyone to connect to them and thus discover network name and device identifier, is that a violation of privacy, or of the Laws of Identity? I’m having trouble seeing the harm or the questionable act. Once again, these are public/open wifi networks. For the most part, these are static access points. Given Google’s stated interests in providing geolocation services, it would be detrimental to them if they catalogued roving access points. So, what’s the worst-case scenario here? Is it that, when I move to a new apartment, Google will know?

None of this excuses Google’s lack of disclosure. This was intentional data collection, it should be disclosed, period.

And it’s worth asking the questions that Kim asks, raising awareness of device privacy. I’m not sure I’m as worried as Kim is on this particular issue, but the questions are certainly legitimate.

So, in the end, the privacy advocacy theater is coming first and foremost from the EU privacy folks, who did get enraged about payload data more than anything else. There’s still some coming from EPIC and, to remain blunt, a little bit from Kim’s first post. But his second post brings up very legitimate questions, and Google should take some additional action here, at least to let us know what they were collecting, when, and whether they properly disclosed it.

5 thoughts on “devices, payload data, and why Kim is (in part) right.

  1. For location purposes (Google’s stated goal), ESSID/mac addresses of private networks are just as effective as those of public networks, so I imagine they were gathering those- no reason to think otherwise, is there?

  2. For location purposes (Google’s stated goal), ESSID/mac addresses of private networks are just as effective as those of public networks, so I imagine they were gathering those- no reason to think otherwise, is there?

  3. I believe the law distinguishes between the tracking of traffic information (who you called, e-mailed, etc) on the one hand and the monitoring of your actual conversations on the other. E.g. the EU has a law that requires ISPs to record traffic information and bans them from monitoring content. This suggests that society currently does distinguish between identify information and content.
    Kim’s assertion that that because both types of information are sent in the same network packet, both should be covered by the same privacy policy, seems to be the technology cart driving the policy horse.
    This is not to say that the collection of SSIDs & MACs should necessarily be acceptable. But policy certainly COULD be chosen to accept the collection of this information while banning the collection of content.

  4. I believe the law distinguishes between the tracking of traffic information (who you called, e-mailed, etc) on the one hand and the monitoring of your actual conversations on the other. E.g. the EU has a law that requires ISPs to record traffic information and bans them from monitoring content. This suggests that society currently does distinguish between identify information and content.
    Kim’s assertion that that because both types of information are sent in the same network packet, both should be covered by the same privacy policy, seems to be the technology cart driving the policy horse.
    This is not to say that the collection of SSIDs & MACs should necessarily be acceptable. But policy certainly COULD be chosen to accept the collection of this information while banning the collection of content.

  5. Pingback: Benjamin Fleischer » Blog Archive » Privacy Theatre, Google, and Users of this website accept it’s TOS

Comments are closed.