As Kim and my ongoing blog discussion seems to have gone off on various tangents (what some might call "rat holes") I thought it best to try to bring things together in a single summary (which I'm sure will probably generate more tangents.
Lets list some of the facts/opinions that have come out in the discussion:
- MAC addresses typically are persistent identifiers that by the definition of the protocols used in wireless APs can't be hidden from snoopers, even if you turn on encryption.
- By themselves, MAC addresses are not all that useful except to communicate with a local network entity (so you need to be nearby on the same local network to use them.
- When you combine MAC addresses with other information (locality, user identity, etc.) you can be creating worrisome data aggregations that when exposed publicly could have a detrimental impact on a user's privacy.
- SSIDs have some of these properties as well, though the protocol clearly gives the user control over whether or not to broadcast (publicize) their SSID. The choice of the SSID value can have a substantial impact on it's use as a privacy invading value -- a generic value such as "home" or "linksys" is much less likely to be a privacy issue than "ConorCahillsHomeAP".
- Google purposely collected SSID and MAC Addresses from APs which were configured in SSID broadcast mode and inadvertently collected some network traffic data from those same APs. Google did not collect information from APs configured to not broadcast SSIDs.
- Google associated the SSID and MAC information with some location information (probably the GPS vehicle location at the time the AP signal was strongest).
- There is no AP protocol defined means to differentiate between open wireless hotspots and closed hotspots which broadcast their SSIDs.
- I have not found out if Google used the encryption status of the APs in its decision about recording the SSID/MAC information for the AP.
Now we get to the point where there are differences of opinion.
- Kim believes that since there's no way for the user to configure whether or not to expose their MAC address and because the association of the MAC address to other information could be privacy invasive, that Google should not have collected that data without express user consent to do so and that in this case Google did not have user consent.
I believe that Google's treatment of the user's decision to broadcast their SSID as an implicit consent for someone to record that SSID and the associated MAC address is a valid and reasonable interpretation. If the user doesn't want their SSID and MAC address collected, they should configure their system to not broadcast their SSID.
Yes, even with the SSID broadcast turned off, some other party can easily determine the APs MAC address and this would clearly have potential negative impacts on the user's privacy, but that's a technical protocol issue not Google's issue since they clearly interpreted SSID silence to be a user's decision to keep their information private and respected that decision.
- In "What harm can come from a MAC address?" Kim seems to argue that because there's some potential way for an entity to abuse a piece of data, that any and all uses of that data should be prohibited. So, because an evil person could capture your mac address of your phone and then drive along the neighborhood to find that mac address and therefore find your home, any use of mac addresses other than their original intent is evil and should be outlawed.
I believe that it's much better to outlaw what would clearly be illegal activity rather than trying to outlaw all possible uses. So, in this particular case, the stalker should be prohibited from using *any* means to track/identify users with the intent of committing a crime (or something like that).
Blindly prohibiting all uses will block useful features. For example, giving my device a means of establishing a location of where it is to obtain some location services without revealing to me the basis for that location is a useful feature that I have made use of on my iPhone and I don't believe that I've violated anyone's privacy in using this type of information to know where I am (to do things such as get a list of movies playing at the nearest theatre via the Fandango application).
- Kim doesn't seem to have responded at all to my criticism of the privacy advocates failing to use this case as a learning experience for users to help them configure their APs in a way that best protects their privacy.
In summary, I do agree that MAC addresses could be abused if associated with an end-user and used for some nefarious purpose. However, I don't believe that Google was doing either of these.
5 comments:
Hi Conor - well, Kim's the Father of Identity (it says on the eema conference agenda, at any rate), not the Father of Privacy. Not yet, at least... ;^)
So, as I have been known to express a view on privacy issues now and then, I did try to tease out what lessons me could draw from this episode, and blog about them here:
http://futureidentity.blogspot.com/2010/05/privacy-and-ssids-in-more-than-140.html
As far as location-based services are concerned, my view is this: if you offer some location-based service, why don't you use your own online presence to help people find you? Why is it better to 'parasite' off the broadcast SSID of someone else, who - let's face it - in all likelihood does not broadcast their SSID for the purpose of making your service easier to locate...
At heart, though, the main lesson is one which you also allude to: effective regulation in this area has to be more sophisticated than current laws, and to cover privacy-invasive outcomes rather than try to specify what third parties may or may not do with every piece of data they may come across.
Regarding:
"In summary, I do agree that MAC addresses could be abused if associated with an end-user and used for some nefarious purpose. However, I don't believe that Google was doing either of these."
I believe that history taught us (Germans) that collecting PII (for whatever good reason) can be horribly abused (by later governments). Don't do it.
Axel,
There's an assumption in your statement that all by itself a MAC address is PII. I disagree. It isn't PII until you associate it with a user or with something a user does. Google was doing neither of these and thus, IMO, the MAC address isn't PII.
Guys - please read this since you will find a link to the report where the company hired by Google to analyse their WiFi collection software telling you that you are completely wrong.
Google WAS capturing the MACs of ALL DEVICES (not just access points) on peoples' home and business networks, whether they broadcast the SSIDs or not, and whether they were encrypted or not. Please look into this - I would think this would cause you to re-evaluate and repost. That would be very helpful because I think, as the matter is better understood, more and more people will need to re-evaluate.
As for the God-father bit, I fear David Goodman was making a comparison with Marlon Brando.
This debate has become abstract in the extreme and lost sight of some of the basic flaws in Kim's approach.
Sweeping up MAC addresses from physical addresses at a point in time isn't worthwhile if the intention to build up a database of indentities connected to devices:
1 Some of the MAC addresses at a location at any point may not belong to the residents at that address (friends, cousins, neighbours)
2 The picture may be different in a week or a month (new routers, new devices, retired devices, devices that have had a drink in the river)
3 Can sweepers distinguish between small flats in a block? ie can they tie down MAC locations to addresses on a 1:1 basis?
4 Kim has already been alerted to IPv6
5 It's happening anyway with Facebook, 4square etc etc. I don't follow Kim so I don't know if he's fulminated against them.
As incitement for governments to kick Google Kim's attempt to keep this debate running makes sense. As a serious contribution to network privacy it doesn't. Everyone has been too polite so far to mention that Kim is an employee of Microsoft, so I'm mentioning it now.
Post a Comment