To describe the various projections of ourselves into cyberspace, I use the following metaphor: we’re cells, and we’re growing the surface area of our cellular membranes. Every time I write a blog item, or post a Flickr photo, or tag a resource in del.icio.us, I enlarge the surface area of that membrane. I do it for two reasons. First, because I want influence to flow from me to the world. Second, because I want influence to flow the other way too. I’m soliciting feedback and interaction.
I monitor that feedback using an array of sensors that works surprisingly well. All of the parts of my public membrane can be instrumented with RSS feeds. By tuning into those feeds, I know — fairly immediately and comprehensively — who has touched which parts of my exposed surface area.
What I can’t do very easily, though, is visualize that entire complex surface. If somebody reacts to something I published years ago on some site I’ve forgotten about, I’m reminded that part of my surface area extends to that site. But it’s only a reactive thing, there’s no proactive way to review the totality of my published corpus. That’d be handy.
It’d be even handier for the parts of my membrane that aren’t fully public. The lack of such a capability, in those cases, is what makes security so hard for people to manage.
For example, I’m still working through the implications of the calendar cross-publishing arrangement I’ve set up for myself. Consider my Outlook calendar. It’s shared within the company by virtue of a default policy that I can view, or modify, by right-clicking the calendar in Outlook and selecting Properties -> Permissions. But it’s also shared with my family by way of a private URL that I created on my WebDAV server and transmitted out-of-band. I can see that private URL by right-clicking and selecting Publish to Internet -> Change Publishing Options, but there’s no indication there of who I gave the private URL to.
This example is just one manifestation of a general problem that cuts across all systems and applications that enable people to selectively expose surface area. There’s no unified way to see and explore that surface area. You have to make a mental inventory of all of the bits that you’ve exposed, you have to individually review the scope of visibility for each bit, and then you have to synthesize a view of what’s visible from a variety of perspectives. Humans are lousy at this kind of thing, computers are good at it, but we haven’t figured out how to enlist the computers to help us to it.
We can at least dream about how a surface-area viewer would work. You’d point it at a blob representing you, and zoom in to resolve the various bits of exposed surface area. There’d be a viewer-impersonation knob that would start at Everyone but could be spun to any of the groups or individuals to which you’ve granted permissions using any of your diverse permission-granting services. You’d spin that knob from one setting to another, and fly around exploring who can cross various parts of the blob’s membrane and who can’t.
I know this would impractical for all sorts of reasons. But I still want it.
I have a similar problem with embargoed material that is hidden under a private URL until I link it into a public structure that search bots see and can follow, along with other curious characters and the intended audience.
I know this is only a piece of the problem. Like you, I rely on the privacy of the embargoed URL and trusting that no one plants a link to it in a visible web page, a blog or whatnot. If it was something I cared more about, I could watch the log reports to find out how the URL is being used (especially the referrer report).
If I were to do more, I would put a real server password on that embargoed section, already in a folder with a not-guessable name created using a password generator. Other than making things more difficult, I don’t think I have accomplished anything other than add a slightly-higher level of protection for something that there’s a mutual interest in keeping private.
It seems to me that giving out a password or a URL is workable but does not scale. I don’t think it is about passwords, I think it is about authorization. I would want to authorize the possessor of a particular certificate to access the material. Having a certificate and the (unknown to me) private key associated with it seems as strong as it gets for practical privacy agreements. Now only if the certificate is compromised, or I accepted the certificate of an imposter in the first place, is there a problem. But it is easy to revoke the access rights of that individual certificate once the compromise is known. This does mean that I would have to keep track of the specific certificates I had granted access to, but that would be good enough for the cases I have in mind.
So, it sounds like something like InfoCards (sorry, I can never remember the married name of that technology) with its easy self-generated certificates might be a reasonable way to set up a private realm shared by a modest number of participants.
Jon,
I recently went back to a couple of pages that had not been touched in years (my first weblogs, dating back to 1999) and inserted a little bit of tracking javascript to see where the hits were coming from. I hadn’t expected to have much traffic, but there is a steady background radiation of 15-30 hits a day on pages that haven’t been changed for a long time.
The “surface area” viewer I make the best use of at the moment is 103bees, a search log analysis tool. The embedded javascript relays the search engine query terms to a stats gatherer, which in turn collates results. Not perfect – you can’t embed it on Flickr, for instance, or on comments you leave – but mighty handy when it does work.
This seems related to the whole digital identity thing. Infocard lets me disclose different information by presenting different representations of my identity depending on the service I’m authenticating to. What you’re talking about seems like the same thing in reverse – progressive disclosure (with tracking) from “server” to “client” instead of Infocard’s “client” to “server” personna selection.
In both cases, the answer to “who are you?” depends on who’s asking. When I’m the server, I’d like to know who’s asking.
In the simple case of calendar sharing, a lower tech facet of this solution (as I just commented on one of your previous posts) is to share full calendar information with close contact and FreeBusy information with more distant contacts. That’s progressive disclosure for calendars, but it’s I have to control it by giving out different references to different types of calendar feeds, and (as you indicated), there’s no simple way to visualize what’s been shared with whom.
After research a couple of of the blog posts on your web site now, and I truly like your approach of blogging. I bookmarked it to my bookmark web site listing and can be checking again soon. Pls check out my web page as well and let me know what you think.
In both cases, the answer to “who are you?” depends on who’s asking. When I’m the server, I’d like to know who’s asking.