[cap-talk] Webkeys vs. the web, problem #2

Chip Morningstar chip at fudco.com
Sun Mar 22 19:06:13 EDT 2009

As I've been pondering this further, I've stubbed my toe on another, unrelated
design issue.

Suppose we have a notion of groups, in the sense of groups of people such as we
see with things like Yahoo! Groups or Google Groups or many social networking

I can have a webkey that gives me access to a group's page, presenting me with
various information and functionality.  Now suppose the information and
functionality available is different depending on whether or not I'm a member
of the group.  In principle, this seems easily achieved by having two different
webkeys, one leading to the public view of the group and the other to the
members' view of the group.

If I am a member of a group, I can follow a link to the group from my own
"groups that I am a member of" page and get to the members' view, and I can, of
course, bookmark this link as well.  (Actually, I imagine each member would get
their own personal members' view webkey, so that they could be individually
revocable if the need arose, but I don't think that changes anything
fundamental with respect to the issues I'm concerned about here.)

If I am not a member of the group, I might acquire a link to the public view
via some kind of search function or index, which is fine since the information
revealed in this manner is supposed to be public anyway.  And I can also
bookmark *this* link.

Now, if Naive Ned, as non-member, bookmarks the link to the public view, then,
at a later time, becomes a member, his bookmark still links to the public view.
Notwithstanding the fact that it is *possible* for him to get to the members'
view via a suitable navigation path, Ned is going to follow the link he has
bookmarked and be surprised that he can't see the stuff he thought he would
see, since he *is* a member after all, and he's going to call up customer
support and complain that it's broken, and this will ultimately lead to my boss
calling me up and sharply inquiring what the hell I was thinking, designing it
to work this way.

The issue here is that groups, representing collections of people, are in a
sense fundamentally identity-oriented abstractions.  While groups, in this
sense, may be a poor abstraction in general for access control, they seem like
a pretty good abstration for regulating access to themselves.  And in any
event, they are a pretty good abstraction for capturing the human relationships
between the members: when I communicate to a group (say, the cap-talk mailing
list), I am addressing the specific people who are members.  In this sense,
it's not really about access control except secondarily.

However, to get directly from the public view to the members' view would seem
to require some kind of under the hood slight of hand that feels very
non-capability like.

Another, related problem, is that if Ned is sitting at his browser staring at
the members' view and wants to tell a friend about the group, he is likely to
just grab the URL he's got and mail it off, thus leaking the members-only
authority to a non-member.  This might make him unpopular with the other
members.  I suppose we could handle this by wrapping things in a UI that never
presents the URL directly, but instead has a "give me a publishable URL to
this" widget that only gives out the public view, but this breaks

I don't see a graceful way out of this.  Anyone? Anyone? Bueller?


More information about the cap-talk mailing list