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

[Brian Moseley]

On 7/11/06, Jeremy Epstein <eggfree at pacbell.net> wrote:
> Hey all-- my comments below.
>
> you enter a list of emails to invite and chandler/scooby handles the rest:
> (1) it looks to match users to emails in the cosmo DB,
> (2) if matched "do the right thing"  if not, create a new account.
> username == email
> (3) send email to all these new users
> (4) when the new user gets to scooby and attempts a non-read action, we
> prompt for them to enter their email and password.-- we offer an
> affordance for new users to choose a password.
> All of this implies that chandler and scooby can do what every other app
> on the web does-- send automated emails.

this is not a bad idea. i feel a little uncomfortable about
autocreating accounts, but i can't back up the discomfort.

> part of this is colored by the notion of what it takes to set up an
> account, and assign permisions. Lets say for the sake of argument the
> following:
> 1) your username and email are the same

not true, for the reasons that sheila mentioned in a followup.

> 2) if there is no account match to an email, we implicitly create one --
> there is no sign up involved.

at some point (step 4 in your proposal), the new user will have to
choose a new username and password. there is no non-ticket way around
that.

> 3) we implicily assign very basic edit permissions to all invitees: "you
> can only edit or destroy events you create", "you can only accept or
> reject events you did not create". You do not need to have a user
> maintained infrastructure to set up these acls-- they are "built in" to
> the behavior of sharing and ownership.

that is also true, but it relies on the fact that people using scooby
to perform write operations have asserted their identity to cosmo, not
just presented a write ticket.

man i hate tickets! let's chuck em!

> >> 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 worry about how to explain the difference between 1 and 2 to users
> > in laymen terms. Secure sharing? Insecure sharing? Requires accounts
> > sharing? Doesn't require accounts sharing?
> >
> you dont have to.  The permissions you assign have everything to do with
> how you stamp events:
> "invitations" only allow "reply actions" for the invitees
> "meetings" may allow "accept" "reject" "tentative" and "schedule"
> if you are not on the list for an event you can only look at it. Maybe
> not even that.
> etc...
> that and the rule "you can never touch someone else's event" unless you
> are made an "owner" of the calendar.

again, that presumes the user is authenticated to the server, which
allows the server to make security decision based on knowledge of the
user's identity. not the case with tickets.

> or you scrape. IE "send to your friends"-- enter in you gmail username
> and password. WE scarpe the address book and present  emails to you to
> send invites to. (this is more common then you think)

... scrape what? there's no address book in either chandler or cosmo.
that's what i was saying.

> the same rules apply-- its actually likely that the spammer may attempt
> to penetrate the cosmo server as it uses a more well established
> protocol(calDAV).

yea.

> I'm drawing this from a current project involving some very consumer
> stuff(podcasting) where there is an effort to sign up members fast, yet
> still limit spam. The catch is in reducing the requirements for sign up
> to the bare minimum. Right now cosmo requires or appears to require six
> fields. it should only require one-- email. Cosmo can mail a generated
> password to the user email.

email is not sufficient identifying information. email addresses
change more frequently than do given names and surnames. the entire
point of usernames is to abstract identity away from such volatile
attributes as email address. a profile's unique identifier should
remain static even when any of the profile's attributes change.