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

[Jeremy Epstein]

Hey all-- my comments below.
>
> So the proposal above would actually require something like this:
> 1. Email the people I want to share with and tell them to go create an 
> account on cosmo.
> 2. Ask them to please email me back with their usernames
> 3. Enter people's usernames into Chandler and assign ACLs to each 
> account (requires additional UI work)
> 4. Enter people's email addresses and fire off an email to invite them 
> to share and to point them to the share
>
no! no! no!  Imagine this:

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.


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
2) if there is no account match to an email, we implicitly create one -- 
there is no sign up involved.
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.


>> 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.

>>
>> 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".
>>
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)


>>> + Should we consider per user tickets? How difficult is this. Are there
>>
>> what does this mean?
>
> Each sharee gets a unique ticket that can be turned off if it is 
> compromised.
>
that is still the equivalent of making each user on windows an admin.
>
>>
>> they certainly could, but spamming isn't the main threat. exposing the
>> ticket to the general public is.
>>
+1 to that
>
> This was more of question for spamming. I'm not sure why an individual 
> would want to graffiti someone else's calendar manually.
>
Not necessarily graffiti. Imagine someone taking mitch's ticket and 
making a website ("pitch your idea to mitch" ), then submitting it to 
slashdot.



>>
>>> + 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.
>
> Sorry, this question was about automated spamming too.
>
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). 
> It seems like SPAM is undesirable for both public and private 
> information. My question was more about how serious a problem spamming 
> would be in the near-term. It seems like you don't feel like it will 
> be a major problem?
>
Ask that the next time OSAF gets slashdotted.



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.

Jeremy