On Aug 28, 2006, at 10:23 AM, Priscilla Chung wrote: On Aug 21, 2006, at 4:46 PM, Brian Moseley wrote: i don't have any problem with that as long as we also provide (eventually) for people who want better security (eg acl).
+1
I realize there is huge amount of development work to add ACLS before beta. I guess what I'm unclear about is how much ACL work is really needed for post beta and has anyone investigated how to phase this in?
I think figuring this out needs to be part of the planning work for Cosmo. As we mentioned during the sprint, we are planning Cosmo beyond Beta so this is something we will discuss. Step #1 starts tomorrow during our design session where we will be reviewing in detail the items on BCM's dev wish list. After having a better understanding of the mission and goals for the beta release, adding a password doesn't necessarily solve any additional issues. In fact, it adds development time (though it may be minimal it still adds some development time) and adds complexity and inconvenience to the user. For example, what happens when the users forgets their password? This happens frequently. How will they retrieve new one? Does the 'Sharee' have to keep pestering the 'Sharer' for the password if they keep losing the password?
As far as I understand the "sharee" would only need the password to actually subscribe to the collection. Once they have done that, they don't need it anymore so I think it's unlikely that they would have to keep pestering the sharer for it, unless they keep having to setup their shares again (but we will have that restore settings and shares feature). The "sharer" would get the password from the manage share dialog or something like that if they forget it.
If the longer term is to add in ACLs why not try to find a solution that brings us closer to the end goal? If the first option is a 'trust' model and that is part of the mission and goal of OSAF then my vote would just go to option 1.
If I could interject with another option which I'll name the 'accountability' option, it might work a little like this:
+ When a user wishes to publish a calendar they may require anyone who uses the calendar to sign up for a Cosmo account. This becomes a property of the calendar, independent of the tickets.
+ Tickets work pretty much the same as they do in the current 'trust' model with a notable exception
+ Upon clicking on a ticket to see a calendar, the user is presented with a dialog that says the calendar requires the user to sign up for a Cosmo account (i.e "this is a secure calendar, you will need an account to view").
I am not convinced this solution is on the path to ACLs anymore than the password one. When we have ACLs sharers will have to obtain specific usernames for people they want to give access to. I will know that it's Mimi editing my calendar because she gave me the account name "hamstar". I wouldn't be specifying that any random person with an account could access the share. I enter people individually and give them a particular privilege level. I would argue that there really isn't much accountability in the scenario you describe. Sure, we could probably turn off the account etc if we see that someone is modifying a calendar maliciously, but simply having a username and password on the server doesn't truly identify someone. I just setup an account on Cosmo, username=cooluser, full name = Cool User and some bogus email. I get a hold of your read write ticket and edit away. How do you know it's me or anyone else you trust to make changes to the calendar.
Reasons for this option --Pros + It's still keeps the original goal of the 'trust' community.
+ It introduces a notion of accountability when a calendar creator wants it
+ Users will create accounts because a sharer wants accountability, not because of a demand of the software.
+ This is a step in the ACL direction where users would be accountable and potentially need permission
+ The 'Sharee' would not have to store their collections in their e-mail - the account is a good way to access all of your subscriptions without having to keep all of the sharing tickets you received.
--Cons + You're not actually password protecting anything (yet), you're just setting the stage for it.
-Priscilla
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
|
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
