Our last installment had us shivering on the edges of our seats with this scenario from Eric Norlin:
you walk into a conference room; dial into a con call on the polycomm; the polycomm senses your bluetooth phone and (using a discovery service) looks at your personal attribute known as “music preferences”; thus your current favorite music (by how often you listen to it) is downloaded from your “federated” mp3 player — and the hold music while you wait for your fellow con-callers is *your* favorite music.
sound a bit advanced? actually, you could (technically) do this right now with the Liberty Alliance specifications…
To facilitate discussion, I have scratched out a pictorial representation of the components (to keep incredulous comments at bay, I won't say this is a “diagram”).
The little thing beside stick person is a phone, and interaction (1) uses Bluetooth to determine stick person's identity by retrieving an identifier from the phone.The polycomm then interacts with a discovery service (2) to find out where stick person's “federated mp3″ server is located.Then it pulls down some music (3) conforming to stick person's sense of what's hip and appropriate. Note that the components are functional pieces only. At this point we are making no assumptions about how they are implemented or where they are located.
Now there are a great many ways this polycomm scenario could be realized.I don't want to make judgments about which realization is best.However I am interested in the underlying dynamics at work.To bring some of these out, I'll posit a couple of realizations and discuss some of the implications.I've never discussed this scenario with Eric and don't have a clue what he had in mind – so if I say something that bothers anyone, it's not his fault!
To start drilling, let's look at the role of the polycomm. It senses my phone and uses Bluetooth to discover my identity.
Issue:What and who is able to use Bluetooth to discover my identity, and what does that mean?
To what extent is Bluetooth like RFID?Is the identity discovered through Bluetooth an invariant tracking tag?Can any Bluetooth enabled device discover our identity as we approach it?What are the implications of this?
When you first start asking questions like these, it seems unlikely that the designers wouldn't have figured all this stuff out.And I certainly don't yet know enough about Bluetooth to provide any definitive answers.But the official Bluetooth website didn't really drive up my confidence with this story:
The group of lanky tourists strolling through the Swedish capital's old town never knew what hit them…As they admired handicrafts in a storefront window, one of their cell phones chirped with an anonymous note: “Try the blue sweaters. They keep you warm in the winter.”
The tourist was “bluejacked” — surreptitiously surprised with a text message sent using a short-range wireless technology called Bluetooth.
As more people get Bluetooth-enabled cell phones — both sender and recipient need them for this to work — there is bound to be more mischievous messaging of the unsuspecting.
It's a growing fad, this fun with wireless…
But there's more than bluejacking to consider, as these further quotes from the Bluetooth site tell us:
What is bluebugging?
Bluebugging allows skilled individuals to access the mobile phone commands using Bluetooth wireless technology without notifying or alerting the phone's user. This vulnerability allows the hacker to initiate phone calls, send and read SMS, read and write phonebook contacts, eavesdrop on phone conversations, and connect to the Internet. As with all the attacks, the hacker must be within a 10 meter range of the phone. This is a separate vulnerability from bluesnarfing and does not affect all of the same phones as bluesnarfing.
What is bluesnarfing?
Bluesnarfing allows hackers to gain access to data stored on a Bluetooth enabled phone using Bluetooth wireless technology without alerting the phone's user of the connection made to the device. The information that can be accessed in this manner includes the phonebook and associated images, calendar, and IMEI (International Mobile Equipment Identity). By setting the device in non-discoverable, it becomes significantly more difficult to find and attack the device. Without specialized equipment the hacker must be within a 10 meter range of the device while running a computer with a Linux operating system and the specialized software
NOTE: None of this is intended as a criticism of Bluetooth. I am completely agnostic with respect to competing protocols – if any actually compete. I'm simply using Bluetooth as an example of the work we as an industry must do to get identity right.
So in light of all this, it seems quite possible that Bluetooth protocols might give out an invariant ID to any device which asks for it.And further, it looks like this is not the number one security issue the Bluetooth engineers are working on – at least until bluejacking, bluebugging and bluesnarfing are taken care of.
The point is that – when we get this right - a phone should only give out a user's ID to devices the user wants it given to.
Let's return to our scenario for an example.If the polycomm belongs to my employer, and if I've chosen to recognize my employer's polycomms, then no problem – the phone should reveal my identity to the polycomm.But otherwise, it shouldn't. We can codify this as one of the laws of identity:
The “Owner Decides” Law of identity:
Technical identity systems MUST only reveal information identifying a user with the user's consent.
I will argue later that we who are technical servants of the “general will” need to obey the laws of identity.If we don't, we will create a snarled mess of reinforcing side-effects that will undermine all the systems we put in place. Our ignoring a law of identity is analogous to an engineer who decides not to obey the law of gravity.
Ah, but we're just beginning to get substantive. And I have a big day tomorrow (you know – that day-job thing), so I'm going to call it a night and drill into other aspects of this scenario next time.
Apologies to Macpeople and End of Heightened RSS Alert
No problems in Safari here. But I do note that there isn't a big “I” in Macintosh. The tartan look went out some time back. Now it's just silver and chrome and glowing white, uncapped.
Meanwhile Doc Searls came through with what seems like a complete engineering report – it sounds like he has a control room going with ten or twenty consoles. Maybe that's how he stays on top of everything.
I just viewed the blog in Safari, and it looks fine. Same with Firefox. Both on OS X. On Linux, I just viewed it in Firefox and Konquerer, and it looks fine there, too. I'll assume it looks cool in IE and Firefox on Windows.