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

[Mimi Yin]

Ashkan's proposal #1 has the added benefit of allowing us to track  
who changed what on shared collection edited by users without a cosmo  
account.

This would necessitate bringing back the Sharing detail view and  
sharing invitation workflows.

We could have 2 simple fields for ACLs:

From: Sharer
Read-write: [Enter email addresses]
Read-only: [Enter email addresses]

Sharers can assign access controls to email addresses and send  
sharing invitations directly from the Chandler desktop client.

Mimi

On Jul 11, 2006, at 2:37 PM, Ashkan Soltani wrote:

> How about these two possible scenarios as cheap/easy workaround to  
> get a small amount of security around the system without requiring  
> full signup/login:
>
> =================================================
> 1) Use the recipient's email address as a 'barrier' to get read/ 
> write access.
>
> + Person creates a calendar
> + They specify a list of email addresses they want to 'share' the  
> calendar with/have write access to
> + Scooby/Cosmo notify's those email addresses that they can view/ 
> import this calendar
> ....
> + When a user, who is NOT currently logged on/approved to make  
> changes tries to make changes to the calendar, Scooby/Cosmo asks them
> to either
>    > 'log in' using their existing username/password if they have one
>    >  or to simply "enter the email address that this calendar was  
> mailed to"
> + Scooby/Cosmo will then try to match the email address to the ones  
> specified by the calendar creator or try again.
>
> *** This is a lower security model, but it just acts as a basic  
> hurdle to prevent calendar's from getting 'out into the wild' if a  
> recipient accidentally posts the calendar url somewhere public.   
> The idea is that the URL is useless without knowing who it was sent  
> to, kind of like not being able to just use a credit card number on  
> the phone without knowing the name it was issued to.
>
> =================================================
> 2) Allow calendar creator to 'approve' changes made to the calendar
> + Person creates a calendar
> + They specify a lists of email addresses they want to 'share' the  
> calendar with/have write access to
> + They also have the option of checking a checkbox that reads  
> 'Approval is required for anonymous changes to the calendar'
> ...
> + When a user, who is NOT currently logged on/approved to make  
> changes tries to make changes to a calendar for which 'Approval' is  
> required, Scooby/Cosmo gives them the option to either
>    >  create an account/login
>    >  or just post their changes anonymously pending approval by  
> the calendar owner
>
>  + If approval was initially required, the calendar creator then  
> gets emails from Scooby/Cosmo requesting that the following changes  
> made by the anonymous user to be approved.
>
> *** This is more work for the calendar creator and doesn't work  
> well in scenarios where he/she is not involved in managing the  
> calendar, however its a checkbox that can be toggled for those  
> people choosing to not have any security restrictions on their  
> calendar.  (i.e some people can opt to leave their front door  
> unlocked/others can prefer to lock it)
>
>
>
> Thoughts?
> -a
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> On Jul 11, 2006, at 2:02 PM, Sheila Mooney wrote:
>
>>
>> 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
>>
>> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>>
>> Open Source Applications Foundation "Design" mailing list
>> http://lists.osafoundation.org/mailman/listinfo/design
>
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>
> Open Source Applications Foundation "Design" mailing list
> http://lists.osafoundation.org/mailman/listinfo/design