There is a fundamental problem here

Joe Mansfield at Peccavi has done a very cogent post where, though he agrees with my concerns, he criticizes me for picking almost exclusively on Google when there are lots of others who have been doing the same thing.  He's right – I have been too narrowly focused. 

Let me be clear:  I have great respect for Google and many of its accomplishments.   I have a disagreement with a particular Google team.

I find the Google Street View team's abuse of identifiers especially worrisome because they have not only been collecting info about WiFi access points, but the MAC addresses of peoples’ personal devices (laptops and phones).  

This bothers me because I see it as dangerous.  It's like going over to visit a neighbor and finding out he's been building a nuclear reactor in his basement. 

 I'm not an expert on the geolocation industry and I have no knowledge of whether this kind of end-user-device-snooping is commonplace.  If it is, then let me know.  Everything I have said about Google applies equally to any similar practitioners. 

But let's get to Peccavi which makes the point better than I do:

I’ve been following Kim Cameron’s increasingly critical analysis of Google’s StreetView WiFi mapping data privacy debacle with some interest of late.

Some background might be in order for those interested in reading where he’s been coming from – start here and work forward. He’s been quite vocal and directed in his criticism and I have been surprised that his focus has been almost entirely on Google rather than on the underlying technical root cause. My initial view on the issue was that it was a stupid over-reaction to something that everyone has been doing for years, and that at least Google were being open about having logged too much data. I’m still of the opinion that the targeting of Google specifically is off base here, although I think Kim is right that there is a fundamental problem here.

Kim is probably the pre-eminent proponent and defender of strong authentication and privacy on the net at the moment. His Laws of Identity should be mandatory reading for anyone working with user data in any sort of context but especially for anyone working with online systems. He’s a hugely influential thought leader for doing the right thing and as a key technical leader within Microsoft he’s doing more than almost anyone else to lay the groundwork for a move away from our current reliance on insecure, privacy leaking methods of authentication. Let’s just say that I’m a fan.

For obvious reasons he has spotted the huge privacy problems associated with the practice of gathering WiFi SSID and MAC addresses and using them to create large scale geo-location databases. There are serious privacy issues here and despite my initial cynicism about this perhaps it’s a good thing that there has been a huge furore over what Google were doing.

Note that there were two issues in play here – the intentional data (the SSID’s, MAC addresses and geo-location info) and the unintentional data (actual user payloads). I’m only going to talk about the intentionally harvested data right now because that is the much trickier problem – few people would argue that having Google (or anyone) logging actual WiFi traffic from their homes is OK.

The problem that I see with Kim’s general position on this and the focus on Google’s activities alone is that he’s not seeing the wood for the trees. The problem of companies or individuals harvesting this data is minor compared to the problem that enables it. The technical standards that we all use to connect wirelessly with the endless array of devices that we all now have in our homes, use at work and carry on our person every day are promiscuous communicators of identifiers that can be easily and extensively misused. Even if Google are prevented by law from doing it, if the standards aren’t changed then someone else will…

I agree with almost every point made except, “The problem of companies or individuals harvesting this data is minor compared to the problem that enables it.”  I would put it differently.  I would say, “There are two problems.  Both are bad.”

We're technologists so we immediately look to technology to prevent abuse.  This is the right instinct for us to have.  But societly can use disincentives too.  I've come to believe that technology must belong to society as a whole.  And we need a combination of  technical solutions and those society can impose.

I actually think I see at least some of the woods as well as the trees.  That is what the Fourth Law is all about.  Of course I want to change the underlying technology as fast as we can. 

But I don't think that will happen unless there is a MUCH greater understanding of the issues, and I've been trying with this set of posts to get them onto the table.    

[More Peccavi here.]

 

MAC addresses will be used to reveal where you live

Conor has responded to my comments on why house numbers don't make a good metaphor for MAC addresses.

He writes that when I characterized house number as a “universal identifier”,

[Kim's argument] “confuses house address with house number. A house number is not able to be used as a universal identifier (I presume that there are many houses out there with the number 15, even in the same town, many times even on the same street in the same zip code (where the only difference is the N.W. and S.E. on the end of the street name).

“Like SSIDs and MAC addresses, the house number is only usable as an identifier once you get to the neighborhood and very often only once you get to the street.”

I like Conor's distinction between house number and house address.  It's true there are many houses with the number 15, thus the house number is a local identiier, and only becomes universal when combined with the street name, the city, and so on.  I hadn't understood that this is what he was trying to say.

Then Conor continues:

“I will admit that there are some differences with the MAC address because of how basic Ethernet networking was designed. The MAC address is designed to be unique (though, those in networking know that this isn't always the case and in fact most devices let you override the mac address anytime you want). So this could be claimed to be some form of a universal identifier. However, it's not at all usable outside of the local neighborhood. There is no way for me to talk to a particular MAC address unless I am locally on the same network with that device.”

Conor is completely right here.  In networking as we have known it, the MAC address is not usable outside the “local network neighborhood”.  But that is exactly what this WiFi snooping is about to change.  In fact this is very much the core of what I'm talking about.

MAC addresses will be used to reveal where you live

Once you have snooped peoples’ MAC addresses, and put them into a database linking them to “where they live” (literally),  you have dramatically changed the way network identifiers work.

In this new world, armed with such a database, if you see a MAC address somewhere – anywhere – you can look it up in your database – precisely because it is unique – and see where “it lives”.   When I say, “where it lives”, I don't mean what network it belongs to.  I mean where it is normally located in physical space – as a street address.  

Is there some way to opt out of this?  No – other than turning everything off.  Unfortunately, given the way networks are designed, we have no choice but to reveal our MAC address when we use our Wireless.  So  anyone who is physically near us and has access to a linking database has access to where we live. I'll explore the implications of this going forward.

Conor concludes,

“I do believe that a more privacy enabled design of networking would have allowed for scenarios where MAC addresses were more dynamic and thus reducing the universal-ness and persistence of the MAC address itself…”

We both agree on this.  And IPV6 has plenty of options that could make this possible.  However, the current infrastructure is the one we live in, and one which is sorely in need of protections, mores and regulations.  The fact that current technology allows the creation of Dr. No technology like that which Google StreetView WiFi has laid on the world doesn't mean that society should or will.

 

 

Are SSIDs and MAC addresses like house numbers?

Architect Conor Cahill writes:

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…

Let's think about this.  Are SSIDs and MAC addresses like house numbers?

Your house number is used – by anyone in the world who wants to find it – to get to your house.  Your house was given a number for that purpose.  The people who live in the houses like this.  They actually run out and buy little house number things, and nail them up on the side of their houses, to advertise clearly what number they are.

So let's see:

  1. Are SSIDS and MAC addresses used by anyone in the world to get through to your network?  No.  A DNS name would be used for that.  In residential neighborhoods, you employ a SSID for only one reason – to make it easier to get wireless working for members of your family and their visitors.  Your intent is for the wireless access point's MAC address to be used only by your family's devices, and the MACs of their devices only by the other devices in the house.
  2. Were SSIDS and MAC addressed invented to allow anyone in the world to find the devices in your house?   No, nothing like that.  The MAC is used only within the confines of the local network segment.
  3. Do people consciously try to advertise their SSIDs and MAC addresses to the world by running to the store, buying them, and nailing them to their metaphorical porches?  Nope again.  Zero analogy.

So what is similar?  Nothing. 

That's because house addresses are what, in Law Four of the Laws of Identity, were called “universal identifiers”, while SSIDs and MAC addresses are what were called “unidirectional identifiers” – meaning that they were intended to be constrained to use in a single context. 

Keeping “unidirectional identifiers” private to their context is essential for privacy.  And let me be clear: I'm not refering only to the privacy of individuals, but also that of enterprises, governments and organizations.  Protecting unidirectional identifiers is essential for building a secure and trustworthy Internet.

 

Ben Adida releases me from the theatre

When I published Misuse of network identifiers was done on purposeBen Adida  twittered that “Kim Cameron answers my latest post with some good points I need to think about…”.  And he came through on that promise, even offering me a “Get out of theatre free” card:

“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.  [Just for the record, I didn't actually say “unlikely to be problematic” – Kim]

“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.”

Ben also says my initial post seems “to weave back and forth between both issues”.  In fact I see payload and header being two parts of the same WiFi packet.  Google “accidently” collected one part of the packet but collected the other part on purpose.  I think it is really bizarre that a lot of technical people consider one part of the packet (emails and instant messages) to be private, and then for some irrational reason assume the other part of the same packet (the MAC address) is public.  This makes no sense and as an architect it drives me nuts.  Stealing one part of the WiFi packet is as bad as stealing another.

Ben also says,

“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.”

Let me be clear:  If Google or any other operator only collected the SSIDs of “open, public networks that invite anyone to connect to them” there would be zero problem from the point of view of the Laws of Identity.  They would, in the terminology of Law Four, be collecting “universal identifiers”. 

But when you drive down a street, the vast majority of networks you encounter are NOT public, and are NOT inviting just anyone to connect to them.  The routers emit packets so the designated users of the network can connect to them, not so others can connect to them, hack them, map them or use them for commercial purposes.  If one is to talk about intent, the intent is for private, unidirectional identifiers to be used within a constrained scope.

In other words, as much as I wish I didn't have to do so, I must strongly dispute Ben's assertion that “Once again, these are public/open WiFi networks” and insist that private identifiers are being misappropriated.

In matters of eavesdropping I subscribe to EPIC's argument that proving harm is not essential – it is the eavesdropping itself which is problematic.  However, in my next post I'll talk about harm, and the problems of a vast world-wide system capable of inference based on use of device identifiers.

  

“I just did it because Skyhook did it”

I received a helpful and informed comment by Michael Hanson at Mozilla Labs on the Street View MAC Address issue:

I just wanted to chip in and say that the practice of wardriving to create a SSID/MAC geolocation database is hardly unique to Google.

The practice was invented by Skyhook Wireless], formerly Quarterscope. The iPhone, pre-GPS, integrated the technology to power the Maps application. There was some discussion of how this technology would work back in 2008, but it didn't really break out beyond the community of tech developers. I'm not sure what the connection between Google and Skyhook is today, but I do know that Android can use the Skyhook database.

Your employer recently signed a deal with Navizon, a company that employs crowdsourcing to construct a database of WiFi endpoints.

Anyway – I don't mean to necessarily weigh in on the question of the legality or ethics of this approach, as I'm not quite sure how I feel about it yet myself. The alternative to a decentralized anonymous geolocation system is one based on a) GPS, which requires the generosity of a space-going sovereign to maintain the satellites and has trouble in dense urban areas, or b) the cell towers, which are inefficient and are used to collect our phones’ locations. There's a recent paper by Constandache (et al) at Duke that addresses the question of whether it can be done with just inertial reckoning… but it's a tricky problem.

Thanks for the post.

The scale of the “wardriving” [can you beieve the name?] boggles my mind, and the fact that this has gone on for so long without attracting public attention is a little incredible.  But in spite of the scale, I don't think the argument  that it's OK to do something because other people have already done it will hold much water with regulators or the thinking public  In fact  it all sounds a bit like a teenager trying to avoid his detention because he was “just doing what Johnny did.”

As Michael say, one can argue that there are benefits to drive-by device identity theft.  In fact, one can argue that there would be benefits to appropriating and reselling all kinds of private information and property.  But in most cases we hold ourselves back, and find other, socially acceptable ways of achieving the same benefits.  We should do the same here.

Are these databases decentralized and anonymous?

As hard as I try, I don't see how one can say the databases are decentralized and anonymous.  For starters, they are highly centralized, allowing monetized lookup of any MAC address in the world.  Secondly, they are not anonymous – the databases contain the identity information of our personal devices as well as their exact locations in molecular space.   It is strange to me that personal information can just be “declared to be public” by those who will benefit from that in their businesses.

Do these databases protect our privacy in some way? 

No – they erode it more than before.  Why?

Location information has long been available to our telephone operators, since they use cell-tower triangulation.  This conforms to the Law of Justifiable Parties – they need to know where we are (though not to remember it) to provide us with our phone service. 

But now yet another party has insinuated itself into the mobile location equation: the MAC database operator – be it Google, Skyhook or Navizon. 

If you carry a cell phone that uses one of these databases – and maybe you already do – your phone queries the database for the locations of MAC addresses it detects.  This means means that in additon to your phone company, a database company is constantly being informed about your exact location.   From what Michael says it seems the cell phone vendor might additionally get in the middle of this location reporting – all parties who have no business being part of the location transaction unless you specifically opt to include them.

Exactly what MAC addresses does your phone collect and submit to the database for location analysis?  Clearly, it might be all the MAC addresses detected in its vicinity, including those of other phones and devices…  You would then be revealing not only your own location information, but that of your friends, colleagues, and even of complete strangers who happen to be passing by – even if they have their location features turned off

Having broken into our home device-space to take our network identifiers without our consent, these database operators are thus able to turn themselves into intelligence services that know not only the locations of people who have opted into their system, but of people who have opted out.  I predict that this situation will not be allowed to stand.

Are there any controls on this, on what WiFi sniffing outfits can do with their information, and on how they relate it to other information collected on us, on who they sell it to?

I don't know anything about Navizon or the way it uses crowdsourcing, but I am no happier with the idea that crowds are – probably without their knowledge – eavesdropping on my network to the benefit of some technology outfit.  Do people know how they are being used to scavenge private network identifiers – and potentially even the device identifiers of their friends and colleagues?

Sadly, it seems we might now have a competitive environment in which all the cell phone makers will want to employ these databases.  The question for me is one of whether, as these issues come to the attention of the general public and its representatives, a technology breaking two Laws of Identity will actually survive without major reworking.  My prediction is that it will not. 

Reaping private identifiers is a mistake that, uncorrected,  will haunt us as we move into the age of the smart home and the smart grid.  Sooner or later society will nix it as acceptable behavior.  Technologists will save a lot of trouble if we make our mobile location systems conform with reasonable expectations of privacy and security starting now.

 

Clarke: Appropriating home network identifiers is the real issue

Here is some background on the Google Street View WiFi issue by Roger Clarke, a well known Australian privacy expert.  Roger points out that Peter Schaar, Germany's Federal Commissioner for Freedom of Information, was concerned about misuse of network identifiers from the very beginning. 

I agree that the identifiers of users’ devices is the real issue.

And your invocation of “It reminds me of an old skit by “Beyond the Fringe” where a police inspector points out that “Once you have identified the criminal's face, the criminal's body is likely to be close by” does hit the spot very nicely!

You ask why the payload is getting all the attention.  After all, it was the device-addresses that Peter Schaar first drew attention to.  As I wrote here,

The third mistake came to light on 22 April 2010, when The Register reported that “[Google's] Street View service is under fire [from the German Data Protection Commissioner, Peter Schaar] for scanning private WLAN networks, and recording users’ unique [device] addresses, as the car trundles along”.

As soon as Peter Fleischer [Google's European privacy advisor – Kim]  published his document of 27 April, I wrote to Schaar, saying:

“Fleischer's document doesn't say anything about whether the surveillance apparatus in the vehicle detects other messages from the router, and messages from other devices…

“In relation to messages other than beacons, on the surface of it, Fleischer might seem to be making an unequivocal statement that Google does *not* collect and store MAC addresses.

“But:

  1. If Google's surveillance apparatus is in a Wifi zone, how does it avoid ‘collecting’ the data?  [Other statements make clear that it does in fact collect that data]
  2. [In the statement “Google does not collect or store payload data”,] the term ‘payload data’ would most sensibly be interpreted as meaning the content, but not including the headers.
  3. The MAC-addresses are in the headers.
  4. So Fleischer's statement is open to the interpretation that header data of messages other than beacons *is* collected, and *is* stored.

“Google has failed to make the statement that connected-device MAC-addresses are *not* collected and stored.

“Because Google has had ample opportunity to make such a statement, and has avoided doing so, I therefore make the conservative assumption that Google *does* collect and store MAC addresses of any devices on networks, not just of routers.”

The document sent to the Commissioners added fuel to the fire, by saying “The equipment is able to receive data from all broadcast frames [i.e. not only beacons are intercepted; any traffic may be intercepted.] This includes, from the header data, SSID and MAC addresses [i.e. consistent with the analysis above, the MAC-addresses of all devices are available to Google's surveillance apparatus.] However, all data payload from data frames are discarded, so Google never collects the content of any communications.

Subsequently, on 14 May, investigations by Hamburg Commissioner Caspar led to the unavoidable conclusion that Fleischer's post on April 27 had been incorrect in a key respect. As Eustace put it, “It's now clear that we have been mistakenly collecting samples of payload data [i.e. message content] from open (i.e. non-password-protected) WiFi networks”.

So I think there are a couple of reasons why the payload aspect is getting most of the press:

  1. The significance of identifiers isn't readily apparent to most people, whereas ‘payload’, like people's Internet Banking passwords, is easier to visualise. (Leave aside that only highly insecure services send authenticators unencrypted. Low-tech reporters have to (over-) simplify stories to communicate to low-tech readers
  2. A corporation appeared to have been caught telling fibs, constructively misleading the public and the media, and regulators
  3. That's what catapulted it into the news, and reporters feed off one another's work, so it's the payload they all focus on
  4. A final factor is that breaches of telecommunications laws may be easier to prove in the case of content than of device-identifiers.

The Australian Privacy Foundation (APF) stepped up the pressure in Australia late this week.

Firstly, we directly requested Google not to delete the data, and gave them notice that we were considering using a little-known part of the TIAA to launch an action.  That was promptly followed by the NYT's report of the Oz Privacy Commissioner saying that the Australian data is in the USA.  (The first useful utterance she's made on the topic – a month after this story broke, there's no mention of the matter on her web-site).

Secondly, we wrote to the relevant regulators, and requested them to contact Google to ensure that the data is not deleted, and to investigate whether Google's actions breached Australian laws.

 

Don't take identities from our homes without our consent

Joerg Resch of Kuppinger Cole in Germany wrote recently about the importance of identity management to the Smart Grid – by which he means the emerging energy infrastructure based on intelligent, distributed renewable resources:

In 10-12 years from now, the whole utilities and energy market will look dramatically different. Decentralization of energy production with consumers converting to prosumers pumping solar energy into the grid and offering  their electric car batteries as storage facilities, spot markets for the masses offering electricity on demand with a fully transparent price setting (energy in a defined region at a defined time can be cheaper, if the sun is shining or the wind is blowing strong), and smart meters in each home being able to automatically contract such energy from spot markets and then tell the washing machine to start working as soon as electricity price falls under a defined line. And – if we think a bit further and apply Google-like business models to the energy market, we can get an idea of the incredible size this market will develop into.

These are just a few examples, which might give you an idea on how the “post fossile energy market” will work. The drivers leading the way into this new age are clear: energy production from oil and gas will become more and more expensive, because pollution is not for free and the resources will not last forever. And the transparency gain from making the grid smarter will make electricity cheaper than it is now.

The drivers are getting stronger every day. Therefore, we will soon see many large scale smart grid initiatives, and we will see questions rising such as who has control over the information collected by the smart meter in my home. Is it my energy provider? How would Kim Cameron´s 7 laws of Identity work in a smart grid? What would a “grid perimeter” look like which keeps information on the usage of whatever electric devices within my 4 walls? By now, we all know what cybercrimes are and how they can affect each of us. But what are the risks of “smart grid hacking”? How might we be affected by “grid crimes”?

In fact at Blackhat 2009, security consultant Mike Davis demonstrated successful hacker attacks on commercially available smart meters.  He told the conference,

“Many of the security vulnerabilities we found are pretty frightening and most smart meters don't even use encryption or ask for authentication before carrying out sensitive functions like running software updates and severing customers from the power grid.”

Privacy commission Ann Cavoukian of Ontario has insisted that industry turn its attention to the security and privacy of these devices:

“The best response is to ensure that privacy is proactively embedded into the design of the Smart Grid, from end to end. The Smart Grid is presently in its infancy worldwide – I’m confident that many jurisdictions will look to our work being done in Ontario as the privacy standard to be met. We are creating the necessary framework with which to address this issue.”

Until recently, no one has talked about drive-by mapping of our home devices.  But from now on we will.  When we think about home devices, we need to reach into the future and come to terms with the huge stakes that are up for grabs here.  

The smart home and the smart grid alert us to just how important the identity and privacy of our devices really is.  We can use technical mechanisms like encryption to protect some information from eavesdroppers.   But not the patterns of our communication or the identities of our devices…  To do that we need a regulatory framework that ensures commercial interests don't enter our “device space” without our consent.

Google's recent Street View WiFi boondoggle is a watershed event in drawing our attention to these matters.

Misuse of network identifiers was done on purpose

Ben Adida has a list of achievements as long as my arm – many of which are related to privacy and security.  His latest post concerns what he calls, “privacy advocacy theater… a problem that my friends and colleagues are guilty of, and I’m sure I’m guilty of it at times, too.  Privacy Advocacy Theater is the act of extreme criticism for an accidental data breach rather than a systemic privacy design flaw. Example: if you’re up in arms over the Google Street View privacy “fiasco” of the last few days, you’re guilty of Privacy Advocacy Theater.”

Ben then proceeds take me to task for this piece:

I also have to be harsh with people I respect deeply, like Kim Cameron who says that Google broke two of his very nicely crafted Laws of Identity. Come on, Kim, this was accidental data collection by code that the Google Street View folks didn’t even realize was running. (I’m giving them the benefit of the doubt. If they are lying, that’s a different problem, but no one’s claiming they’re lying, as far as I know.) The Laws of Identity apply predominantly to the systems that individuals choose to use to manage their data. If anyone is breaking the Laws of Identity, it’s the WiFi access points that don’t actively nudge users towards encrypting their WiFi network.

But let's hold on a minute.  My argument wasn't about the payload data that was collected accidently.  It was about the device identification data that was collected on purpose.  As Google's Alan Eustace put it: 

We said that while Google did collect publicly broadcast SSID information (the WiFi network name) and MAC addresses (the unique number given to a device like a WiFi router) using Street View cars, we did not collect payload data (information sent over the network). But it’s now clear that we have been mistakenly collecting samples of payload data…

Device identifiers were collected on purpose

SSID and MAC addresses are the identifiers of your devices.  They are transmitted as part of the WiFi traffic just like the payload data is.  And they are not “publically broadcast” any more than the payload data is. 

Yet Google consciously decided to abscond with, tabulate and monetize the identities of our personal, business and home devices.  The identifiers are persistent and last for the lifetime of the devices.  Their collection, cataloging and use is, in my view, more dangerous than the payload data that was collected. Why? The payload data, though deeply personal, is transient and represents a single instant.  The identifiers are persistent, and the Street View WiFi plan was to use them for years.  

Let's be clear:  Identity has as much to do with devices, software, services and organizations as with individuals.  And equally important, identity is about the relationships between these things.  In fact identity can only be adequately expressed through the relationships (some call it context).

When Google says, “MAC addresses are a simple hardware ID assigned by the manufacturer” and “We cannot identify an individual” using those “simple hardware IDs”,  it sounds like the devices found in your home and briefcase and pocket have nothing to do with you as a flesh and blood person.  Give me a break!  It reminds me of an old skit by “Beyond the Fringe” where a police inspector points out that “Once you have identified the criminal's face, the criminal's body is likely to be close by…”  Our identities and the identities of our devices are related, and understanding this relationship is essential to getting identity and privacy right.

One great thing about blogging is you find out when you haven't been clear enough.  I hope I'm making progress in expressing the real issues here:  the collection of device identifiers was purposeful, and this represents precisely the kind of “systemic privacy design flaw” to which Ben refers.  

It bothers me that this disturbing systemic privacy design flaw – for which there has been no apology – is being obscured through the widely publicized apology for a completely separate and apparently accidental sin.  

In contemporary networks, the hardware ID of the device is NOT intended to be a “universal identifier”.  It is intended to be a “unidirectional identifier” (see The Fourth Law) employed purely to map between a physical machine and a transient, local logical address.  Many people who read this blog understand why networking works this way.  In Street View WiFi, Google was consciously misusing this unidirectional identifier as a universal identifier, and misappropriating it by insinuating itself, as eavesdropper, into our network conversations.

Ben says, “The Laws of Identity apply predominantly to the systems that individuals choose to use to manage their data.”  But I hope he rethinks this in the context of what identity really is, its use in devices and systems, and the fact that human, device and service identities are tied together in what one day should be a trustworthy system.  I also hope to see Google apologize for its misuse of our device identities, and assure us they will not be used in any of their systems.

Finally, despite Ben's need to rethink this matter,  I do love his blog, and strongly agree with his comments on  Opera Mini, discussed in the same piece.

 

EPIC on Google WiFi eavesdropping

Readers have drawn our attention to a recent letter from EPIC's Marc Rotenberg to  FCC Chairman, Julius Genachowski.

In the detailed letter, Marc Rotenberg specifically calls attention to the mapping of private device identifiers, saying, “We understand that Google also downloaded and recorded a unique device ID, the MAC address, for wireless access devices as well as the SSID assigned by users.”

He argues:

The capture of Wi-Fi data in this manner by Google Street View could easily constitute a violation of Title III of the Omnibus Crime Control and Safe Streets Act of 1968, also known as the Wiretap Act, as amended by the Electronic Communications Privacy Act (ECPA) of 1986 to include electronic communications. Courts most oten define “interception” under ECPA as “acquisitions contemporaneous with transmission.” The Wiretap Act provides for civil liability and criminal penalties against any person who “intentionally intercepts, endeavors to intercept, or procures any other person to intercept or endeavor to intercept any… electronic communication [except as provided in the statute].”

The Wiretap Act imposes identical liability on any person who “intentionally discloses … to any other person the contents of any… electronic communication, knowing or having reason to know that the information was obtained through the interception of a[n] … electronic communication in violation of
this subsection,” or “intentionally uses … the contents of any… electronic communication, knowing or having reason to know that the information was obtained through the interception of a[n]… electronic communication in violation of this subsection.”

Full text (including many footnotes elided in the quote above) is available in pdf and Word format.  See also The Hill's technology blog.

Issuing Information Cards with ADFS 2.0

When  Microsoft released Active Directory Federation Services V2 recently, we indicated we were holding off on shipping CardSpace 2.0 while figuring out how to best integrate Minimal Disclosure Technology (U-Prove) and create maximum synergy with the OpenID and OAuth initiatives.  Some feared the change in plan meant Microsoft was backing away from the idea of Information Cards and a visual identity selector.  Nothing could be further from the truth – the growth in adoption of federation and the shift toward cloud computing both make Information Card technology more important than ever.

This new announcement from Technet identity blog will therefore come as good news:

Today, Microsoft is announcing the availability of the Information Card Issuance Community Technology Preview (CTP) to enable the following scenarios with Active Directory Federation Services 2.0 RTM:

  • Administrators can install an Information Card Issuance component on AD FS 2.0 RTM servers and configure Information Card Issuance policy and parameters.
  • End users with IMI 1.0- or IMI 1.1 (DRAFT)-compliant identity selectors can obtain Information Cards backed by username/password, X.509 digital certificate, or Kerberos.
  • Continued support for Windows CardSpace 1.0 in Windows 7, Windows Vista and Windows XP SP 3 running .NET 3.5 SP1.

We have also added two new mechanisms for interaction and feedback on this topic, an Information Card Issuance Forum and a monitored e-mail alias ici-ctp@microsoft.com