[Design] [Scooby] Anonymous access to read-write tickets and security concerns

[Brian Moseley]

On 7/11/06, Sheila Mooney <sheila at osafoundation.org> 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.