The cloud ate my homework

In mid-August I got an email athat made me do a real double-take.  The subject line read:  Legacy Service End of Life – Action Required. 

Action Required:

Legacy Service End of Life

Dear Kim,

We’ve been analyzing customer usage of Joyent’s systems and noticed that you are one of the few customers that are still on our early products and have not migrated to our new platform, the Joyent Cloud.

For many business reasons, including infrastructure performance, service quality and manageability, these early products are nearing their End of Life. We plan to sunset these services on October 31, 2012 and we’d like to walk you through a few options.

We understand this might be an inconvenience for you, but we have a plan and options to make this transition as easy as possible.  We’ve been developing more functionality on our new cloud infrastructure, the Joyent Cloud, for our customers who care about performance, resiliency and security.  Now’s the time to take advantage of all the new capabilities you don’t have today. Everyone that’s moved to our new cloud infrastructure has been pleased with the results.

As a new user to the Joyent Cloud, you are eligible to take advantage of Joyent Cloud’s 30-Day Free Trial using this promotional code… [etc. – Kim]


Jason Hoffman
Founder and CTO

Of course I spend a lot of my time thinking about the cloud: people who’ve heard me speak recently know that I’ve increasingly become a zealot about the new capabilities it opens up, the API economy and all that..

So I suppose that getting a pail of cold salt water thrown in my face by joyent was probably a good thing!  Imagine telling customers their infrastructure will be shut down within three months in an “action required” email!

We understand this might be an inconvenience for you.

Or even more surrealistic, after the hurricane,

We want you to take the time you need to focus on your personal safety, so we are extending the migration deadline from October 31, 2012 to the end of day Wednesday, November 7, 2012.

By the way, don’t think I was using a free service or an unreasonably priced plan.  I had been on a joyent “dedicated accelerator” for many years with an upgraded support plan – on which I only ever made a single call.  This site was the very one that was breached due to a wordpress cross-site scipting bug as described here [note that my view of Joyent as a professional outfit has completely changed in light of the 2 month fork-lift ultimatum they have sent our way].

Anyway, to make a long and illuminating story short, I’ve decided to leave joyent in the dust and move towards something more professionally run.  Joyent served up what has to be one of the nightmare cloud scenarios – the kind that can only give the cloud a bad name.  Note to self:  Read fine print on service end-of-lfe.  Tell customers to do same.

Meanwhile, I’ve taken advantage of the platform change to move to the latest version of wordpress.  This meant paying the price for all the modifications to wordpress I had made over the years to experiment with InfoCards, OpenID, U-Prove, SAML, WS-Trust and the like on a non-Microsoft platform.

So friends, please bear with me while I get through this – with a major goal of keeping all the history of the site intact.  There are still “major kinks” I’m working out – including dealing with the picture in the theme, re-enabling comments and porting the old category system to the new wordpress mechanisms [categories now work – Kim].  None the less if you see things that remain broken please email me or contact me by twitter or linkedin.

OK – I now “throw the big DNS switch in the sky” and take you over to the new version of Identityblog.

Information Card Thermometer

I’ve started publishing a “sockets guage” on my homepage – a thermometer that represents my best estimate of the percentage of desktops running Information Card bits (and thus capable of using Information Cards).  As of October, 2007, this is just over 10.2%. 

I’ll try to update this estimate monthly, working with others so our estimates are across Windows, Macs and Linux Desktops. 

It will be interesting to watch developments as this percentage moves up to 30% and then to 60% and then to 90%, each with  potentially greater network effects. 

Today we are in the “Sockets and Ecology” phase where we can see:

  • CardSpace and DigitalMe and other Card Selector sockets growing towards a tipping point
  • software for building relying parties becoming widely available and understood on all platforms and in all languages
  • the early versions of the software put out by Microsoft and others being refined and perfected through community feedback and experience
  • leading applications raising the competitive bar by adopting the technology

Our view is that as these phenomena accelerate, CardSpace and its sister implementations will be increasingly used across many different contexts and their ability to support minimal disclosure and prevent the use of universal identifiers will become increasingly valued and apparent.


This blog is about building a multi-centered system of digital identity that its users control.  All kinds of things pass themselves off as “digital identity”, so I want to start by pruning enough trees that we can see a forest.

Basic ideas

In these pages, I'll make it clear that digital identity can't be confused with “a unique identifier” like an SSN or a biometric like DNA.  In fact, digital identity can often just convey that you are a member of some group, or possess some characteristic (for example, your profession, employer, citizenship, role or age).  Similarly, it can indicate that you are the same person who visited a site previously – without conveying any personally identifying information.

In other words, digital identity has a complex relationship with flesh-and-blood identity, which I'll call natural identity.  Sometimes we want digital identity to correspond to natural identity, and sometimes we want the two to be isolated, or the knowledge of the connection to be highly controlled.  This has become necessary because the digital world has its own “physics” that is quite different from that of the natural world.  Here space becomes more or less irrelavent and isolation very difficult to achieve, while “now” extends through great slices of time.  The result is not only that our friends and loved ones are closer:  so is every actor, good and bad, and every monitoring device in the world.

This leads us to conclude that digital identity must embrace both being public and being private.  It must provide both anonymity and pseudonymity.  It must embrace being public and being private.  It always exists in a context, and we expect the context to have the same degree of separation we are used to in the natural world, even though space and time no longer serve as insulation.

I'm interested in history and philosophy, and realize philosophers have had much to say about identity, but don't discuss these issues on this blog.  I stick to matters of technology, with the express goal of creating a digital world in which none of the richness of our natural world is lost, so that everything that can be expressed there can be expressed digitally.

A matter of urgency

The Internet was built without a way to know who and what you are connecting to. This limits what we can do with it and exposes us to growing dangers. If we do nothing, we will face rapidly proliferating episodes of theft and deception that will cumulatively erode public trust in the Internet.

As a result, I have undertaken a project to develop a formal understanding of the dynamics causing digital identity systems to succeed or fail in various contexts, expressed as the Laws of Identity. Taken together, these laws define a unifying identity metasystem that can offer the Internet the identity layer it so obviously requires.  They also provide a way for people new to the identity discussion to understand its central issues.  This lets them actively join in, rather than everyone having to restart the whole discussion from scratch.

Those of us who work on or with identity systems need to obey the Laws of Identity.  Otherwise, we create a wake of reinforcing side-effects that eventually undermine all resulting technology.  The result is similar to what would happen if civil engineers were to flaunt the law of gravity. By following them we can build a unifying identity metasystem that is widely accepted and enduring.

Reading these Laws will give you the introduction you need to understand the rest of this site.  They are available in five formats:

Browser versionPrintable PDF.  WordDIDW powerpoint

If you can't read the paper, you can look at  the laws in point form – as long as you promise to remember that you won't understand what I'm saying without returning to the paper when you have time.

Identityblog Privacy Policy

This notice is the entire privacy notice for the site at which is solely owned and operated by Kim Cameron.

Personal information usage and storage 

  • In order to leave comments on the blog, I will ask you to log in and provide personal information (possibly via the intermediary of your social network provider if you reuse an existing social identity): a first name, last name, a ‘display name’ and an email address.
  • I don’t require that your first name, last name, or display name correspond to your natural identity. However you must be able to prove you can access to your working email address.
  • Each time you authenticate, I also employ a personal identifier – a random number used only at and created by your identity provider or our identity management system that I associate with you.
  • This information is stored in a WordPress mySQL database and protected by our identity management system.
  • The display name is retrieved from our database to identify your comments.
  • The email address is used as an anchor in case you are unable to authenticate to your identity provider: by proving ownership of the address you can register with another identity provider.

No combining or revealing of information

  • The information I collect will not be combined with information obtained from other services and companies.
  • The information will not be revealed to other companies or organizations under any circumstances unless I am legally required to do so.

No persistant cookies or tracking of your reading 

  • If you do not authenticate by using our identity management system, no cookie is generated and no tracking is done.
  • When you authenticate using our identity management system (and possibly a social networking provider), I create a session cookie to give you a better experience when leaving comments.  The time and IP address of your authentication may be stored in an audit database so we can aggregate the data and graph Identityblog usage.  No other tracking is done.
  • The cookie is not reused between sessions.
  • Under no circumstances do I track which postings you have read or searches you have done.


  • You will never be sent an email except a) to prove possession of your email address during registration or b) to reconnect you with identityblog in case of technical or operational issues… I assure you that you will never be sent a ‘reconnection’ message more than once in any three year period.

Updating your personal information

  • To change your personal information, please use the ‘Update Profile’ link after you log in. The system will be updated automatically.

This is a personal blog and my goal here is to convey why and how I am using (and will use) any information I ask you to provide. If you have other questions I should answer or comments on my policy, please let me know.

Evolving technology for better privacy

Let's continue to explore linking, and of how it relates to CardSpace, identity protocols, token formats and cryptography.

I've summarized a number of thoughts in the following diagram, which contrasts the linking threats posed by a number of technology combinations. The diagram presents these technologies on an ordinal scale ranging from the most dangerous to the least – along the axis of linkage prevention.

X.509 with OCSP

Let's begin with Public Key Infrastructure (PKI) technology employed with X.509 user certificates.

Here the user has a key only she can “exercise”, and some Certificate Authority (CA) mints a long-lived certificate binding her key to her name, organization, country and the like. When the user visits a relying party who trusts the CA, she presents the certificate and exercises the key – typically by using it to sign a challenge created by the relying party.

In many cases, in addition to binding the key to attributes,  the CA exists with the explicit mission of linking it to a “natural person” (in the sense of an identifiable person in the physical world).  However, for now we'll leave the meaning of assertions aside and look only at how the technology itself impacts privacy.

Since the user presents the same long-lived certificate to every relying party who trusts the CA, the certificate and the information in it link the user accross sessions on one web site, and between one web site and another. Any two web sites obtaining this kind of certificate can compare notes and determine that the same user has visited each of them. This allows linkage of their profiles into a super-dossier (possibly including a super-dossier of a natural person).

What is good about X.509 is that if a relying party does not collude, the CA has no visibility onto the fact that a given user has visited it (we will see that in some other systems such visibility is unavoidable). But a relying party could at any point decide to collude with the CA (assuming the CA actually accepts such information, which may be a breach of policy).  This might result in the transfer of information in either direction beyond that contained in the certificate itself.

So in the diagram, I express this through two risks of collusion. The first is between any two relying parties who receive the same certificate. The second is between any relying party and the certificate authority. In esssence, then, all participating parties can collude with any other party, so this represents one of the worst possible technology alternatives if privacy is your goal.

In light of this it makes sense that X.509 has been successful as a technology for public entities like corporate web sites, where correlation is actually a good thing, but not for individual identification where privacy is part of the equation.

(Continues tomorrow…).

More on the iTunes approach to privacy

Reading more about Apple's decision to insert user's names and email addresses in the songs they download from iTunes, I came across some related information in an excellent Macworld article by Rob Griffiths:

Yesterday, Apple’s iTunes 6.0.2 update was released, and offered these features, according to the Read Me:

iTunes 6.0.2 includes stability and performance improvements over iTunes 6.0.1.

What it also offered, but didn’t bother to disclose, was the addition of a bit of potential spyware to the iTunes interface. As reported originally on, and then followed-up on boingboing and other sites, the new iTunes MiniStore, which appears directly below the song list area in the main iTunes window, watches what you click on in iTunes and sends that information across the Web to a remote server. When you double-click a song to play in your Library or playlists, the display in the mini-store changes to reflect ‘matches’ based on what’s been selected, as seen below.

In order to do this, the music store must obviously know what you’re listening to. It learns this information via a packet of information sent each time you play a song via a double-click. This data is sent without your explicit permission, and as far as I can tell, there are no Apple privacy policies that cover that transfer of information. It’s also unclear exactly what data is being sent. (Is it just song and title? Or does it include your Apple music store ID, which would tie the song info directly to your personal data?) And although Apple now assures us that the data is not collected, that information is not made clear to users when they begin using iTunes.

The MiniStore can be easily disabled—just hit Shift-Command-M, or choose Edit: Hide MiniStore, and it’s gone. Once hidden, no more data is transmitted, as confirmed by Kirk McElhearn using the Unix program tcpdump, which watches traffic sent over your network connection. Disable the MiniStore, and your private listening habits will stay just that—private.

However, this isn’t about the MiniStore itself. It’s about Apple’s attitude in rolling this change out to the millions of iTunes users, without as much as a peep about what’s going on behind the scenes. Consider, for example, if Microsoft had done such a thing with a minor Office update—say they started collecting data on the names of the files you were editing, in the hopes of selling you preformatted templates to help with future similar projects. If they did this in a minor update, and without telling anyone that the data were being transmitted, there would be universal outrage over this potential attack on our privacy. And now Apple’s gone and done basically the exact same thing.

Personally, I am quite upset with Apple’s decision-making in this case, and I hope others are as well.

No company, even one I admire as much as Apple (I did spend nearly five years of my life working there), should start transmitting personal data over the Internet without my explicit permission and a clear explanation of how it’s being used. In addition, if a company is collecting this information, I have a right to know exactly what’s being collected, and what the company plans on doing with my personal information.

The good news is, Apple tells us that the information is not actually being collected. The data sent is used to update the MiniStore and then discarded. If you think about it, this makes sense—imagine the size of the data files they would accumulate with millions of users and what must be hundreds of millions of songs played each day. But Apple should tell us as much, so that we can all relax a bit about sharing our listening habits with Apple.

Apple should amend iTunes to clearly disclose what data the program is transmitting and how it’s being used. There should be a dialog box that pops up the first time iTunes runs, explaining exactly how the MiniStore works. If Apple had just included that yesterday — or even some information in the Read Me, then I wouldn’t have even raised this as an issue. A little transparency and openness can go a long way to easing privacy fears.

As interesting as the article are the 166 comments on it. About half seem to think it's fine for Apple to collect the information without consent. Oops. I shouldn't have said “collect” – or at least that's Apple's spin on this. It seems that even though the information is sent in (through a third party), Apple doesn't actually “collect” it, since it discards the information after “processing it”. So “collect” seems to mean “retain in raw form.” The iTune supporters make it clear they “don't think” Apple would use the information to create a profile of their tastes. Customer loyalty is a beautiful thing. This is the stuff that great ads are made of.

Leaving a comment

Information Card Selectors are the digital equivalent of a wallet to hold your cards.  Digital Me and Azigo produce selectors that run not only WIndows but on Mac and Linux.  (Unfortunately I don't yet have working links for some other offerings that I've seen.)

Selector Windows XP Windows Vista Macintosh OS X Linux
Digital Me Yes (Firefox) Yes (Firefox) Yes Yes SUSE
Azigo Yes (Explorer, Firefox) Yes (Explorer, Firefox) Yes (Firefox)

On XP, you can also run the same version of CardSpace used on Vista:

1. If CardSpace is not installed (as will be the case on XP), when you click on the Information Card logo or LOG IN link on my home page, you will see this:

2. No problem.  Just click the .NET Framework Runtime 3.0 and get the download happening.   Go out for a coffee.  Or even a Martini.

3. Next you'll need to do the usual license approval, and the real installation will start.  Hint:  go do some instant messaging or work on something else for a while.  It takes a while but costs you nothing!

4.  Go back and follow the instructions for Vista.

Details of firefox bug

From: Chuck Mortimore
Sent: Tuesday, March 06, 2007 5:50 PM
To: Pamela Dingle
Cc: Eric Norman; Neil Macehiter; Kim Cameron
Subject: Re: Figured out the xmldap/firefox issue

Weird….Sorry I've been quiet – very busy at work these days.

– cmortOn 3/6/07, Pamela Dingle wrote:Ha, I figured it out.Since you said that nothing had changed on your box since when it
started working and when it didn't, I started going through my software
update logs.  Nothing there. But then I went to
and checked
release dates there.Turns out Firefox came out on Feb 23.  At some point you must
have updated, and things started failing.  To prove this, I just
downgraded to FF — and presto, Chuck's plugin works.  So the
issue is an incompatibility between FF and xmldap 0.8.6.I'm going to blog this ASAP so people know what is going on…  thanks
for twigging me onto the right path Eric, I'm so glad I can finally
explain what's going on!



Eric Norman wrote:
> On Mar 6, 2007, at 2:57 PM, Neil Macehiter wrote:
>> All
>> My results are totally consistent with Pam's. I am unable to login to
>> either Kim's identityblog or Chuck's Java relying party using XMLDAP
>> (version 0.8.6) on Mac OS X 10.4.8 (PowerPC) with Firefox
. I
>> have JRE 5 installed.
>> Interestingly, on the 2nd March I was able to login to Kim's
>> identityblog using XMLDAP (and I am pretty sure I was also able to
>> login to the Java Relying Party but I can't swear on it).
>> I am encountering no such problems on Windows.
> Here's some observations from me that might lead to a clue about Firefox
> on a Macintosh.  Then again, they might not.
> With Firefox on a Macintosh, there's an extra icon under preferences
> called “Identity Selector”.  You have 2 choices: Microsoft CardSpace or
> XMLDAP.  I have always set it to XMLDAP.  I have no idea what the
> purpose of this preference is or why it's even offering me a choice
> about Microsoft.  But anyway, I tried them both.  As near as I can tell,
> it doesn't make any difference.
> The only reason I'm mentioning this is that it is something would be
> different between Firefox and Windows and on Macintosh.
> When I get to the page with the “Invoke Identity Selector” button,
> I get two buttons.  The source for the page says there should only
> be one — see attachments 1 (.tiff) and 2 (source).  So I think that
> the <OBJECT> element is messing up the rendering.
> If I click on the upper button, I get an identity selector and don't
> see the error until I select and send a card.  If I click on the
> lower button, I get an error immediately.  And it's a different error
> page that says code = EMPTYTOKEN.
> However, I sure don't think I saw the double button Sunday when
> this used to work at KIm's blog (but maybe I did and just don't
> remember).  Anyway, this sure is curious.
> Eric
> ————————————————————————
> <!DOCTYPE html PUBLIC “-//W3C//DTD XHTML 1.0 Transitional//EN” “ “>
>       <html xmlns=”“>
>               <head>
>                       <meta http-equiv=”Content-Type” content=”text/html; charset=UTF-8″ />
>                       <title>Information Card Invocation</title>
>               </head>
>               <body>
> This site is under maintenance – anything is possible<br/>
> <br/>This page contains the hidden form object that specifies required and optional claims, and invokes the Identity Selector.<br/>
> View the page source to see the object.<br/>
> Net Agent: septemberAgent
> User agent string:<br/><br/><pre>Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv: Gecko/20070219 Firefox/</pre><br/>                         <form name=”ctl00″ id=”ctl00″ method=”post” action=”“>
>                                       <OBJECT type=”application/x-informationCard” name=”xmlToken”>
>                                       <PARAM  Name=”tokenType” Value=”urn:oasis:names:tc:SAML:1.0:assertion”/>
>                                       <PARAM  Name=”requiredClaims” Value=”“/>
>                                       </OBJECT>
> <br/>No clickback detected<br/>
>               <input type=”submit” value=”Invoke Identity Selector”/>
>   </form>
> </body>
> </html>
> ————————————————————————