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

[Sheila Mooney]

Sorry, my bad for not getting this post out to the list sooner...

Context:

A couple of weeks ago the web client and PPD teams met to go through  
the proposed usage scenario for Scooby 0.3. Several good issues  
surfaced around how we intend on satisfying this usage scenario -  
particularly centering around security and web access. I will attempt  
here to summarize...

+ What we are trying to accomplish at user perspective and why
+ Proposed design
+ Issues that came up during the meeting
+ A list of PPD questions about security concerns etc.

My objective with this post is to generate some dialog around how  
serious the security concerns should be in the 1.0 timeframe and  
other creative solutions for satisfying the user needs.

User Goals:

+ The primary use case for 0.3 is to enable someone from OSAF to  
easily update their PTO on the office calendar, using the web client  
as an interface.
+ Today, this individual would simply send an email to everyone at  
OSAF with PTO in the title and Esther is responsible for updating an  
iCal version of our office calendar.
+ We would eventually like to get rid of the iCal version of the  
office calendar and have everyone update PTO or other travel time on  
the shared read-write office calendar.
+ How do we make the experience of getting to the office calendar and  
updating your information as simple as possible - equivalent to the  
ease of simply sending an email?

Proposed Design:

There are a couple of things to note...

+ Unless we made some drastic change we assume that people will be  
receiving a read-write ticket to the office calendar as they do today  
- since this is the technology we have in place right now.
+ To facilitate ease of use and adoption, we currently allow desktop  
client users to subscribe to calendars upon receiving a ticket and  
not require them to have an account on the server.

The current design proposal is as follows....

+ Support a clickable URL - someone receives a URL ticket, let's say  
via email, they simply click on it and the calendar would be  
displayed in a browser (Scooby).
+ As with the desktop client, having a read write ticket would enable  
users to immediately start editing the calendar.
+ Since we support read-only as well as read-write tickets, it's  
possible that someone will only be able to view the calendar.

Implications/Assumptions

+ This implies as with the desktop, anyone who gets a hold of the  
read write ticket can edit the calendar.
+ They are not forced to sign up for an account - we don't know who  
they are when they make changes. The changes get logged but we don't  
have a username.
+ There is no mechanism in place to search for tickets, someone needs  
to get a hold of one to actually to anything.
+ The small workgroup target for 1.0 will be more self-contained, we  
won't be passing around tickets to that many people.

Issues Surfaced:

There were several issues raised around security, particularly giving  
users the ability to edit calendars without having to log into some  
kind of account. Here is a summary of some of the issues raised.

SECURITY ISSUES:

+ If you get a hold of a ticket you can make anonymous changes to a  
calendar and nobody knows. We are giving anonymous access to anyone.
+ Tickets as they are implemented today are not very secure.
+ In the web space, it's more common to force people to login ie; Flickr
+ For something list evite, users can RSVP (have some level of  
editing but not full access)
+ There are concerns about things like calendar spam - people put the  
URL on an online forum. We already have wiki spam issues today.
+ We currently allow anonymous access for the desktop client but  
there are strong feelings that there's a fundamental difference  
between giving web access and doing this from a desktop client

DESIGN ISSUES:
+ Username/password account logins is a known usability problem.  
Username/password accounts makes it easier for service providers to  
manage security leaks. However, they are onerous for the user and  
present a significant barrier to entry for new users, especially  
casual users.
+ On the other hand, it is common in the web space to for anonymous  
users to participate as a viewer only or a restricted users (can do  
limited things).
+ ACLs are a more common scenario to handle something like this but  
the current plan of record was to have ACLs for 1.0. From a PPD  
perspective, ACLs are also very complicated and there would still be  
significant work to figure out how to make this usable and doable in  
the current product timeline.
+ There are some questions about how ACLs fit in with our  
"calendaring without IT" organization goals.
+ Should we consider per user tickets? How difficult is this. Are  
there other creative options ie: forcing anonymous users to decipher  
an alpha-numeric string from a garbled up image?

PPD Questions:

+ Is a ticket URL essentially a potential security hole, the way  
username/password is a potential security hole?
+ How would a spammer exploit that security hole? Do they create bots  
that scan websites for ticket URLs?
+ How do they figure out how to add content to Scooby once they've  
found an exposed ticket URL?
+ Do they need to know what protocol Scooby speaks and tailor the  
data they add to that protocol?
+ How much surface area is there for an attack?
+ How does the ticket URL approach compare with public websites where  
the content is available for anyone to search through, navigate  
through and view?
+ Did Wikipedia have SPAM problems when they allowed anonymous edits?
+ Do we have wiki SPAM problems today?

Sheila



-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osafoundation.org/pipermail/design/attachments/20060711/256187da/attachment.html