Progressive Disclosure is another key concept in a model of privacy that builds on a social model.
In progressive disclosure, there is always something that you reveal, even if it is just your physical presence in the same room. This becomes the "authentication" that lets you decide if you wish to reveal more. Each progressive revelation leads to the possibility of further disclosure.
In order to enable progressive disclosure with an intimacy gradient, social spaces need windows that reveal whether someone is home, and doors that enable people to knock and gain entry.
The Public Directory of Socialtext Spaces is an early, social implementation of this concept. We're adding more in Socialtext 1.4. Watch this space.
from conversation between Adina Levin and Christopher Allen. Please join.
Edited from IM discussion with Adina:
Adina Levin: I think this is new stuff we are working on...
ChristopherRayAllen: It is not entirely new -- I've seen these type of discussions in old CSCW works from 80's and 90's, but they were all academic or pie-in-sky like Xanadu.
Christopher Allen: I've been talking about progressive disclosure for instance for over 12 years -- it is the reason why I chose SSL over competing standards in 1992, as it had progressive disclosure, and the others didn't. I felt that its trust model mapped better human trust, and that the market would decide how much "trust" was needed, and the market decided that it didn't need the ultimate trust of mutual authentication and perfect forward secrecy (which is possible with SSL, though no one uses it) and instead single authentication was good enough. Now it is the world's dominate
Adina Levin: yes, and there is opportunity to build practical tools supporting these concepts. need to engage with customers about how to sell it, since you always need to solve problems people know they have and, while cogniscenti have been thinking about progressive disclosure/intimacy gradient the conventional models are "playground" and "prison".
Christopher Allen: Agreed.
It turns out that my term of art "progressive disclosure" may have come from my work in the 1980's at Apple consulting for the Human Interface Group. So more commonly progressive disclosure is a term of art for hiding interface elements so that they don't intimidate the user.
My term of art "progressive disclosure" is similar, but more about how human trust works.
This is how I typically talk about progressive story at a conference:
You are now spending your most precious resource, the most unrenewable commodity -- time, in order to listen and understand what I have to say.
Why do you do so? Because by the act of us being here in this common space, at this conference, you have a very simple credential from me, that I'm willing to spend time here in a place that you are interested in. In turn, I'm willing to spend more time chatting with you for same reason.
Why do we continue to chat, and not move on to other people to discuss with? Because as we chat we are exchanging a number of credentials -- people we know in common, common interests, meaningful ideas, etc. We may also present credentials typically issued by others, like a business card.
As our unspoken agreement to continue discussing evolves, we typically will unconsiously check to see if others are listening, and adapt our conversation thereof. If the discussion becomes more personal or serious, we will find ourselves moving to a more private portion of the room.
As our discussions become more intimate, we may begin to speak of things that hint on a mutual respect for confidentiality. We will speak of people we've worked with positively.
If we agree to meet later to discuss more, before we meet again we may go authenticate some of the credentials given us. We'll not authenticate them all, only enough to substantiate to the level of assurance that we need for the risk we are taking (which may only be the loss due to wasted time, but it is a risk.) This authentication can consist simply of confirming information given, or as complex as asking for an endorsement from a mutual collegue.
As our collaboration grows, we will find ourselves seeking more and more credentials, endorsements, etc., but they will not be enough. The next level of trust can only be established by small things -- so we call back when we said we would? We find ways to test our trust, typically with small things at first, growing to larger things. At some point this may ultimately grow to form simple verbal contracts, then over time richer, deeper social contracts that might not be written down.
Ultimately may we bring in third parties to witness, and thus possibly enforce our mutual obligations, whether it is just having a mutual collegue view our handshake, friends see our kiss, or all the way up to having a legal, signed document.
At some point our mutual interests may be so large that we decide not just to collaborate, but to share assets, whether through a partnership, a corporation, or a marriage. Before this is complete there will be more credentials and authentication of those credentials (talk to former employees, credit checks, visit each other families, blood tests), endorsements, and less risky tests of the full contract (signing a term sheet, or an engagement).
This is the way human trust works. It also very similar to the way that groups work -- a corporation will collaborate with another corporation in the same way, starting with small trust, tests, and leading ultimately up to partnerships and mergers.
Computer trust rarely works the way that human trust does. It starts with mathematical proofs, that such and such is extremely difficult, thus something built on it must also be difficult. These are then built on top of each other until a system is created. It often seeks a "perfect trust" that is rarely required by human trust.
One of the reasons why I chose to back the nascent SSL (Secure Sockets Layer) Standard in 1992-3, was that I felt that it much better mapped to progressive disclosure and human trust then did its competitors. At the time SET not only required strong mutual authentication, but also multiple authencations. HTTPS required digital signatures, preferebly by both parties. But SSL starts out very simple -- first it simply connects two parties, then it establishes simple confidentiality. If one party wants more confidentiality, they can upgrade to a stronger algoritym. Then one party can request a credential from the other, or both can. Either party has the option to request authentication of those credentials. Ultimately you could use SSL come close to the trust that SET tried to establish, but the market decided that only one party needed to send a credential -- the merchant.
I believe that as we evolve social software to better serve our needs and the needs of the groups that we are involved in, we need to figure out how to apply an understanding of how human trust works.
Some Links on Progressive Disclosure as a user-interface design principle:
Interesting points.
Page Last Updated: Jan 7 7:28pm by George Sawyer