ALL ART BURNS

[More thinking out loud about what I could do with an SRM. I haven’t started Everyware yet and might edit this after I’m finished. –jet]

So what happens if I drag around a slightly tweaked spime retrofit module and intentionally pre-load it with data and a set of data redistribution rules? As it collects and redistributes data about me over time based on rules I create, how does my life change for the better or for the worse?

More generally, “What happens when I have detailed control about a relatively large amount of my personal information and fine-tuned granularity about how I share that information with the world around me?” Humans in every cultural and temporal collection have had control of simple sets of personal information and how it is distributed via clothing, hairstyles, makeup, tattoos, &tc. These primitive coding systems change over time and require some amount of interpretation and authentication on the part of the receiver. Some subcultures have specific coding mechanisms that are highly-specialized and that don’t translate well outside the community and may not even be recognized as a code by outsiders. Flagging via the hankie code is subtle and probably not recognized (much less decoded) by anyone not familiar with the schema and symbols it uses. These subculture-specific encoding mechanisms require a shared set of interpretations between the sender and receiver and the mechanisms can easily be misinterpreted or not interpreted at all when in the incorrect context. Flagging means something in the Castro neighborhood of San Francisco, but does it mean anything in Tokyo? If I’m visiting friends in New York City or London, are there clothing colors, styles or brands I should avoid if I don’t wish to be thought a gang-banger or a chav?

So let’s say I take a SRM and tinker on it a bit to give it a few additional capabilities:

• broadcast selected information on a routine basis
• respond to broadcast queries (a request to any SRM within listening range) from individuals or entities with specific information
• respond to directed queries (a request to my specific SRM) from unknown but potentially trustworthy entities
• respond to directed queries from specific authenticated individuals or entities
• receive and translate schemas and protocols used by other entities, SRMs and spimes to local, internal schemas and protocols

With these changes I can broadcast data and and any needed translation mechanisms or schemas to other individuals or my surrounding environment in order to correctly identify (or obscure) my identity, likes, dislikes, and needs. I can warn emergency services personnel about existing medical conditions, tell a building I enter about my preferred working environment, or broadcast a authenticated message from a local holder of power that I am under their protection. I can make my availability and orientation known in a singles bar without identifying myself and the bar can collect that information in order to allow in more of the appropriate mates and fewer of the inappropriate ones.

I don’t want everyone to automatically know everything about me or even to know my identity — I want select individuals, businesses, chartered organizations or the public to each know something specific about my patterns, personal tastes and status within the local reputation hierarchies.

My SRM has become something new — a Personal Data Broadcast Device (or PDBD, as I’m feeling a bit acronym happy) that distributes data about me of my choosing to the world around me. Design and implementation of the PDBD is probably more important in the world of The Participatory Panopticon than it is in the spime-full world, but it is built on technology and infrastructure similar to that required to develop proto-spimes.

When I turn on my PDBD, I become a proto-spime. I am now interacting with my environment in a more active and controlled fashion than a typical passive proto-spime or spime, but I still collect, process and redistribute information. In addition, I can dynamically define classes of information and who gets that information in reaction to my environment or new circumstances. (To be a proper spime I would have to have been designed (genetically engineered) from the start with the expectation I would exhibit spime-like behavior. Perhaps I would be able to provide power from my nervous system and collect and store data using my existing senses, but that’s a topic for a future entry.)

When I go to Deathguild, I want the DJs to know what songs I like and I want the bartender to know how often order drinks for groups of people and that I have a history of tipping generously. Neither the DJs nor the bartenders need to know who I am, merely that I am physically present and what my likes, dislikes and buying habits are. Knowing who I am can increase their level of trust or lead to further personalization of my experience, but it is not required for a basic level of interaction. I can make my identity known to entities that I trust or already know, but the general environment won’t have access to that information.

The data I — a proto-spime — distribute isn’t always originated by me but it is data I want to distributed. Not only will I broadcast information of my own selection, but I will also make available data about me generated by others. If you’re a bartender you shouldn’t trust me when I say I’m a great tipper, but you will probably trust other bartenders in the neighborhood. You’ll be able to verify that I didn’t generate a fake message from them about myself using a authentication and nonrepudiation mechanism.

Cryptography 101: authentication and nonrepudiation, the ability to prove that a message was created by a specific entity and prevent them from denying they created it, is an important security concept in both the physical and digital realms. In the physical realm, these tasks might involve a signature, seal or watermark on a document that is both difficult to forge and known to the recipient. In the digital realm, the electronic copy of a document is “signed” using a “signing key” and a cryptographic algorithm like ElGamal or RSA. The “signature” is then attached to the document similar to a footnote or cover-sheet being attached to a physical document. Anyone receiving the document and signature can verify that the document was created by the owner of the signing key and that the message has not been altered since its creation. See Schneier’s Applied Cryptography for more on this subject.

So while I have enough control over my PDBD to delete information I don’t like or don’t want, it is near-impossible for me to fake favorable information about me purporting to be from a known third party. An entity deciding whether or not to act upon data I provide would validate that data thru one or more trust networks that would range from ad-hoc, neighborhood level associations to government or international bodies running trust hierarchies. (Verisign and other companies currently operate trust hierarchies that use SSL certificates to authenticate web sites and web browsers.) Trust networks used by entities to validate my information would be independent of one another and each would likely operate by its own levels of trust mechanisms and standards. A trust network might be a collection of neighborhood bars that share information on good tippers, local power structures (law enforcement or street gangs) that provide identification or reputation references, a government organization or corporate body providing authentication services, or even mutual data sharing programs operated by airlines, hotels and other travel services. (More fodder for future entries: What happens when a trust mechanism requires that I allow negative data to be included in my digital reference if I want to use their service? Do I become a “blank” rather than let Trans Global Airlines note that while I’m a million-mile member I also tend to drink to excess and make trouble with the flight attendants? If I’m a blank for other reasons, will people assume I’m trying to hide negative information?)

When it comes to non-authenticated data, there’s little reason for third parties to automatically trust the data I send out about myself. The Deathguild DJs could compare my “favorite songs list” I broadcast to what I actually bother dancing to or reject the list entirely because it is too divergent from what other club members are reporting as their favorite songs.

“Broadcast” vs. “Transmit”: I’ve intentionally used the word “broadcast” instead of “transmit” in this entry for a very specific reason — the technology described here relies on radio frequency (RF) communications, and RF is by nature a “broadcast” technology. Unlike a switched TCP/IP network that can easily route data directly between two systems never to be seen by any other system, broadcast RF can be seen by any system within a given distance. This distance is determined by transmitter power, antenna size and design, and the environment in which the communication takes place. The 802.11 protocol operates in the 2.4Ghz range and can easily penetrate walls, vehicles, and other line-of-site obstacles that we humans perceive as limits on communication. Given that anyone can listen in on broadcast packets, proper encryption of communication channels is a must for Everywhere or the spime-full world.

I won’t broadcast most information without a specific, authenticated request, and I certainly don’t want to reveal sensitive personal information to untrusted sources. I don’t want a random person on the street to know my shopping preferences or how much I’m willing to spend on an item; my age, ethnicity, religion or sexual orientation; or my medical history or any physical disabilities. Who I decide to trust, what data I will share, how much certainty I require that they are who they claim to be, and the ramifications of a failure in the trust mechanism are questions we will need to answer.

PDBDs, Spimes, and Their Security

The request, authentication and data broadcast interactions discussed so far are automatic and happen without my explicit knowledge or approval. A spime doesn’t check with an owner to verify each request, it operates under a set of rules that define how to validate a request and how to respond to valid and invalid requests. This request mechanism is the only acceptable way to move data off of a spime. Any spime (not just a PDBD) carrying truly sensitive data cannot be designed or implemented in a way that allows for direct reads under any circumstances. If my PDBD is lost, stolen, or simply not under my immediate physical control, another entity should not be able to access the information stored within unless I have previously approved of that access. That is to say, there is no “root” or “administrator” level of access that will reveal sensitive data stored on a PDBD or spime, only a query from an authorized third party (as predetermined by me) will cause information to be revealed. (I’m handwaving over the question, “How do I install rulesets that prohibit access but prevent an attacker from replacing those with rulesets that allow access?” More material for a later entry.)

The requirement that a spime be completely “locked down” requires a great amount of trust in the algorithms and implementations used, as a vulnerability would be easily exploitable without the knowledge of the owner. It is critical that every component of a spime fail safely, not operate on bad data, not have backdoors and do or not do all the things we require out of our most secure computing environments. I would suggest that only open source code and public algorithms be used to implement SRMs and spimes and that significant effort needs to be put into developing authentication mechanisms for executables and how they are installed. The OpenSSL, OpenSSH and OpenBSD projects are a fine example of how secure software for communication channels and operating systems can be developed and distributed for use by third parties.

What I, the Human Proto-Spime, Cannot Do

Based on our earlier distinction between passive collection and dissemination of data vs. active decision making, I as a human proto-spime will be limited in what actions I can perform with my PDBD. Many of the actions one assumes I’d do with a PDBD would likely be performed using a different, more personal object I carry with me or access remotely. For example, I cannot use my PDBD to:

• vet a third party by generating a signed statement about them
• engage in business transactions involving money or goods stored on the PDBD
• collect, relay or transmit audio or visual streams for rebroadcast
• view media, access the InterWeb, or perform other communication tasks

This “separation of powers” pays off in a number of ways. The simple SRM used as the basis of my PDBD will be cheaper to manufacture and will not create a security risk if lost, stolen or otherwise compromised. Anyone who finds a lost PDBD might not be able to determine the owner, even with the help of a third party or possibly the owner themselves. Rather than try and identify the owner, it would be more efficient for the finder to wipe the device and use it themselves or return it to the manufacturer to be wiped and reused.

It is quite possible that a PDBD would be embedded in some other host device I own, but unless it could be easily removed I might not be as likely to carry it around. My wristwatch or a piece of jewelry I wear every day is a more secure and dependable place than a part of my mobile phone, laptop or PDA that I have to carry in a pocket or bag; that I can lose; or that I might replace or send in for repair.

Technorati Tags: spimes, participatory panopticon, everyware, ubicomp