ALL ART BURNS

It does, you know. You just have to get it hot enough.

Sunday, September 10, 2006

When the Environment is the Enemy: Teague

Yet another surprise in the mail bag.

WTF? An expanded polystyrene (EPS) box from Teague? What manner of prank is this? Did someone I know get hired at Teague and put me on their elite client list? (Well, not too elite, it is made of generic EPS and not Styrofoam(TM) brand EPS.)

Um. Ok. A EPS box with a little booklet inside it.

A little booklet showing me their work in hopes I’ll hire them. I’m a software engineer by day and an ID student by night. Why are they sending me this? Did they send this to every student member of IDSA?

The box lets me know that it “can be recycled”. Well, lots of things “can be recycled” if you live in the right part of the world, but how many of us live in a place with easy recycling of block EPS? In the back of the book there’s a note saying I should call a 800 number or go to a website to find out where to recycle it, and that if I can’t recycle it, I can mail it back to Teague and they’ll recycle it:

No joke. Apparently I am either supposed to throw it away, figure out where to recycle it, or pay postage to send it back to Teague.

Looking at epspackaging.org, the nearest place that takes EPS is 45 miles away. I should burn how many gallons of gas to recycle something I didn’t need or want in the first place?

Why not just send me the little booklet in a fancy little cardboard box? Or better still, not send me anything at all until I’ve expressed interest in their services? What’s the fully-loaded cost in terms of natural resources of developing this little piece of advertising and shipping it out to who knows how many people? How many of these boxes will get recycled? How much fuel was burned by the vehicles delivering these boxes?

Perhaps the actual content in the booklet have been better delivered to me via the web. The booklet is smaller than a CD insert so the type is very tiny and the spine won’t lay flat. Even if I wanted to read this it’d be difficult to do so.

Thanks, Teague!

Technorati Tags: , ,

posted by jet at 10:05  

Saturday, September 2, 2006

When the Environment is the Enemy: Sears

The other day the mail carrier dropped off a 19″ x 16″ padded plastic envelope. The return address said “Sears”, but I couldn’t think of anything I’d recently ordered from them.

one envelope

I opened it up and discovered that it contained four, 14″ x 12″ padded plastic envelopes.

one envelope

After opening the first envelope, I remembered that weeks earlier I’d ordered the service and install manuals for the stove that was already in the house when we moved in.

one envelope

One of the envelopes contained only a single sheet of paper: a schematic for the stove.

At this point I’m pretty peeved. I’ve got five envelopes made of plastic that I can’t recycle or reuse.

Then I got to noticing that the stack of paper I had was pretty light, possibly lighter than the weight of the packaging itself. I don’t know what the postage charge was, but the thought of paying to have stuff shipped to me that I can’t use or recycle really makes me cranky.

So I broke out the postal scale.

Stove documentation, 6.5oz:
one envelope

Packaging, 7.5oz:
one envelope

That’s 7.5 oz of plastic mailers to protect 6.5 oz of paper. I paid twice the postage for unnecessary packaging that will end up in some landfill.

Thanks, Sears!

Technorati Tags: , , ,

posted by jet at 16:40  

Monday, July 10, 2006

The Future of Data

[More thinking-aloud about how tags and spimes will change things. I’m also in the middle of Everyware and am trying to finish this while reading that.

I said I’d be writing about security next, but I ended up thinking about about the future of data in terms of public policy and societal issues regarding collection and ownership of data. Security is in the queue, but I need to figure out the requirements and context before I think about the implementation.]

The Future of Data

A world filled with RFID tags, smart tags, readers, and spimes reveals a vast amount of easily accessible data not previously available to the individual. A store currently has an idea of its inventory, shrinkage, and daily sales, but I as a shopper wouldn’t know any of that information. A movie theatre would know how many tickets it sold while as a guy watching a movie I can only do a rough count of empty seats and make a guess.

In the near future you or I will be able to know these things, should we choose. We will be able to wander through a public place and automatically collect vast amounts of information in a form easily used by computers instead of tediously taking notes and making spreadsheets.

Think about the world we’re about to inhabit:

  • Any object with a more than nominal monetary value has some sort of RFID-like tag used to track the object from creation thru the point of sale and afterwards into its usable lifespan. Not only will the merchant you bought a shirt from know you bought a shirt (and link that information to your customer account), they’ll know every time you wear it past or into their store. You didn’t just buy a shirt, you gave them a fair amount of useful marketing information when you used your credit card to buy the shirt and even more if you ordered it online and had it delivered. If you physically enter a store, the odds are that they’ll also be able to determine who made all the other items on your person and possibly what those items are, then tweak their sales pitch at an individualized level.
  • Your PDBD is blasting out data to any device that queries it or broadcasting in cleartext to every device in range. So is everyone else’s, and simple proximity mapping will make it trivial to plot each step by each person through public and even private spaces.
  • Readers are everywhere: every business or home has one at the entrance, and most have several inside that operate on different classes of tags using domain specific requirements. The door reader looks for all tags, the inside reader looks for local tags or those that meet a limited set of criteria. Think inventory tracking vs. employee tracking, then imagine every object worth more than a few bucks have its own unique serial number and tracking device.
  • Really, readers are everywhere: every commercial delivery vehicle with have some sort of tag reading mechanism to track packages between being picked up and delivered. Reading the contents of those packages will be trivial, and delivery firms will not just have databases of who ships how many packages and to whom, but the contents of those packages will be known.
  • Spimes and other types of smart objects (smobjects? smaarbjects?) are collecting data from their surroundings and reporting it back to their owner or the general public. “Data” is any information that can be collected and stored: location, time, temperature, number and type of other tags and spimes seen, data those smart objects have transmitted, etc.
  • Proto-spimes are doing this now: A case of expensive wine can know if its been stored at the correct temperatures, a laptop will know if it’s been dropped, a shipment of fragile goods can know if it’s been subjected to improper environments. Take a look at Maxim’s iButtons for an inexpensive, common, off-the-shelf (COTS) example of the technology required to track environments of packages or equipment.

How Your Role Will Change

The technology to collect, store and analyze vast numbers of RFID or other smart tags is about to become very accessible to the masses, very portable and very easy to hide. RFID and other inexpensive tagging mechanisms won’t have the sort of security that a full-on spime has and will be easily readable by just about anyone. (To keep things simple, I’m going to lump publicly readable data from spimes in with data from RFID, bar codes, and other insecure tagging mechanisms and refer to them all as “tags”.)

In a short time — months or a couple of years at most — it will be trivial to build an advanced tag monitoring system that not only scans all nearby tags but call also passively eavesdrop on other scanners as they communicate with tags. Your involvement in the participatory panopticon will go from one of passive participation to active engagement. You no longer have to be just another data point, you can also be a collector, analyzer and interpreter of data and a distributor of information.

What happens today if you wander in with a pad of paper and start writing down a store’s inventory and pricing based on what’s on the shelves with the intent to post it to a web site? You’ll probably get kicked out of the store because most stores have policies about what data you can collect while you’re on their premises. (Try it at your local Wal-Mart if you don’t believe me.)

But what if data collection isn’t obvious? Today, you get kicked out of a store because you are obviously collecting data they don’t want you to collect. What if it just looks like you’re idly browsing through the racks and shelves? Will they kick you out for simply browsing?

In the near future, anyone will be able to wander in to a store with a PDA in their jacket or backpack and a tag scanner up their sleeve and start reading tags on any nearby merchandise. To any human, they will look like someone idly wandering around the store — the typical bored person waiting on their spouse to finish shopping. Perhaps a nearby tag reader would throw exceptions about tag reads that they didn’t request, but would any human get notified in a reasonable amount of time?

Data as Property

Who “owns” the data you just collected with your portable tag scanner and who can do what with it? Is it yours? Does it belong to the store? Facts can be copyrighted, is the state of the store’s inventory a fact that can be somehow put under copyright? Or do you now own a database of facts that you collected in a public space for which you own the copyright?

I can stroll up and down every aisle in a small store at the mall in a matter of minutes, plenty of time to scan not only the inventory on the shelves but the overstock under the shelves and maybe what’s in the back room. If I’m lucky I’ll also get data on other customers in the store and possibly record a few purchase transactions. (One would hope that purchase transactions use some sort of strong cryptography, but I can imagine plenty of systems that use weak or no security in the interests of saving a few pennies.)

When you enter a store and a monitor at the door reads all the tags on your person, what can they do with that data? Do they own it? Do you own it? If I sit in the middle of the food court at the mall with my laptop reading data on all the passersby, what can I do with that data? How about if I monitor the reads being performed by the scanners at the doors of businesses? What if I monitor my competitor’s reader across the way? Next time you’re in a shopping mall, notice at how close together doorways and cash registers are, how many are within line of site of one another, and how many of those businesses are competitors who would benefit greatly from this sort of data.

Data as Property Today. Here’s a question to ask yourself: “Who can collect what data in my household and what can they do with it? Do you have a DVR in your house or a digital cable box? Do you have other consumer electronics devices in your entertainment center that can contact a remote server using phone or broadband? How do you know these devices aren’t recording the clickstreams of all your remotes, not just the one that each obeys? There’s no magic that says “only send my remote control infra-red beam to a specific unit”, anything in your entertainment center is going to receive an IR signal from any remote you use and could be collecting your remote presses and sending them off to a third party. If you’re concerned about the answer to this questions, read the privacy policies for the services you subscribe to or contact the companies providing you service.

Hacking the Near Future

So far we’re just talking about COTS technology and most (all?) of these things can or will be done with commercially available tag reading software and hardware. If you want to start writing your own code or hacking your own hardware your data collection and distribution options are greatly increased.

Today you can build an extended range RFID “skimmer” that can poll tags well outside the normal operational range of a few centimeters (See Kirschenbaum and Wool, “How to Build a Low-Cost, Extended-Range RFID Skimmer”.) Yes, it’s bulky and obvious, but you could probably hide one under the counter at a cash register, near a doorway in your business, or in the backseat of your car.

As you’re collecting data from tags in the world around you, you’ll probably pick up a few that are authentication mechanisms of one sort or another. These are useful for replay attacks — when someone copies an authentication token and re-uses it at a later time without the owner’s permission. In the RFID and token world, this could be anything from a toll road account to an employee door badge.

Current RFID and Smart Tag Security. WIRED has an excellent article on RFID hackers worth reading. My personal experience with tags is similar: I have worked with some physical security systems based on RFID-like technology that did everything in the clear and with no authentication. Duplicating a specific card’s ID number was simply a matter of sniffing the transaction at the door reader or using a “rogue” door reader attached to a PC to query a card. No authentication was used by the card to verify the identity of the reader making the request and the server had no way of knowing if the card ID number presented was from the original card or a physical duplicate. Imagine security based on responding with a correct answer to a simple question:
“What is your employee ID number?”
“12”
“Access granted.”Do you feel comfortable knowing that any person who said “12” could open the door to your building? Or would you prefer some sort of verification along the lines of, “Only current employees of the company who answer the question with their secret serial number” or “Only people I trust who know today’s serial number” to be used as conditions for access?

Crimes, Hacking and Pranking

A high powered tag pinger that could query all tags within a meters feet would be a handy thing for me to have if I were of a criminal bent. Instead of guessing which bag to steal from a passerby, which locker to break into at the gym, or which package to steal from a delivery truck I can just wander around scanning things until I find a likely target.

From the other side of the data equation, what’s to stop someone from making bogus tags or making a device that responds as if it were a tag but with bogus data? Someone might notice me physically replacing the bar-code on an item in a store or trying to remove a security tag, but will they notice the RFID emulator in my courier bag? Will they be able to tell that I used it to drown out the tags of any items I have with me as I go through the checkout line or walk past the security scanners at the door?

Theft is a criminal act for which I can be prosecuted, but what if I just send out bogus data with no intent to commit forgery or fraud? Me and a few dozen of my pals looked like poorly dressed people who wandered in to a high end store, looked at a bunch of expensive merchandise and walked out out without buying anything. However, the tag reader at the door logged us as well dressed individuals carrying laptops or expensive cameras. When the store owners sit down to analyze all their demographic data, they’re going to be looking at some very bogus information that will probably lead them to make improper business decisions.

If I suspect my competitor across the way at the mall is snooping on tag activity at my store, what’s to stop me from generating false tag activity? Is it (or should it be) illegal to broadcast fake transactions or other data knowing that my competitors will collect and interpret that data?

Some Questions

These aren’t new issues, but the technology that makes business more efficient makes everything else equally efficient. Hacking, crimes, invasion of privacy, &tc all become more efficient as well. We need to answer some new questions and come up with new answers for old questions:

  • What is data?
  • What data can be owned and what is in the public domain?
  • Who can own data?
  • What safeguards does an owner of data have to take to prevent that data from being exposed to the public?
  • How is ownership of data determined?
  • Who can control data collection?
  • Who should control data collection?
  • What rights are there to collect data, if those rights even exist?
  • What rights are there to prevent collection of data, if those rights even exist?

When I started writing this, I was thinking about securing tags, proto-spimes, and spimes by first determining the requirements created by their environment. I quickly realized that many of the questions I was asking were questions about public policy, laws and social agreements, not questions about technology. The security questions are important but they’re simple engineering problems and will be easily solved once we know the requirements. The questions about how public policy, legal and social agreements will change are much harder to answer than the security questions; our answers will have profound impact on what our world looks like in the coming decades.

Technorati Tags: , , ,

posted by jet at 21:24  

Tuesday, May 16, 2006

The Human Proto-Spime

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

entity making request type of data to be shared amount of certainty required to share costs of authentication failure
family, close friends, personal physician or legal counsel sensitive, private information about me or my family: medical records, real-time data relaying physical or emotional information possibly more than can be implemented in this mechanism; at a minimum prior personal contact massive legal, financial, or emotional damage, public humiliation or embarrassment
businesses with existing legal relationships sensitive personal buying preferences or information: size, medications taken, account number or related information prior personal contact minor to major legal, financial, or emotional damage, public humiliation or embarrassment
businesses with no existing legal relationships or prior contact personal contact information and general buying preferences: preferred colors, brands, flavors, items I’m interested in buying verification by trusted third party varies: a failure results in disclosure of data I would have given to a potential business contact but not necessarily made available to the general public.
non-commercial, chartered organizations: churches, political groups, social organizations semi-personal data related to volunteer availability, meeting schedules, religious or social affiliations or preferences prior personal contact; in some cases verification by trusted third party disclosure of religion, political or social preferences, cost depends on context in which the information is disclosed and to whom
government agencies collecting demographic or aggregate data anonymous demographic information verification by trusted third party limited, this is information someone could determine by visual inspection or other external measurement systems
emergency services, first responders medical information (if injured), useful skills (if available as a volunteer) verification by trusted third party exposure of personal medical conditions or personal information
individuals with an existing “relationship index”; friend, coworker or neighbor ranked %0-%100 depends on my personal preferences prior personal contact, no third-parties involved depends on the information shared
untrusted / unknown depends on my personal preferences depends on the information shared and who I’m sharing it with depends on the information shared

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: , , ,

posted by jet at 19:00  

Saturday, April 29, 2006

On the Path to a Spime-full Future: Proto-spimes

(I’m writing these as an exercise in thinking out loud and starting some dialog. I make no claims of breaking new ground here and welcome criticism. –jet)

The concept of a spime is simple to understand, the path to a world of spimes is not as obvious. Instead of attempting to invent spimes out of whole cloth we can extrapolate from existing capabilities and look to what we can do now or in the immediate future. Between the spime-less now and the spime-full future we will go through a brief period of working with what I’ll call “proto-spimes”.

Proto-spime: an existing object retrofitted for spime-like behavior by tacking on some number of sensors, computing resources and communication mechanisms. A proto-spime exhibits spime-like behavior but is no more a spime than a person who speaks another culture’s language is a member of that culture.

The arbitrary line I draw between a proto-spime and a spime is that of design intent. A proto-spime was not intended to have spimelike behavior when it was initially conceived and designed; a real spime has intent in the initial conception and design. Compare this to early portable personal computers and modern laptops: Early portable computers were PC-ATs smushed into portable cases while modern laptops are not only designed and built on the plan of portability but often contain features unique to portable devices or lack those found in non-portable devices.

The process and benefits of retrofitting items with simple magnetic or radio resonant tracking tags is well understood across a number of industries. Inventory management systems can easily track items that have a small barcode on the surface or a resonant tag embedded inside; these range from books leaving a library to a rental car being returned. This model of items being managed by users is one starting point for thinking about proto-spimes. The requirements and processes are well understood, we’re simply extending and enhancing an existing model with smarter tags.

Making a proto-spime

The resources needed for spimelike behavior — basic data collection, storage and retransmission– can currently be packaged in a small space and had for a relatively low cost in volume. Maxim’s iButtons are a current example of this sort of device. About the size of a few stacked dimes, iButtons can collect or store data and can draw their operational power from their communication channel. (The 1-Wire protocol is also used by personal weather stations and other devices needing minimal operational power for data collection and communication.)

Spime Retrofit Module (SRM): a device capable of data collection and transmission that does not communicate with or control its host. A SRM possibly has limited decision-making capability in the domain of what data is collected and who it is shared with.

Let’s assume for the sake of design that our basic spime retrofit module is larger than an iButton, about the size of a 9v battery. Let’s also assume that a fancier version with limited computing power and the ability to initiate communication with other spimes is the size of a two or more D cell batteries. The basic SRM can log limited amounts of data and transmit it on demand from a powered reader; a fancy SRM can collect data, make simple decisions, initiate contact with other spimes, or decide when to broadcast data to passive sensors.

Batteries are good models for our SRM for a few reasons: the size and weight are understood across most cultures, they are easily fitted into a variety of existing items, and most importantly, there are plenty of CAD models already in existence.

So what do we do with these spime retrofit modules?

Initially, SRM’s can be easily attached to or installed in existing items that their humans want to know more about (or will soon discover they want to know more about). Some of these items might not be worth redesigning as proper spimes while others might be more than useful with an embedded SRM.

Once we’ve learned a few lessons with proto-spimes we’ll be able to include the other side of spimes — data collection and management — in the iterative development process of spimes and SRMs. For now we’ll just stick to uses of the first generation of SRMs. (With the addition of the ability to directly manipulate its physical environment, a SRM becomes an autonomous, data collecting robot. I think these are interesting but because they can manipulate their environment they don’t match my definition of a proto-spime as a passive data collection device.)

Early Adopters of Proto-Spimes

The obvious adopters of proto-spimes are organizations that manage, move and maintain inventory and items. There are other early adopters in areas where individuals or groups have an interest in data and metrics collection to use as feedback for performance or entertainment purposes.

People responsible for equipment used by others

IT departments will be able to track the physical history of laptops, portable projectors, or other high-value and easily-damaged items. How often does the new high-end projector actually get used and in what conference rooms? Why does it always spend the weekends at the same person’s house? How and where do laptops get broken? Where does the tool cart spend its time during the day and what sort of equipment is it used to move?

Tool and equipment rental firms can verify that their rental items weren’t subjected to environments that violate rental terms or safety restrictions. In addition, they’ll be able to know how long a tool was used and in what ways, information critical for both routine maintenance and product marketing.

Auto rental companies and other transportation firms are already using proto-spimes in the form of black boxes that collect driving data and track the location of rental cars.

Athletes and Coaches

Data and metrics collection are a key component of most sports and many athletes and coaches are already moving into proto-spime territory to gain a competitive edge. This is already common in motor-sports, vehicles are heavily instrumented and the data is relayed in real-time to team managers and engineers. Other types of sporting activity has yet to directly benefit from this sort of real-time data collection and analysis.

Cyclists currently use integrated computers that collect information on things like heart rate, pedaling cadence, altitude, and speed. These are displayed in realtime for feedback to the cyclist while riding and saved for later post-ride analysis. With some simple (and hopefully lightweight) additions, these proto-proto-spimes will not only collect data from their bike but share data with nearby cyclists or even spectators. Teammates will be able to use shared data to optimize their pack performance while riding and more easily anticipate needed changes in ride order or speed based on one another’s physical performance. (All I know from bicycle racing is listening to my friends talk about it. Feel free to fill me in on the reality.)

Sports that use objects — hockey, football, basketball, golf — will be able to collect information from the objects themselves during and after an event. How hard a ball was kicked, how damp the green was, the precise amount of time between events and information on the playing surface and environment will all be immediately available to interested parties. Players of team sports that use objects can collect data on the performance of other players by monitoring objects to look for patterns of weakness, strength, or exhaustion that are not normally perceptible during game play.

Environmentalists, Anthropologists, and Other Observers

SRMs are drop-in replacements for many of the tracking devices used by people who monitor objects in the environment. Instead of simply relaying position, they will be able to collect information on their environment, save that information and exchange it with other SRMs in the wild. SRMs will be able to feed information to one another on additional data that needs to be collected, back up data carried by other SRMs in order to ensure that data gets back to the SRM’s owner.

I think this might be the most important area for design and development of proto-spimes and spimes. The ability to collect and dynamically manage data from the field and ensure a high return rate of that data to the collector is useful for everything from weather forecasting to studying the remote corners of the planet.

An entire pod of dolphins could be instrumented for data collection and return not only information about their world, but information about the dolphins who did not return and why they did not return.

An SRM that is small enough and sturdy enough to survive the digestive process might go from an organism low on the food chain to a higher organism. While it may never be retrieved, if it senses a friendly/compatible SRM nearby it could relay its history and increase the chances of its data getting back to the owner

What’s next?

The handful of examples here has me thinking about a number of engineering, legal and ethical questions:

  • Who owns data collectd by a spime?
  • What are the rules of engagement for spimes in the wild?
  • What data can I legally collect and store?
  • How do I protect my data?
  • How do I protect my spimes from being spimejacked? (And am I the first perso to use the work “spimejacked”?)
  • Are self-transporting spimes useful? How are they different from “software agents”? Is it time to dust off my Telescript developer’s kit?
  • How do we prevent ill-effects from all the RF fields used by spimes, both physical damage to the environment and harmful interference to other users of the airways?
  • How do we make SRMs that are low-impact on the environment should they become lost or damaged?

Technorati Tags: , , , ,

posted by jet at 15:46  
« Previous PageNext Page »

Powered by WordPress