dessalles

In his 2007 year-end wrap up, Matt Webb lays out a scenario for some social-software better served by a sign-in system that doesn’t rely on the standard username and password pair:

9
[...] The challenge I was thinking about was this: how would you design a sign-in system for a book club? Having them share a username and password doesn’t seem elegant somehow: although the information they keep online they want to keep in common, in the meat world telling one person a username and password doesn’t guarantee that knowledge passes to others in the group. So is there knowledge they do hold in common?

Perhaps the login system could be based around questions: ‘what is a name of a blonde person in your group?’ And let’s say, to sign in, you answer three questions: two which are known by the system and one which isn’t. The one which isn’t known is asked several times and the answers correlated. This becomes another known fact the system can use in the official part of the sign-in process. The problem I see here is that people from outside the group could also sign in, and this is also the problem with traditional passwords: with my weblog, it’s not the random stranger I want to prevent logging in–it’s the potentially malicious people I might meet, who are the people most likely to guess my password (except that I use a strong password, but you get my drift).

It’s an interesting concept - one that reminds me of the US Department of Motor Vehicles’ method for proving identity. Point values are assigned to different documents based on how authoritative they are as proofs of identity - a passport is 4 points whereas a high-school diploma is only 1 point. So a specific transaction requires a specific point total (e.g. 6 points to renew a driver’s license), and it’s up to the applicant to provide a collection of documents that add up to the required number of points. If we extend the DMV’s system to online sign-in, in addition to accepting a username and password, we might also accept other weaker forms of identification such as an IP address, user agent, a multiple choice question about the last action you took on the site or the title of the last book read by the club.

But I don’t think an sign-in system that relies on shared knowledge really solves the challenge set forth. As pointed out in the excerpt above, the whole point of sign-in systems is keeping people out. Embedded in the scenario above is the assumption that the book club’s members-only area can be found by someone without prior knowledge of it. How did this person find the way in to begin with? The challenge I’m thinking about is this: How would you design software for a book club with a public-facing space that’s in no way visibly attached to the private, members-only space? This problem can probably be reduced to a technical one, so I’m not going to attempt to answer it. But again, solving this problem only partially addresses the challenge of developing group-software that doesn’t require login. There’s a second, more important question we still need to answer: Why is anyone even looking for the way in to begin with?

I don’t have an answer to that question either. But there’ s an approach that might not require us to even know the answer. Nate Combs explained the concept wonderfully in a post on Terra Nova a couple years ago:

[…] The question starts with, should access to a system and its resources be identity based or authorization based?

Simplistically, an identity based scheme might be to have Joe Public validate his identity (register/ password) and grant him privileges/roles based on a confirmation of his identity (to the limit of risk imposed by hacking, malware, etc). An authorization based scheme instead might focus on managing Joe Public’s actions: what is he allowed to do it and when. […]

In the end, however, were this debate extended beyond design and engineering practicalities (e.g. scalability) it would likely come to this. Is it more important to worry about who you are versus what you are allowed to do? On the surface this sounds enigmatic: what if who you are determines what you are allowed to do. But there is a distinction: if I am better able to control what you are able do, I may be less interested in who you are. Or by way of an extreme example, if you can’t trash my world, sure, I’ll let you log in anonymously.

In my professional work for various cable providers and electronics manufacturers, the question of managing multiple-users on a shared information appliance like a set-top box or television set keeps cropping up time and time again. A typical design challenge from a client goes something like: we want to track what users watch so we can offer content recommendations (a la Amazon), but don’t want to require family members to login to the television every time they turn it on. Totally understandable. The best solution I’ve identified to this problem is switching to a permissions based system. If the recommendations are sufficient motivation for users to manage what’s saved to their profile, we can let anyone use any profile they wish and instead protect the ability to remove content from a specific profile. Put more abstractly, we only need to protect destructive actions - e.g. deleting or overwriting data. Interestingly, Matt explores a similar concept in the very same post:

4
I mentioned refactoring earlier, so an additional point on that: I have a feeling that refactoring code is not a good thing. I am not in favour of deleting code. If there are problems with code the way it is written, there should be mechanisms to code over it gradually, and leave the old code there. If it becomes too complicated, we need more convenience functions and not less. A codebase should be its own source repository: seeing what the code was like a year ago shouldn’t be a check-out from source control, but archeology.

“Archeology”, exactly.

So what have we got after all this? A book club with a private, members-only space that isn’t indexed by any search engines and isn’t directly attached to any public-facing spaces - making it difficult for non-members to find. The private space doesn’t require login to enter, but instead requires a varying number of identification points for different actions (publishing and overwriting content). The application itself is designed so that no malevolent behavior isn’t extremely easy to reverse since nothing is ever truly deleted, just “buried”. And the public space displays content securely and pseudo-anonymously pushed to it from the private space - maybe the same way spammers flood your email inbox. Complicated, and all speculation, but it might work.