[Design] [Scooby] Anonymous access to read-write tickets and
security concerns
Ashkan Soltani
ashkan at osafoundation.org
Tue Jul 11 14:37:51 PDT 2006
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
More information about the Design
mailing list