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

[Mimi Yin]

See in-line...

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

>> 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 think we've always imagined a more open collaboration model than  
this. A lot of the usage scenarios / workflows we've sketched out and  
storyboarded involve multiple people collaborating on a single item.  
(See: http://wiki.osafoundation.org/bin/view/Journal/ 
StampingStoryboards#StampingWorkflow)

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

I'm not sure I understand.

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

This is where the ability to shut off an individual ticket would help.

Even so, I'm not sure how many people Mitch would give read-write  
access to on his personal calendar. Which means that even if we  
didn't have per-sharee read-write tickets, if the share was  
compromised, it wouldn't be that much of a hassle to issue a new read- 
write ticket and have 2 sharees re-subscribe with the new ticket.

The scale of sharing we're talking about in the Beta timeframe is  
just very small.

It's one of those things where if you're a high stakes person, you  
make sure to be extra careful about these things. And if you're not a  
high stakes person, then why would anyone bother manually spamming  
you in the first place? It seems like in most scenarios, it wouldn't  
be worth anyone's time to spam shared collections unless it could be  
done in an automated way.

I'm not trying to discount the scenarios that are being brought up.  
They are legitimate and serious. I'm just wondering if we can get  
away with what we have in the beta timeframe because of the nature of  
the collaboration scenarios we're supporting.

===

On a related note, I'm starting to get confused with all the  
different 'spammy' things that could happen. I think there are 2-3  
very distinct scenarios and teasing them a part might help us figure  
out which scenarios are more or less likely in the Beta timeframe.

How unwanted data gets added to a shared collection where the read- 
write ticket has been compromised:

1. SPAM: Malicious or Commercial, Automated, Large-scale
2. Graffiti: Malicious, Manual, Small-scale

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