On 7/11/06, Sheila Mooney <[EMAIL PROTECTED]> wrote:
+ They are not forced to sign up for an account - we don't know who they are when they make changes. The changes get logged but we don't have a username.
we don't even log the details of changes. we can see that an HTTP PUT took place, but we can't associate it with a specific difference in an item's content.
+ ACLs are a more common scenario to handle something like this but the current plan of record was to have ACLs for 1.0. From a PPD perspective,
you can't have acl without also having user login. acls are attached to specific user or group identities.
ACLs are also very complicated and there would still be significant work to figure out how to make this usable and doable in the current product timeline.
it really doesn't have to be that complicated.
+ There are some questions about how ACLs fit in with our "calendaring without IT" organization goals.
access control seem pretty fundamental to sharing. i can't imagine one without the other. we don't need the most flexible, general access control system. here's a strawman: 1) let me enter the cosmo usernames of people i want to give read or read/write or freebusy access to, and deny everybody else. 2) let me grant read or read/write tickets if i want to, understanding that anybody who gets their hands on the tickets can use them i know that as soon as somebody suggests entering usernames, there's a storm of objection that there should be a directory or addressbook that we can select usernames from. nah. i mean that would be cool, and maybe we could do it later on, but for now, let us just enter usernames. that's what the csg folks said a year ago, and it's still good enough for "calendaring without IT".
+ Should we consider per user tickets? How difficult is this. Are there
what does this mean?
other creative options ie: forcing anonymous users to decipher an alpha-numeric string from a garbled up image?
that's captcha, and it's used to separate humans from malicious programs. it's not a means of asserting identity to the server.
PPD Questions: + Is a ticket URL essentially a potential security hole, the way username/password is a potential security hole?
it's much more of one, because a ticket url is much more likely to be communicated in an email or web page that could be intercepted or harvested. people are pretty well trained to keep usernames and passwords private. not so with urls, even if they are "magic".
+ How would a spammer exploit that security hole? Do they create bots that scan websites for ticket URLs?
they certainly could, but spamming isn't the main threat. exposing the ticket to the general public is.
+ How do they figure out how to add content to Scooby once they've found an exposed ticket URL?
click the url and then use the scooby ui? :)
+ Do they need to know what protocol Scooby speaks and tailor the data they add to that protocol?
no, because the url will take them to the scooby calendar/event interface.
+ How does the ticket URL approach compare with public websites where the content is available for anyone to search through, navigate through and view?
publicly harvested data is, well, public. it doesn't have the same privacy issues that your personal calendar does.
+ Did Wikipedia have SPAM problems when they allowed anonymous edits?
i don't think that's relevant, for the reason above. _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ Open Source Applications Foundation "Design" mailing list http://lists.osafoundation.org/mailman/listinfo/design
