Since Sheila sent out this email, we've slightly altered the design proposal. Instead of using the ticket as a password, we've decided to give the user an option to add password-protection.

Proposed workflows

Option 1: No password protection (Same as Today)
+ Publish collection
+ Copy URLs to clipboard (Read-only and Read-Write tickets)
+ Send tickets to sharees in some out-of-band way (email, IM)
+ Sharees click on ticket to access share in Cosmo UI

Option 2: Add password protection
+ Publish collection
+ Check option to 'Add password protection'
+ Type a password into a field
+ Confirm password
+ Copy URLs (tickets) and password to clipboard
+ Send tickets + password to sharees in some out-of-band way (email, IM)
+ Sharees click on tickets to access share in Cosmo UI
+ Sharees must type in the password in order to view / edit the share (depending on the ticket)

Our rationale: From an implementation standpoint, it is redundant to require both a ticket and a password, we decided on this proposal for the following reasons:
+ We want the password to be optional
+ However, we don't want users to pass around plain English  URLs that would be dead simple for everyone to hack (e.g. osaf.us/bcm/work)
+ Machine-generated tickets are better used as a URL, something the user clicks on
+ On the other hand, passwords will be more user-friendly if they are user-defined (more likely to be something the sharee can remember, at least remember for long enough to type it into a password field to access the Cosmo UI.)

We brought this up last week at the Cosmo Sprint and there seemed to be some concern about the proposal. I am throwing this on the list now to invite more discussion.

On Jul 28, 2006, at 1:43 PM, Sheila Mooney wrote:

+ WHERE WE ARE NOW & NEXT ACTIONS:

+ There seems to be general agreement that we need some security model/privileges in order to accommodate all potential users in the long-term.
+ We need to be able to support additional security as a choice but not a requirement for all users.
+ There is acknowledgment that going with forced security or none in the short-term will be a barrier for some people.
+ There is some suggestion that tickets are not appropriate for the long-term.
+ We don't yet know the cost of any of the proposals that were presented.
+ Spelling out the target user group and their needs in more detail will help us figure out the right solution for the short-term and the long-term.
+ There are definitely some options in the short-term (Beta), that would meet the design requirements and enhance the security for users.
+ The design and dev teams will continue to explore the optimal solution to put in place for 1.0.
+ The design team would also like to do a LAST CALL on the idea of using the tickets as a password as a proposal for Beta.







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

Open Source Applications Foundation "Design" mailing list

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

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

Reply via email to