Rethink things in light of Google's Gstumbler report

A number of technical people have given Google the benefit of the doubt in the Street View Wifi case and as a result published information that Google's new “Gstumbler” report shows is completely incorrect.  It is important that people re-evaluate what they are saying in light of this report. 

I'll pick on Conor's recent posting on our discussion as an example – it contains a number of statements and implies a number of things explicitly contradicted by Google's new report.  Once he reads the report and applies the logic he has put forward, logic will require Conor to change his conclusions.

Conor begins with a bunch of statements that are true:

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

Wishful thinking and completely wrong

 These are followed by a statement that is just plain wishful thinking.  Conor continues:

  • 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's report says Conor is wrong about this, explicitly saying in paragraph 26, “Kismet can also detect the existence of networks with non-broadcast SSIDs, and will capture, parse, and record data from such networks“.   Conor continues:

  • Google associated the SSID and MAC information with some location information (probably the GPS vehicle location at the time the AP signal was strongest).

This is true, but it is important to indicate that this was not limited to access points.  Google's report says that it recorded the association between the MAC address and geographic location of all the active devices on the network.  When it did this, the MAC addresses became, according to Conor's own earlier definition, “worrisome data aggregations”.

  • There is no AP protocol defined means to differentiate between open wireless hotspots and closed hotspots which broadcast their SSIDs. 

This is true, but Google's report indicates this would not have mattered – it collected MACs regardless of whether SSIDs were broadcast.

  • 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.

Google's report indicates it did not.  It only used that status to decide whether or not to record the payload – and only recorded the payload of unencrypted frames…

I like Conor's logic that, “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.”   I urge Conor to read the Gstumbler report.  Once he knows what was actually happening, I hope he'll tell the world about it.

 

The core of the matter at hand

We've explored many of the basic issues of WiFi snooping.  I would now like to go directly to the core of the matter: why do large centralized databases of MAC addresses linked to our street addresses have really serious consequences for peoples’ privacy?  I'd like to approach this through an example:

Consider the case of someone attending a conference at which people are using laptops and phones over a wireless network.  We picture the devices within range of a given attendee in Figure 1:

The green dot represents the WiFi access point through which conference attendees gain access to the Internet.  For now, let's assume this is a permanent WiFi network.  Let's therefore assume its MAC address and location are present within the linking database that also contains our residential MAC to street address mapping.

Now suppose one or more people at the conference have opted into a geo-location service that makes use of the database.  And let's assume that the way this service works is to listen for nearby MAC addresses (all the little circles in the figure) and submit them to the geo-location system for analysis.

The geo-location system will learn that the opted-in user (let's call him Red) is near the given WiFi point, and thus will know Red is at a given location.  If the geo-location system is also capable of searching the web (as one would expect that Google's could), it will also be able to infer that Red is in a given hotel, and that the hotel is hosting a conference C on the date in question. 

If Red stays in the same location for some time, and is surrounded by a number of other people who are in the same location (discernable because their MAC addresses continue to be near by), the smart service will be able to infer that Red is attending conference C being held in the hotel. 

So far, there's nothing wrong with this, since Red has opted in to the geo-location service, and presumably been told that's how it works.

However, note that the geo-location system also learns about the MAC addresses of all the attendees within range who have NOT opted into the system (Green).  And if they remain within range over time, it can also deduce that they too are present at conference C.  Further, it can look up their MAC addresses in the database to discover their street addresses.  This in turn can be used to make many inferences about who the attendees at the conference are, since a lot of information is keyed to their street addresses.  That can itself become further profile information.

Opting out doesn't help

The problem here is this:  The geo-location system is perfectly capable of tracking your location and associating it with your home street address whether you opt in or not.  Home address is a key to many aspects of your identity.  Presto – you have linked many aspects of your identity to your location, and this becomes intellectual property that the geo-location can service sell and benefit from in a myriad of ways.

Is this the way any particular geo-location services would actually work?  I have no idea.  But that's not the point.  The point is that this is the capability one enables by building the giant central database of laptop and phone MAC addresses linked to street addresses.

Commercial interest will naturally tend towards maximal use of these capabilities and the information at hand. 

That is why we need to fully understand the implications of wirelesstapping on a massive scale and figure out if and where we want to draw the line.  How does the collection of MAC addresses using WiFi trucks relate to the regulations involving data collection, proportionality and consent?  Are there limits on the usage of this data? 

One thing for sure.  Breaking the Fourth Law, and turning a unidirectional identifier into a universal identifier is like the story of the Sorcerer's Apprentice.  All the brooms have started dancing.  I wonder if Mickey will get out of this one?

 

More input and points of view

Dave Nikolejsin, CIO of British Columbia and a man who sees identity as the key to efficient government, writes:

“I agree with your comments and focus on the MAC layer data collection going on with Google. One observation I would have re all the “other” similar type activity would be that no others have Google’s resources and thus no others are doing systematic sweep of the western world on such a data gathering mission. As we all know the value of data increases in an N-squared manner and the “N” once Google is done will be a big number.”

Dave goes on to compare wirelesstapping with Facebook's privacy problems and makes what I think is a very insightful comment:

At least (for all its warts) we actually willingly give our info to Facebook!

Heavy duty SOA architect Gunnar Peterson (an expert on Service-Oriented Security) condenses our discussion to date and comes out strongly in favor of the arguments I've been making with regards to the wirelesstapping of MAC addresses: 

Google's Macondo Street View team cannot seem to get the right combination of top kill or cap to fit on its MAC spillage. Your MAC is not like a house number (which everyone knows and are used for many purposes), MAC address is scoped to one use. There's no harm in collecting MACs, the hell you say, there's a number of evil emergent cocktails that can come out of this. Its not so much the MAC itself, its the association of the MAC and the gelocation and time – combining something unique like MAC with geolocation.

This looked like a rogue team (or as Google put it last week a “rogue software engineer“) until this shocking announcement that Google is patenting (emphasis added) – “The invention pertains to location approximation of devices, e.g., wireless access points and client devices in a wireless network.”

It seems pretty obvious that any number of permutations of problems  will result by combining private client data and geolocation. Maybe Google books should scan a copy of J.C. Cannon's book “Privacy: What Developers and IT Professionals Should Know” and Stefan Brands Primer on User Identification.  In both works you see the risks of promiscuously mixing identification cocktails and the unexpected leakages that result. In addition, what does benefit to the user who is being spied upon does all this spying create…?

[More here]

It's true that J.C. and Stefan both do a great job of helping explain the issues at play here, and I advise people who want to understand the issues better to check out their work.

Hal Berenson got back to me after my response to him, saying,

One thing I would suggest is that you write language attempting to ban what you want to ban and let the rest of us poke holes in it  – meaning, show all the legitimate scenarios you would make illegal or accidental criminals you would create… :)

I have total sympathy with this concern of course.  We want the minimum intervention necessary.  But our society has come to realize there are many instances where consumers and citizens need be protected in various ways.  In introducing these protections, lawmakers had to deal with exactly the same difficult concerns about balancing rights.  The good news here:  our legal system seems to handle this just fine.  In fact, that's what it is about.   So I will leave the crafting of the appropriate disincentives to professionals.

Ted Howard, who has broad experience including in the Games industry, commented,

Regarding the issues of Google's collection of MAC addresses and wireless SSIDs:

“If I leave my blinds open so that I can get sun into my home, that means I have no problem with anyone walking past my house pausing to watch me in my home. When I talk with a friend while walking in the park, that means I cannot be bothered by a stranger walking alongside us listening to every word. In both cases, am I “publicly broadcasting” something or is the broadcast just a side effect of my activities? The analogy should be clear.

 

“Do a survey to see how many wireless router owners understand what MAC and SSID are. I suspect that very few (< 5%) people know. If they don't know what these are, then how can anyone claim that these people have been intentionally publicly broadcasting these with an understanding that the broadcast has become publicly-available knowledge? Government regulation exists to, among other reasons, protect the public when the public needs protection and would otherwise be unprotected. This seems to me like a good case for protecting the truly ignorant public.

Journalist Mary Branscombe comments:

For me there are 3 big questions.

  1. How much info did or could someone capture; and by the way Google is in the data capture and data mining/machine learning business and that data *has* been used because if they didn't know it was there they didn't know they had to exclude it.
  2. How personally identifiable or anonymised that information is (i don't think my phone has a bunch of captured MAC addresses and if it does I don't think it has any pii about them but I may be wrong.
  3. How much people care. What is public or private about my SSID or about my MAC address? (I honestly don't know is how much you can find out about me from my MAC address but I'm assuming not much; if I'm wrong that's a data point! I know in 2007 Skyhook told me they were confident they had privacy cracked but they would and they're not the only people and they're the good guys…)

Location services is a *huge* business and people are oversharing location information for trivial rewards (see Foursquare). 8000 apps use Skyhook location data. It's Facebook with co-ordinates. I don't think we can not do this – but I think we can regulate and do it more safely.

In answer to Mary's question two, systems like the Street View Wifi system exist to map peoples’ device MAC addresses to their residential address, as described in the Google patent.  Her point about big business is a BIG POINT.  But to me it just increases the urgency to give people the geo-location capabilities they want without creating a privacy chernoble that will explode down the line.

Jan and Susan Huffman write,

“Standing naked in my front yard is like broadcasting my MAC address.  If I don’t want people to look at me naked in my front yard, I wear clothes. I don’t ask that the law punish those who might take a look through the bushes.

My response:  your MAC address is visible in your wireless packets no matter what you do.  Turning on encryption doesn't help.  So there are no clothes to put on.  The analogy with clothes and bushes therefore just doesn't stand up.  Furthermore, in most neighborhoods, if you spend your time trawling the neighborhood and peeking through bushes you end up with people giving you a pretty hard time…  Maybe that's what's happening here.

 

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.

  

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.

 

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

 

Interview on Identity and the Cloud

I just came across a Channel 9 interview Matt Deacon did with me at the Architect Insight Conference in London a couple of weeks ago.  It followed a presentation I gave on the importance of identity in cloud computing.   Matt keeps my explanation almost… comprehensible – readers may therefore find it of special interest.  Video is here.

 

In addition, here are my presenation slides and video .