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

[Mimi Yin]

On Jul 12, 2006, at 3:38 PM, Brian Moseley wrote:

> On 7/12/06, Mimi Yin <mimi at osafoundation.org> wrote:
>
>> The optional password approach might work really well (at least  
>> from a
>> workflow perspective), especially if it was bundled in the URLs  
>> that get
>> copied to the clipboard. I believe pbwiki has something similar to  
>> this and
>> it's worked well for me in the past (where I was a casual sharee not
>> interested in creating an account).
>
> there's no difference between a url containing a ticket and a url
> containing a ticket and a password. they are redundant.
>
> if you're okay with letting people enter a password when accessing a
> calendar in scooby, then why not just have them enter the ticket? keep
> the ticket out of the url altogether.

ticket is harder to type in, but separating out the ticket would be  
fine too ;o)

>
> 1) sharer sends notification including the calendar url
> http://cosmo-demo/home/bcm/Calendar/ and the ticket 0xdeadbeef
> 2) sharee clicks the link and receives a page that says: "if you have
> an account, enter username and password to log in. if not, enter the
> ticket you received in the sharing notification."
>
> remember me can be done with the ticket just as easily with the
> username and password.
>
> i still fail to see how it's so much more usable for a user to enter a
> calendar-specific password than it is for a user to enter one username
> and password to be logged into the entire server. especially with some
> of the ideas that were tossed around yesterday about automatic account
> creation, and with remember me functionality which has rightly been
> brought up.
>
> mimi, i haven't seen any thoughts from you about any of the
> suggestions jeremy and i made yesterday afternoon. can we get some
> more discussion going about those things?

oh, I lumped my response in with Ashkan's proposal. As far as I can  
tell (from the user's perspective) Ashkan's proposal is pretty  
similar to Jeremy's proposal, except that it doesn't require a  
password and isn't presented to the user as an account...it's more as  
a security hurdle that is separate from the URL. The advantage of  
that is that users wouldn't expect shares that are sent to different  
email accounts to be coordinated into a single account.

> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>
> Open Source Applications Foundation "Design" mailing list
> http://lists.osafoundation.org/mailman/listinfo/design