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

[Sheila Mooney]

On Jul 11, 2006, at 1:30 PM, Jeremy Epstein wrote:

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

Seems to me like we talked about this when I first started at OSAF  
and decided this wouldn't work well. I can't remember all the issue  
but I would like to get Lisa to chime in since most of these  
discussions were with her. We used to have a sharing invitation  
detail view where people entered email addresses and we ended up  
getting rid of that to do something really simple - 2 tickets.

A couple of things I remember...

1) People may have more than one email address. They might be using  
multiple email accounts in Chandler - I am right now.
2) What happens when people's email addresses change? How do I  
reconcile that with the account name I have setup
3) If I enter an email and it doesn't find an account match, it  
creates a new one. What if I already have an account but someone is  
using one of my other emails...now I have 2 accounts?
4) For this automatic account creation - how to we deal with passwords?

>
>
>>> 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
>
>
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>
> Open Source Applications Foundation "Design" mailing list
> http://lists.osafoundation.org/mailman/listinfo/design