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 |
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list http://lists.osafoundation.org/mailman/listinfo/design
