In a series of blog articles, Kim Cameron and Ben Adida discuss Google's capturing of open access point information as part of its Street View project.
Kim's assertion that Google was wrong to do so is based upon two primary factors:
- Google intended to capture the SSID and mac address of the access points
- SSIDs and mac addresses are persistent identifiers
And it seems that this has at least gotten Ben re-thinking his assertion that this was all about privacy theater and even him giving Kim a get-out-of-jail-free card.
While I agree that Kim's asserted facts are true, I disagree with his conclusion.
- I don't believe Google did anything wrong in collecting SSIDs and mac addresses (capturing data, perhaps). The SSIDs were configured to *broadcast* (to make something known widely). However, SSIDs and mac addresses are local identifiers more like house numbers. They identify entities within the local wireless network and are generally not re-transmitted beyond that wireless network.
- I don't believe that what they did had an impact on the user's privacy. As I pointed out above, it's like capturing house numbers and associating them with a location. That, in itself, has little to do with the user's privacy unless something else associates the location with the user.
- I hold the wireless AP industry responsible for the fact that many users don't have their APs setup in SSID stealth and data encrypted mode. The AP industry should have designed things so that they were encrypted by default with hidden SSIDs and required the user to do something to create an open network if they wanted to.
- The user has to assume some responsibility here, though I really don't expect my mother to know how to configure encryption on an AP (nor do I expect her to know enough to know it's necessary). So I'm back to the AP industry.
- And, perhaps most of all, I fault the various privacy pundits and all the news outlets who did not take this as an opportunity to teach the users and the industry about how to protect their data. Not one report that I read/saw went into any detail on how the user could protect themselves (which, if they still broadcast their SSIDs and leave their network unencrypted they are open to much worse attacks than Google capturing their SID & mac address).
Perhaps my view is contrarian for one who is somewhat active on the privacy side. However, I think it is a much more pragmatic view that will ultimately bring value to the user far beyond giving Google a hard time for capturing SSIDs and mac addresses which have little privacy value (in my opinion).
Tags : identity / privacy / google / SSID / privacy / privacy
6 comments:
Wait, what? I agree that enabling encryption on your WiFi network is a good thing, and from what I've observed in most neighbourhoods I've looked in lately, everyone *is* doing this already.
But what difference does it make if I broadcast my SSID or not? If the traffic is already going over the air, then the SSID is capturable from all WiFi client devices, no? So I call "security by obscurity" in hiding SSIDs - it might keep out the least dangerous folks, but I doubt their attacks are the ones to which you allude when you say "they are open to much worse attacks than Google capturing their SID & mac address)".
I personally always leave my SSID in broadcast mode - I judge the convenience to myself and my friends & family to be far more valuable than the false sense of security I'd get from 'hiding' it (when it's not even all that well hidden, since it'd be part of my wireless communications). And further, even once an attacker were to know the SSID, they still have to get past my password. And if they really want to do that, they'll do it no question - at which point the security layers protecting each of my computing devices from unsolicited inbound attempts will still be there. (Which they always should be in place, since 4 of the 5 devices in my home that are on that wifi network are mobile, and are regularly exposed to direct Internet connections in their weekly travels.)
I tend to equate broadcasting a SSID as an invitation for others to connect to you. That may be fine for you because one can't get far with just an SSID on your system -- they need the encryption password as well (and I use the same setup).
That said, if you do broadcast the SSID, you should not have expectations that the SSID is not visible/known to others outside your home. Which seems to be part of the argument being made by some of the privacy folks.
Imaging that Google or some other entity would mount cameras with number plat and face recognition on every street corner.
Now you would argue that Google is only aggregating and publishing data that is public anyway.
That the data is available does not mean that you may use it.
Alex, that is a quite different situation than what is currently being discussed. First you have permanently mounted cameras everywhere. Then you add facial recognition and license plate recognition to the picture -- two "identifiers" that are clearly associated with the user and which last for long periods of time and which, when tied to the location of the camera, reveal substantial information about the user.
So yeah, I would say your example would be a bad thing. However, that isn't what is being discussed at this point in time.
Coner, any usage of PII outside its intended context and without user consent is a bad thing. SSID and MAC addresses are PII
I don't agree with the assertion that an SSID and mac address automatically are PII by themselves.
For example, hundreds of thousands (if not millions) of APs have the SSID "linksys". I can't see anyone reasonably arguing that such a SSID is PII. In addition, one can reasonably make the argument that a user choosing to broadcast their SSID by definition provides consent for others to know that SSID.
As far as mac address, they are predictable identifiers -- once I know one mac address (even for my own system) I can predict many, many others. So just having a mac address is not PII (IMO). Associating that address with other user information (web traffic, logins, etc.) can cause the set of data to become PII, but I don't believe that a mac address by itself, especially one that is not typically exposed outside of the internal network (e.g. the mac address on the AP is not typically the same as the mac address on the Ethernet connection to the ISP, so you only get to see this mac address if you are able to see the wireless AP network itself in which case the AP provides the mac address again anyway).
Post a Comment