Mitch threw out some ideas about ways we could make sharing via tickets more secure without
1. Introducing full-fledged username/password accounts and/or 
2. Adding functionality in Chandler to send sharing invitations in-band

I followed up with a description of how what the workflows might look like.

Questions: How does this approach measure up in terms of addressing SPAM and Graffiti, as defined earlier in the thread?

On Jul 12, 2006, at 9:20 AM, Mitch Kapor wrote:

Some ideas:

- allow people to continue to publish calendars without additional security via the ticketing system.  Let additional security be a choice, not a requirement

- does it make any sense to allow people to attach a password to the calendar itself?  Probably not, but this idea should be examined.

- would it be ok to require people who want access to protected calendars to have an account on the hosted service?  Good question.  It could be ok, but of course not as desirable as not having the requirement.  Knotty.

Mitch


The optional password approach might work really well (at least from a workflow perspective), especially if it was bundled in the URLs that get copied to the clipboard. I believe pbwiki has something similar to this and it's worked well for me in the past (where I was a casual sharee not interested in creating an account).

The workflow would look something list this:

1. SharER checks an option '[x] Password-protect my share' in the 'Share' dialog when publishing to Cosmo.
2. Sharer chooses a single password for the share.
3. Sharer copies URLs + Password to the Clipboard
4. Out of band: Sharer pastes URLs + Password and sends it to ShareES. **

On the Sharee end, the password adds a little bit of extra work, however:
1. Sharees without accounts need to find the URL ticket in order to access the share anyway. When they find the email with the URL ticket, the password will be right there beside it.

2. We can add a 'Remember me' feature to Scooby so that if you've entered the password once, you don't have to remember it again.

** Doesn't require us to do much additional work in Chandler to store email addresses, manage ACLs or send sharing invitations from Chandler.

Mimi

_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design

Reply via email to