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

[Mimi Yin]

Absolutely. There will always be people who will not be comfortable  
with the way we're doing sharing.

How much effort we're going to expend in the Beta timeframe to make  
everyone comfortable with sharing is partially a target user issue  
and partially a personal choice thing that is independent of the  
whole target user exercise.

For some people, it won't matter what 'role' they play in their  
organization. It doesn't matter if their organization is a small  
group, a large enterprise or the government. They won't share without  
user accounts.

Nevertheless, there are a handful of 'target user' considerations to  
take into account.
+ If you really, really, really, really, really need to share your  
calendar. (e.g. you're Mitch) Then you might put up with the security  
risk in order to make your life easier/possible.

In the end however, I think we all recognize tickets are an interim  
solution and that eventually we will need to offer something more  
robust.

Mimi

On Jul 14, 2006, at 5:19 PM, Brian Moseley wrote:

> thanks for the deeper explanation. i buy your argument now. see below
> for a comment, though.
>
> On 7/14/06, Mimi Yin <mimi at osafoundation.org> wrote:
>
>> This misalignment of interests and goals is why:
>>
>> + Evite doesn't require user accounts to RSVP.
>> + Flickr doesn't require user accounts to view pictures.
>> + Many e-tailers (including Amazon) are now allowing users to make  
>> purchases
>> without creating accounts.
>> + It's one of the reasons why Microsoft created Passport.
>
> the difference between our stuff and these examples is, i think, the
> degree of privacy that is/could be required.
>
> my personal calendar is a very private thing, and i only want a few
> people at most to even have read access to it. i would be very upset
> if a ticket-bearing url was to escape into the wild and would probably
> immediately nuke all of my data from the server. i would most
> definitely not use tickets to share my calendar, and i would require
> that anybody i shared with have an account on the server and be forced
> to identify themselves to the server with (minimally) username and
> password.
>
> now, maybe i'm not one of the target users, and maybe sharing my
> personal calendar with select friends and family is not one of the
> target use cases. if that's the case, then i'll shut up.
>
> i do understand that for evite- or flickr-style collaborations,
> requiring an account is probably not necessary. luckily cosmo does
> support tickets, and i don't see anything in the original proposal
> that would keep chandler from using them for these types of sharing.
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>
> Open Source Applications Foundation "Design" mailing list
> http://lists.osafoundation.org/mailman/listinfo/design