You are here: Home / Archives for Ian Glazer

The Identity Portability and Accountability Act of 2011

13 June 2011 by

Last week, the NSTIC program office held the first of three outreach workshops. While a who’s who of the identerati (along with government and trade group representatives) discussed what kind of governance body NSTIC requires, there were a variety of productive hallway conversations. I was involved in once such conversation in which a well-respected chief security officer of a large identity company half-joked, “What we need to do is re-write HIPAA, word replacing it to talk about identity.” Not being the blogging type, this security officer said I ought to take this idea and run with it. Here goes nothing…

The Identity Portability and Accountability Act (IPAA) of 2011

Whereas identity is foundational to all transactions (financial, informational, etc.) on the interwebs, identity is poorly defined and protected by law. The Identity Portability and Accountability Act of 2011 seeks to:

  • Describe a minimal set of attributes deemed to be identifying
  • Establish the legal standing of identity and attribute providers
  • Define minimum standards for the protection of identity information
  • Codify individual’s rights with respect to their identity information

Whereas Congress has spent an enormous amount of time regarding portability and accountability of health information (and given that it is also almost the summer and who on earth wants to stick around DC in July and debate), this body shall simply word-replace the current contents of 45 CFR Parts 160, 162, and 164 to form IPAA. IPAA shall draw upon HIPAA’s two Rules: Security (45 CFR Part 160 and Subparts A and C of Part 164) and Privacy (45 CFR Part 160 and Subparts A and E of Part 164). The following substitutions shall be made:

HIPAA term IPAA term
Health care provider Attribute provider
Health care clearinghouse Identity provider
Business associate Relying party
Protected health information (PHI) Identity information (II)

Whereas, after word-replacing as described above, the language within IPAA seems to still resemble English (at least as much as any bill resembles English), this body shall describe the rights and standing of identity and attribute providers…

And so on. There is some usefulness in such a ridiculous endeavor. Instead of discussing what happens when identity and identifying information is disclosed (a la a breach notification law), why not codify a minimal set of identity information and some basic rules of the road for identity and attribute providers. (If we are to have a thriving identity ecosystem as NSTIC hopes, I believe we are going to need some rule-making for identity and attribute providers, akin to credit agencies). Using HIPAA’s Privacy and Security rules as models, Congress could establish some basic data handling rules for such information, including safe harbor for the use of data encryption and relationship context metadata (my report on this will be release shortly). Most importantly, such a law could describe what rights people have to identity information about them. Following the recent rule changes to HIPAA, one could imagine that, by law, each of us could ask our IDPs for a log of both identity data use as well as disclosure.

I know that the security officer who gave me the idea for this post was only half kidding. But the other half isn’t a bad idea.

It is seven weeks to Catalyst. Seven weeks to great sessions, productive hallway conversations (like the one that spawned this post), and ample opportunities to network with peers. Relevant to this post, we have:

  • Deb Gallagher, chair of the Federal Identity and Credential Access Management (FICAM) sub-committee, discussing the governments role in identity assurance
  • Me discussing relationship context metadata and protecting privacy by using data labels

If you’ve got a half-joking, half-brilliant idea, bring it to San Diego, schedule a 1-on-1 with an analyst, and see where the discussion leads.

Filed Under: News Tagged With: , , , ,

No, really, who has access to what?

7 June 2011 by

In the unceasing wake of the RSA breach, and especially given Art Coviello’s most recent post, I’ve been thinking about what role identity and access governance can play in mitigating post-RSA attacks. As you know, I don’t cover authentication – that’s Mark’s beat and he’s been on this like a hawk. This separation of coverage reflects how most organizations work: teams focusing on remote access, teams focused on authentication, teams focused on provisioning and certification, etc. Ok, so if I represent the access governance team, what could I do to help?

The most important thing I could do is start identifying who in the organization has access to the most sensitive IP the enterprise has. It was this sort of information that was targeted in the RSA breach and it appears that the same sort of information was targeted in the Lockheed breach. So I as the keeper of the “who’s got what” repository ought to know who has access to such sensitive data.

Except, I might not.

Yes, I’ll know what entitlements are assigned to which people on which systems. But that isn’t the same as knowing what kinds of data people can work with. Overall enterprise identity teams have done a good job building out their entitlement catalogs. My customers constantly amaze me in describing the contents and scope of their entitlement catalogs. But there’s a gap. The mapping of people to entitlements is strong, but the mapping of entitlements to kinds of data is often weak.

Too often people managing access to data operate on tribal, implicit knowledge – if it comes from that server, then the data is likely financial data. But unfortunately, that tribal knowledge doesn’t make it into our entitlement catalogs.

I’m starting to believe that “kind of data” is the new perimeter for the enterprise. Each kind of data in the enterprise has its own attack surface, and protecting and governing access to those kinds of data requires blending different techniques depending on context. The entitlement catalog has a major role to play, but it can only do so if we start making explicit what kinds of data entitlements enable action upon.

Just a heads up, I’ll be talking about this idea in the privacy track at Catalyst. See you there!

Filed Under: News Tagged With: , , , , ,

Privacy contexts over dinner

24 March 2011 by

This weekend I had an opportunity to attend a dinner that, besides providing great food, presented me with an interesting exercise in privacy expectations.

There’s a person here in DC who hosts weekly dinners featuring Gujarati food. Seats are incredibly limited. The identity of the host is a secret. Even the event’s location is a secret up until the morning of the dinner.

To get a seat at one of these dinners, you have to fill out a very detailed reservation form. The form asks you to describe your cooking habits, what interests you have, and an anecdote. Further the form asks for your phone number, age, and for a photo. All this to get a reservation. (It reminded me a bit of L.A. Story’s L’Idiot restaurant.)

As a patron, my expectations were probably similar to yours in the same situation. I want to eat a restaurant’s food. I am trying to make a reservation. Asking for information beyond my name and phone number seems like too much. This was the context within which I was evaluating the situation.

Now here’s the wrinkle. The dinner is hosted at the person’s house. Every week, the person has dozens of people sit in the living room and eat. The host put together the reservation form as a means of protection. The host figured that a long reservation form would keep creeps and stalkers away. The context the host was using was one of a homeowner inviting strangers into the home.

Same data. Same form. Two completely different sets of expectations tied to two different contexts.

I am knee deep in my current project examining how we can help people make better privacy-respecting decisions by giving them more contextual information. The reality is that our data processing systems strip out contextual information. Customers, citizens, and partners becomes rows in a database, and when this happens people working with the data are denied a glimpse at the bigger picture and thus denied an opportunity to make a contextual evaluation. In my cases, this denial of context would have meant not having a great meal, but in the enterprise case the denial of context leads to far worse outcomes.

PS: Dinner was delicious and I’m glad I disclosed my private information. But of course, I did explain the problem of contexts to my host and offered to write a small privacy policy.

 

Filed Under: News Tagged With: , , ,

Privacy pendulum swings

7 February 2011 by

If you haven’t been following the “right to be forgotten” topic, this article in The Atlantic is a fairly good primer – and it has a few quotes from Marty Abrams as a bonus. I’m with Marty on this – I don’t think that the right to be forgotten has legs. It makes for interesting conversations but I question its practicality.

But this article did jog an old memory. I spent a very happy year of my life studying at the University of Edinburgh. I distinctly remember the day I got my account to access the AI department’s network. The administrator told me that I might want to change the read permissions on my account. By default, all student UNIX account were created world-readable to foster information sharing. I remember thinking – well that’s curious – we did the opposite back home. Oh how the privacy pendulum swings over the Atlantic.

Filed Under: News Tagged With:

Relationship context metadata

31 January 2011 by

In our paper “A Relationship Layer for the Web“, we defined a “contextual identity asset” as a package containing two kinds of information:

  1. Identity information about an individual
  2. Relationship Context Metadata

Relationship context metadata explicitly describes the relationship from which the identity information was obtained and the constraints imposed by the participants in that relationship on the use and disclosure of the information.

The idea behind using relationship context metadata is that it puts personally identifiable information “in context”; in the paper we described this process as creating a “contextual identity assets”.  Our theory is that putting information into contextual identity assets does two important things:

  1. Makes it easier for those receiving the information to treat it properly (because recipients can just look at the metadata to see what the rules are)
  2. Makes it riskier for those receiving the information to misuse it (because anyone can just look at the metadata and see if the rules are being broken)

So, for example, imagine that instead of an identity provider passing this little chunk of raw identity information to a relying party

  • Bob’s credit card number is 555-00-1212

the provider passes the following contextual identity asset to a relying party:

  1. This individual’s name is Bob and his credit card number is 555-00-1212
  2. This information has been provided in the context of relationship (services contract #42 between InterMedProvider and RelPart, Inc.); under the terms of that contract the information in part 1 may be used to authorize Bob’s payment for the current transaction, but the information may not be stored, displayed on a screen, printed, or transmitted to any third party.

The contextual identity asset in a sense protects itself. Unlike the chunk of raw data above, which conveys no information about the sensitivity of the information it contains or the rules for processing the information, the contextual identity asset is self-explanatory. It states which relationship will be damaged if the information is misused (the one between InterMedProvider and RelPart), and it also describes what uses are proper and what uses are improper. Recipients of this asset can understand their obligations to protect it, and they can understand what damage will be done by a failure to meet those obligations.

And, importantly, the contextual identity asset is meaningful not just to the technology infrastructure, but also in the “social layer” above the technology infrastructure.  Humans can look at the metadata and decide whether they’re about to do something wrong – or whether they have received the information as a result of someone else already having done something wrong.

We think relationship context metadata is the way forward in privacy protection; we think private information will never be well-protected until it’s easy to tell what the rules are and whether they have been broken.

We’re doing research about existing uses of relationship context metadata, about projects underway to create and use relationship context metadata, and about the nuts and bolts of what relationship context metadata should look like, how it should be attached to private data, and what policies should be defined surrounding contextual identity assets.

If you use relationship context metadata today, or if you have or know about a project to define and use it, we’d love to talk to you as part of our research .  Get in touch.  Here’s how:

  • On Twitter
  • Email: ian dot glazer ~at~ gartner.com
Filed Under: News Tagged With:

I “like” you, but I hate your apps – Part 3: Controls and a look at the market

28 January 2011 by

Happy Data Privacy Day! Or if you are in the EU – Happy Data Protection Day!

In my last post I talked about the desires of all the parties involved in this new style of relationship, one in which, not only you and I are involved, but also your apps. One thing is clear – better controls are needed.

Controls for me

To attain the kind of control that I want, there are two things I need. First, I need a language to express my wishes with respect to information about me. I must be able to express myself easily even though the expressions may be complex. The manner in which I build these expressions must be miraculously usable. This is not a problem for developers to solve, nor is it a problem for privacy professionals to solve. This is a problem of big “D” design. Here designers such as IDEO, Jonathan Ive, and Charlie Lazor must be enlisted to tackle the problem.

Second, the language and methods used to express how I want information about me to be handled must not only be simple, they must be applicable in multiple contexts. A person will not dream up every way that information about them can be used in just one sitting. Thus how someone wants their information used has to be malleable to be applicable in new unforeseen situations.

Controls for you

You want to obey social norms if for no other reason than thousands of years of societal development has constructed a reward system for compliance. Simply put – the more trustworthy you are the more trusted you become. And you want your apps to be as trustworthy as you are.

To accomplish this you need usable controls that govern how your apps use information about your relationships. You need to understand how apps use this information. You also need to know how apps build information through relationship-based interactions. Lastly, you need a means to control both relationship information use and construction. These controls must be usable, complete, granular, and non-invasive. Again, this is a problem of big “D” design.

One approach – trustworthy agents

Copies of information are bad. Copies of information about me lead to ownership issues. They lead to authenticity issues. They lead to freshness issues and they lead to disclosure issues. Instead of copying information about me, it would be far better for all parties to reference information about me.

But the question is from where should this information be referenced?

I believe the answer is – from a trustworthy agent. I provide the trustworthy agent with information about me and the terms under which this information can be shared. The agent then acts on my behalf. This agent is persistent and available. It can be consulted regardless of whether I am at my computer, on a bus in Bhutan, or on the operating table. This agent is a polyglot and knows how to express my information usage wishes to all parties. This agent is portable and can be consulted anywhere in both on-line and real world situations.

In a world of trustworthy agents, you still express your preferences about information sharing to your apps. When an app wants to use information about me it first checks your preferences to see if that use is okay. Then the app is directed to my trustworthy agent, which in turn determines if that use is okay. Then, and only then, does my trustworthy agent share the relevant piece of information. In this way your wishes are respected, my wishes are respected, and the app developer’s need for information are respected while minimizing the amount of information copied from place to place.

What is out there

So does such a fantastical trustworthy agent exist? … not exactly, but technology is beginning to catch up with our collective need for controls. First, User Managed Access (UMA) aims to provide a framework in which an individual can control access and use of information about them. Leveraging OAuth 2.0, UMA provides the kinds of controls that are needed. Second, the idea of a trustworthy agent, known more commonly as a personal data service, is starting to gain real traction. Projects stemming from ProjectVRM such as Personal Data Ecosystem and Mydex have begun to further explore how such data services could work. XDI has shown potential as the underlying protocol for such services. Again, a personal data service would be a way for your apps to respect my preferences: I’m happy and you and your apps appear trustworthy.

What isn’t out there

Unfortunately, your needs and the needs of the app developers aren’t addressed by both UMA and personal data stores. In order to meet these needs, device and platform makers must build “concern for the other” into their products. This is a big “D” design problem that requires not just user-experience intelligence but also classically trained design expertise. Baking “concern for the other” into products can be used to gain a competitive advantage in a market. By acknowledging that referencing information and pulling it from the source when needed, is superior to copying it, app developers have an opportunity to both mitigate their risks as well as provide better controls.

Because societal norms are formed at social speeds, it will take some time before society can provide guidance when your app does me wrong. To assist us all, technology and design must be enlisted and the needs of all parties must be considered.

Furthermore, both you and I are at the mercy of platform providers. Your apps run on a social network platform whose provider may have different goals, values, and principles than either of us. Similarly, your devices are likely connected to communication platform over which neither of us have a great deal of leverage.

In summary…

While social and legal norms play catch-up, we need to make our apps are trustworthy as ourselves. Until concepts such as UMA and personal data services are more wide spread we are at the mercy of the paltry controls that app developers provide. Apps are not uniformly trustworthy and their use of information far exceeds what is visible to and expect by their users. The reality is for the foreseeable future – I like you but I hate your apps.

Filed Under: News Tagged With: , , , , , , , , , , , , , , ,

The continuing story of Privacy Mirror

21 January 2011 by

For those of you interested in my ongoing tinkering with Facebook to explore how apps gain access to data, I have added a few more observations here. The short version is that although Facebook’s extended permissions to help inform users of how apps access data, the lack of fine-grained controls coupled with the unusual relationships between people and their apps remain problems that Facebook must address.

Filed Under: News Tagged With: , , ,

I “like” you, but I hate your apps – Part 2: Desires and Expectations

20 January 2011 by

In my last post, I contrasted the nature of our relationships with the nature of our relationships when apps are involved. In this post, I will examine the desires and expectations of parties involved in these relationships.

What about my needs, my desires?

I’m not unreasonable, but I have four desires:

  • awareness
  • control
  • visibility
  • redress

First and foremost, I want to be aware of when an app or devices uses information about me. I want to reduce the asymmetry of relationship between me and your apps. Second, I want the ability to declare what information can be used for what purpose. If I send you an electronic business card, I’d like to send along with the information about me a statement concerning how this information can be used. Also, I’d like to be able to declare (and delegate) authority of information about me. Ideally, I’d want to point your apps to a source of authoritative information about me, but we’ll get to that later. Third, I’d like some visibility into how information about me is propagated forward. Ideally, I’d love a way to know how information about me ended up in a service provider’s database. Lastly, I want some means of redress. This can take two forms. First, redress could be the ability for me to declare my information off limits to an app. Second, mirroring our relationships, I’d like the ability to sever my relationship with your apps independent of my relationship with you.

Simply put – I desire better controls.

What about you?

Unless you are a sociopath (and I am pretty sure most of you are not), you have tried to be a good member of society. This means that you have attempted to learn and adhere to both social norms and laws. It is safe to assume that you’d like your apps to be as upstanding as you are. No one wants to be perceived as trustworthy and yet have a blabbermouth social network profile.

With this in mind, you’d likely desire something that made it clear how your apps use information about the relationships you have. If apps could announce their information use practices as you enter a relationship with them and when you enter a relationship with me, then at least you could be better informed. This awareness enables you to decide whether you really do want to use the app. Imagine:

  • As you enter a contact into your smartphone, you would be informed as to how all the apps on your smartphone would use that information.
  • When you add a new app to your Facebook profile, it showed you how the app was going to use your social graph data – an impact assessment.

What this gets back to is a desire for control. An app that tries to be as upstanding as you are would provide better visibility and choice with respect to the use of information about your relationships. Apps that are bad actors will not provide such choice and likely go to great lengths to hide their actual use of the information.

What is expected of app developers?

But what of the other parties: the app developers, device makers, and service providers? The benefit you reap from their apps depends on the app developer being able to continue to provide services. The use of relationship-related information has to be expected and ought not to a surprise.

But that being said, app use of information from the app user as well as their relationships must be:

  • declared
  • understandable
  • allow for innovation

First and foremost, apps developers must declare how they use information gathered by their apps. There are too many issues related to notice to list here, but we can agree how information is used must be declared to all parties in the relationship. That declaration must be in a language that all parties can understand. Explaining to grandpa in rich legalese that pictures he shares will be associated with his contacts in his social graph and used for targeted marketing is not acceptable. Thankfully the movement for clearer, more approachable notice is well on its way.

Keep in mind that app developers need room to use information to innovate and offer new services. It would be a fool’s errand to enumerate every attribute possibly shared and declare specific uses for those attributes. Not only would such an enumeration become out of date almost instantly, but it would also constrain developer imagination and potential.

Control and redress must be provided. App developers and service providers must provide a method for people to express their preferences. Not only must app users be able to express how they want information about them and their relationships used, but the people in those relationships must be able to express their preferences as well. Furthermore, redress must be provided to all parties. When your app does me wrong, I need a way to seek redress from the app developer and have information about me removed.

From a responsible app developer’s point of view, the risks of unintended disclosures need to be limited. This points to a world of collecting less information and referencing more of it. Referencing has a secondary benefit to app developers – they do not have to develop as many controls over the information because people would express their information sharing preferences at a trusted source. The trusted source would enforce controls when the app referenced data at the time of use. Thus referencing not only reduces that amount of information that could be accidentally disclosed, it also reduces that amount of work an app developer has to do.

I’ll talk more about controls and this idea of a trusted source of information in the next and final post, which I’ll post on Data Privacy Day, January 28th.

Filed Under: News Tagged With: , , , ,

I “like” you, but I hate your apps – Part 1: The nature of relationships

14 January 2011 by

As I sat in my in-laws’ living room on Christmas, I realized that there were far more than just the 17 of us there. Almost everyone of us had our heads down toying with either a computer, iPad, or smartphone. Some of us, notably the teens, were interacting with each other, in the very same room, via one of those devices. Even the little kids were getting in on the action – downloading apps onto their dad’s iPad… an iPad with information about me on it. Hey, wait! I didn’t give my consent to this 4 year old to share information about me with unknown 3rd parties. (And until someone makes a unicorn and fairy version of the Fair Information Practices good luck trying to explain disclosure minimization to a 4 year old, but I digress.)

The apps we use introduce strangers into our daily lives. We, as a society, are not equipped to handle these strangers. If we do not address these strangers, we will transform ourselves from consumers into products, from upstanding citizens into unwitting informants.

The bottom line is: although I “like” you, I hate your apps.

In this three-part post, I am going to explore the situation we find ourselves in. We must first compare the nature of our relationships without apps to the nature of our relationships with these apps. Next I’ll consider what we want with respect to our relationships. Lastly, I’ll explore the kinds of controls we need and will also look at emerging technologies to help us out.

Why hate apps?

Before diving into the nature of our relationships, I want to provide a quick snippet as to why I hate your apps. Your apps, whether they are running on a smartphone or have been added to your social network profile, have access to a variety of pieces of information. Some of this information, such as your location and device identity, is specific to you. But some of this information, such as your contacts and friends, includes me. Your apps are gathering both kinds of information, using it, and sometimes sharing it with third parties. Research into this includes:

  • The Wall Street Journal’s What do the Know series on how apps gather and use information about you and your friends.
  • The ACLU’s and my own research into Facebook has shown how your apps can easily access information about your friends without their knowledge or consent.
  • Examinations of both the iPhone and Android phones with concerning results.

Our relationships

Let us consider the nature of our relationships. The meaningful ones are symmetric and have been established over time. (This is true even if the relationship is between a person and an organization.) This relationship is grounded in at least one set of social norms and subject to at least one set of law. Of course, the relationship might be subject to multiple sets of norms and laws depending on each parties cultural and geographic backgrounds.

When things go well we observe these relationships have three attributes:

  • mutually beneficial
  • mutually acknowledged
  • dignified

These relationships are mutually beneficial, and although the derived benefit isn’t necessarily financial in nature, it certainly can be. The bigger benefits of social interaction and connection often outweigh transactional benefits.

A “good” relationship is mutually acknowledged. All parties understand that they are in fact in a relationship. Acknowledgment of the relationship helps prevent the “dull, pervasive menace” of an asymmetric relationship. (See our freely available report, “Privacy” for more about asymmetric relationships.)

Finally, when things go well, a relationship is dignified. By this I mean, that all parties respect the dignity of the other. This includes treating shared information appropriately.

And when things go turn sour?

What happens when a relationship goes wrong is a fairly regular process. I, as one party in the relationship, can seek redress from you if you mishandle information I shared with you. This redress isn’t necessary financial in nature – sometime an apology is all the redress that is required. The redress process will follow a set of social norms. If you gossiped about me, I can ask for an apology. If the situation requires, we can also rely on a set of legal norms for redress as well. Further, we can use a third party to help mediate the situation. Lastly, either party is free to sever the relationship if they so desire.

Our relationships with apps

Our relationship to apps are asymmetric in nature. I have no idea what apps have added to your social network profile. I am unaware of all your devices that “know” about me. I have no idea what you have “said” to your apps about me. For example, I don’t know what my address book entry looks like in your phone – I might be listed as “Ian Glazer” or “The Hairy Analyst with Odd Socks.” In this regard, there is an asymmetric relationship – your apps have a relationship with me but not vice versa.

Furthermore, you may be just as much in the dark as I. You may (and likely don’t) know what your apps know about your friends. You may (and likely don’t) know what your devices know about your friends. And it is almost certain that you do not know how your apps are sharing this information with third parties.

If things go well in these relationships, then you receive the benefits. These benefits extend beyond just our interactions as your apps can provide an enhanced experience. In fact, these apps can enrich our interactions. Also, if things go well, then I am not negatively affected. I may not reap all the benefits you do, but I am none the worse for wear.

But what about when things go poorly? What happens when one of your apps or devices doesn’t respect my dignity and doesn’t treat information I have shared the same way you would have? You may receive some extra benefit, but I am negatively affected. This could include unwanted or unknown onward transfer for information about me. I could receive unwanted and unsolicited communications from app and device providers. I may also receive unwanted marketing.

In this case I cannot seek meaningful redress. You cannot change the situation if one of your apps mishandles information about me. Since you were not negatively affected, you cannot (and most probably would not) seek redress on my behalf from the app developer. And if you did seek redress from third parties on my behalf, any remediation they offered would likely be of little use to me. Also, I cannot approach the app developers and service providers because the asymmetry of relationships plays against me on a number of levels.

Worse still, I cannot sever my relationship with your apps. I can implore you to remove the offending app, but you likely receive enough benefit from it not to delete the app. I could sever my relationship with you, but I probably wouldn’t. Even if I did terminate our relationship, there’s no guarantee you’ll remove information from me the app and thus the asymmetric relationship between me and the app will continue on.

This is the new world we find ourselves in; there are strangers in our interactions. Apps are privy to information about us without our awareness. Our tried and true social and legal norms have yet to adapt.

In my next post, I’ll examine the desires of all parties involved in this new style of relationship.

Filed Under: News Tagged With: , , , ,

We are the disrobots

21 October 2010 by

Our technology and our society have reached a point where our privacy can be automatically impinged. We have fully automated disrobing ourselves. We have created the disrobot – a machine or process which automates the stripping away of the veil of privacy.

Consider the apps on your smartphone or social networking platform of choice. There are too many incidents to name in which app developers have acted badly. And it isn’t the app developers that are the only potential bad actors. The behavior of the platforms on which these apps run is suspect as well. The recent work by the Wall Street Journal on how app developers, either knowingly or not, have been leaking Facebook identifiers to advertising networks because of the way the Facebook Platform handles referrers is quite telling. But social network platforms aren’t the only ones – considering how communications providers have been using their platforms to infringe on customer’s privacy either through enabling eavesdropping or disclosure of location.

Disrobots don’t just exist in the internet and its infrastructure. Millimeter wave scanners at airports are disrobots; they come as close to disrobing you as the TSA can get without doing something like this.

But wait it gets worse – we are becoming disrobots as well. When you check-in to a location and mention someone else is with you – you are a disrobot. The apps that you so dearly love could very likely be disrobing your friends.  Our government is doing this as well. The story of Michael Roberts, the ExpressJet pilot who refused to submit to a millimeter wave scan and will likely be fired is a prime example of the government-as-disrobot. As Kraftwerk sang:

Ja tvoi sluga
Ja tvoi Rabotnik robotnik
- Kraftwerk – We are the Robots

One of the reasons that disrobots are so prevalent is that they have evolved faster than our social norms. If you do not respect information I’ve shared with you, I can seek redress from you and even go so far as to sever our relationship. But society doesn’t have a recognized set of norms in the case that an app you’ve installed doesn’t respect information I’ve shared with you. (Furthermore, I would be hard pressed to single out your app as the bad actor, but that’s another story for a different day.) Consider the feeling you get when someone tags you in a photo – is that different from the feeling you get when someone identifies you at location via a Foursquare or Facebook check-in?

The reality is the disrobots are here to stay. A combination of social norms and technology will be needed to keep them in their place. But unfortunately, in the name of profits and false hope of zero risk and total security, I see norms and technology being encouraged to help disrobots, not limit their behavior.

Cue German dystopian cinema…

 

Filed Under: News Tagged With: , , , , , , ,