By dries on

Bill Humphries wrote:

    Frank Booseman would like blog tools to support walled garden posting. He's inspired when a friend would love to post photos from a party, but not to the whole world. Live Journal, which I've been playing with lately, supports this. It can, because it's a monolithic (on the server-side) application. I created a LJ account, and friends who were already there added me to their 'friends' list, and added them to mine. They post a private entry, and their friends see it, but not others.

Pete Prodoehl suggested to look at Drupal, to which Bill responded:

    Drupal's a nice system, but it doesn't do what I really want: I'd like a system which does not require the user to set up an account. I'd like to get a token in the request that says "I'm Jane User, and here's my assertation that I'm Jane User", and since Jane User is my friend and her assertation could be verified (though a public directory, or because someone I trust has signed her key), she gains access to the friends and family-only materials on the server without signing in. And, the key piece is that this may be the first time she's been on the site.
    Live Journal can do that because all the journals are part of the application, and I sign on once. Any LJ user can recognize me as their friend, and I get access to their friends-only materials.
    The godsawful piece is the public key infrastructure.

Which reminds me of this blog entry where Paul Bausch describes how he experimented with PGP-signed comments and how he think it would be a good way to verify identities. The talented folks behind MovableType picked up the tread saying that it could possibly be used to build a web-based verification service with a trust web.

As online communities (incl. the weblog community) continue to grow, and as more and more websites become interactive, identity theft might become a big enough problem that we'll want to deal with it. An interesting challenge for 2003?.

Comments

adamshand’s picture

adamshand commented

So he wants a web of trust, not to be a naysayer but so does the rest of the world and no ones managed to do anything useful yet. Then to make it harder he wants single sign on with this web of trust.

So this basically comes down to this:

  1. You need a accessible database of users
  2. You need a way for users to proove that they are in fact user XXX.
  3. You need a way for credentials to be automatically presented to get around the forced login.
  4. Each site needs an internal privacy/buddy/security system.

Live Journal does this fairly easily because it only works with Live Journal sites. They have access to the database of users and you have to login to proove it. However this isn't what I call a community friendly solution.

I'd say Drupal already has a better solution to part one and two, with it's distributed authentication system. Every enabled Drupal site is it's own realm (eg. drupal.org), and any account within any realm can login to any other site. The biggest part I don't like about this is that I'm typing my username/password into a site that I have no real reason to trust.

The hard part is the single sign on, and I think the only way to solve this is with client side certificates. However I think centralized CA's are doomed to fail, what need to do is to turn each Drupal site into a tiny CA. When you create an account Drupal generates a certificate for you (or possibly allows you to upload an existing one) and stores it as part of your profile, it also prompts you to load it into your browser if you so desire. Now when yo go to another Drupal site you automatically present your certificate (this is safe because there is no secret information within it) and if the site is capable it can verify your certificate against your realm (presumably some form of XML-RPC query back to the users home Drupal site).

The final item I would think would be the easist to actually implement, and I think taxonomy would be a great way to do it. Create a security taxonomy and you can list items as being accessuble to the public, only friends or completely private. Now we just need a way to keep track of friends, and couldn't that just be done as an interface to profile data?

Anyway ... my $0.02.

Adam.

amy-at-spiffariffic.com’s picture

amy-at-spiffariffic.com commented

I like your idea about using taxonomy to create different levels of access to content. The more I've been using drupal, the more I realize it didn't have the kind of privacy features I had come to expect. Basically an item is published or not, from what I can tell, or anonymous users have all access to content or none. I would prefer there to be some shades of grey, and taxonomy would be a great way to do it.

I'm not a real privacy freak. I'd like to have the ability to grant different user accounts different levels of access — I don't mind if they have to login, and if the person logs in with the right ID and password I'm not going to worry if it's really them or not.

I want to maintain an industry/what-i'm-doing-at-work blog AND one for a personal journal, and it'd be nice if there were an easier way to keep the two separate using the same codebase/server. What I'm going to do for now is do a user blog but not have a link to it by overriding the generation of links in conf.php.

amy-at-spiffariffic.com’s picture

amy-at-spiffariffic.com commented

http://www.spiffariffic.com/node.php?id=10

What do you guys think? Comments? Refinements?

adamshand’s picture

adamshand commented

Kinda rambling, it's late ...

Side note ... wouldn't it be cool if there was someway to post the content to your own Drupal, and then tell the content to replicate to another Drupal? Or have all your postings automatically replicate to your own site? I remember Dries talking about this a long time ago ... Only local images are allowed.

Anyway, back to the issue at hand. I think you're almost there. I'd say create a way for users to list the email addresses of friends (profile data, a new table, whatever ...). When a new friend tries to view content which is protected "friends only" they get a page which says:

This content is protected and only viewable by friends of XXXXX. Please enter your email address to be validated. You will be sent a URL in email shortly, please click on the link to be validated as a friend.

If the email address they enter is on the list it sends them an email saying "Click on the below link to get access to XXXXX's friends only content".

Now set your cookie and give them access.

If their email address wasn't listed, then the owner of the content gets notified that user@domain.com has requested access to their stuff and they can allow/deny the request. The user gets an email saying that they are currently unapproved and should get an email shortly.

One issue might be invalidating cookies. What if I'm using a friends computer or one at an internet cafe and don't want them to be able to view the content? Do you expire the cookie? It could get pretty annoying to enter in your email and then wait for an email everytime you go to the site.

You could maybe give them a persistant URL and tell them to bookmark it (http://drupal.org/validate/hashofemailetc).

I think in the end though this is a lot of work to go to avoid having people log into a site. People know how usernames/passwords work, they may be annoying etc but I think you may have more luck with a user/pass then with a new "easier" system that people aren't familiar with.

Adam.

amy-at-spiffariffic.com’s picture

amy-at-spiffariffic.com commented

Adam, what a killer idea I would love if the distributed authentication system they have now could extend to postings. The great thing about that is that the owner of the site could set up realms of access (there's that privileges stuff again) that would allow some site owners to always share their content based on user@site OR the entire site, and everyone else would get stuck in the unpublished-to-review queue. Comments would 'appear' to be the shared-with site, but would actually be housed on the original site only for organization's sake.

We could also tweak the ping technology so that the site 1 (eg: me) runs will notify site number 2 (eg: drupal.org) that the entry has changed and then site number 2 could grab the updated content. That way site 2 wouldn't have to load the data from site 1 every time, thereby increasing efficiency. Of course this would automatically happen if someone on site 2 read the article and submitted a comment from a link on site 2. Of course, this would be automatic once the person at site 1 submitted the content to be distributed, or controlled by a checkbox at most.

With regards to the authentication scheme I offered and your comments about its losing points, I agree with you. You're right, there are definitely issues with it. But as an alternative for people who don't want to make people log in (did you notice the original post for this node?), I don't think there's any other, better solution that's been proposed.

For those who have no issue with logins, such as myself, we could extend the scheme to the one-time-link-with-hash-code to be a one-time invitation to register, which would automatically stick that person in the right permissions group just like I described. And, to minimize hassle where it is security-appropriate (ie, not shared machines, etc. etc.), the cookie would be ultra-long life. Or, instead of that, depending on how paranoid the site owner is, invalidated after a certain period of inactivity on behalf of the permissioned visitor.

caseymaxwell’s picture

caseymaxwell commented

Iam looking for a good sculpting machine any one can suggest me?