Anonymous access to read-write tickets and security concerns

Thread: Anonymous access to read-write tickets and security concerns

Search this list only Search all lists
Anonymous access to read-write tickets and security concerns
	2006-07-28 20:43:08

A couple of weeks ago I posted a thread about allowing users to anonymously edit read-write calendar events using Scooby. http://lists.osafoundation.org/pipermail/design/2006-July/004958.html This is some attempt to summarize the proposals, issues, arguments (categorized by themes) that came out in the thread. + TOP ISSUES, CONCERNS AND CLARIFICATIONS: + BCM + ACLs are attached to specific user or group identities and therefore imply having logins. + He pointed out that ACLs don't have to be that complicated and are pretty fundamental to sharing + Tickets are a bigger security hole than usernames because it's more likely to be communicated it an email or web page that could be intercepted. + People are trained to use usernames and passwords, not so with urls. + Exposing the ticket to the general public is a bigger threat than spamming. + Simply clicking the URL can add content to Scooby, it exposes the events directly. + Personal calendar data has some privacy issues that differ from publicly harvested data on public websites. + Wikipedia SPAM issues are not relevant since it's different than personal calendar data. + Mimi: + We would like to associate ACLs with email accounts rather than server usernames you don't have to find out usernames - usually know people's emails. + Mimi pointed out the experience with Google spreadsheet. People didn't respond with account information, it was very unorganized trying to get setup. + We are asking people to get Cosmo accounts which have no purpose beyond sharing. + Casual collaborators will not be using this frequently - look at collections 1-2 times a month. + Agrees spam is an issue and wonders how immediate this problem will be in the short-term. + Mimi is worried about the scenario - email people to set up and account, wait until they give you account names, enter these in chandler, enter email addresses to send an invite. + BCM: + Problem with associating emails to ACLs. When a user clicks on a notification goes to Scooby, how does Scooby know the email address as the identification for this person. + Putting email addresses into the calendar link has problems - how do we know it's really this person, could be spam. + To find out usernames: small company has a wiki/web page, maybe they use their emails. If we are targeting small groups with high-bandwidth interactions finding out usernames should be easy. + Mimi + There are workflow problems of coordinating shares sent to different email accounts into a single cosmo account. + On the design side we don't want users to feel they are creating and maintaining accounts. + Auto-generating accounts helps but we are still asking people to pick and remember a password. + Acknowledges that users create accounts all the time currently for services but there is a difference between the work that a hub user is willing to do vs a casual collaborator. This implies a difference in commitment to using the service. Our thesis for Scooby 0.3 is that these casual collaborators would choose not to create the account over using the service. The goals of these 2 types of users are not aligned. + She points out that this misalignment is why there are differences between how other products handle this. evite vs flickr. + Acknowledges that in the beta timeframe there will be some people who don't feel comfortable with the way we are doing sharing. + This will be a barrier for some people but in the beta timeframe we can't satisfy everyone. + The question is are people willing to put up with these security risks in the short-term to share their calendars. + We all recognize tickets are an interim solution and not what we want for the long term. + John T + Doesn't understand why it's a design requirement that users don't feel they like they are creating and maintaining accounts + People do this all the time and would rather be explicit and force people to create accounts than auto-create them. + Says there is a difference between the desktop and the web app and web apps have different requirements and expectations and we are not designing for that. + Mikeal + Most web apps have the model - some people have write, some read, some nothing + Most people have the ability to read + Doesn't like tickets as a solution but feels users should be able to say they want everyone to write to the calendar and not force logins if they don't want to. + We can invite people and those that except should have no barrier + Priscilla + Examine security alternatives based on our use case for an OSAF employee adding PTO to the office calendar + 1) Silent agreement and trust that info would not get out to a larger audience + 2) Force people to identify themselves in order to participate. IT manages his account. + 3) Advanced ACLs. IT sets up permissions. + If we think about the target user for 1.0 as the casual collaborator it's possible to accommodate the casual collaborator even if you have a security model and this may make the experience for the casual collaborator a better one. + If we are deciding in the short-term to trade low security for ease of adoption, at what point does having more security become a higher priority? + BCM - on proposal from original email + Really has no issues with the proposal at hand since we support tickets today. + Understands the arguments + Still has concern about security and personal data. + Concern is over the calendar being a private thing and wanting to control who has a certain level of access to it. + Worries about ticket escaping into the hands of others + VARIOUS PROPOSALS/IDEAS AND COMMENTS + BCM's proposal... + A solution where people could enter usernames of people I want to give access OR grant read or rw tickets and anybody that gets one has access. We would have to know people's usernames and there would be no address book. + Comments -> Mimi + Past design discussions have gotten complicated around account lookup issues. Our way of getting around this was read-only and read-write tickets and unique tickets for each sharee. + How do sharers find out people's user names in the first place? What if they haven't created accounts yet? + Do I need to enter both account names and emails for the notifications? + Can people with RW access add accounts to the share? + Is there an admin - what if they leave? + Jeremy's proposal... + Enter a list of emails to invite and they do a match-up with account names in the db. + If there is no match, we create and account under the hood for these new users. + Send an email with info to users. + When they try and edit we prompt them with username and password. + Provide affordance for changing generated password. + Implies Chandler and Scooby can send automated emails. + Some simplifying assumptions... + Email and username are the same + Accounts created under the hood + Have basic permissions like you can only edit or destroy events you create + Have some implied permissions like invitations allow reply actions - meetings have accept, reject etc + You can't touch other people's events unless you are the owner of the calendar + Be able to locate people's friends - when they enter username and password we search the address book + Comments -> Sheila + We talked about this a year and a half ago and there were some concerns about matching emails and usernames + People may have more than one email and what happens when the email address changes? + If I enter an email with no match but I have an account, what happens? + How do we deal with passwords on auto account creation? -> Lisa + All the issues going beyond tickets - discussed a couple of years ago were possible but required more interface work and programming. + Except for the spam/privacy issues discussed - it's just work. -> Heikki + Agreed with Sheila's concerns... + Using email as account name will confuse less technically savvy people. They may have different passwords on email and cosmo and get them confused. In many cases they will use the same one for both which is a bad security practice. Changing passwords becomes confusing. + In some cases, people don't want to disclose their email but account names are ok. -> Mimi + Imagine a more open collaboration model since our workflows support multiple people collaborating on one item + Giving people particular permissions based on the type of event is too restrictive. + Mitch is likely to be sharing with a small group, if his ticket is compromised then he can republish + Concerns are valid but wondering if in the Beta timeframe it's ok to continue with what we have for the short-term. + Wants to understand the wide range of spam type things that can happen and the likelihood in the beta timeframe. -> Mikeal + Proposed an alternative to Jeremy's solution + Doesn't like the idea to auto-create an account for everyone that may access a calendar. Only create accounts is people accept the invite. -> BCM + Likes the proposal but some discomfort around creating auto-creating accounts + Username and password being the same has issues - pre sheila's email + The user is forced to choose a username and password at some point when we create an account automatically + In order to support basic edit permissions, people using scooby have to assert their identity to cosmo + Many of the points assume authentication to the server and the server makes decisions based on the identity - not so with tickets + Agrees that spam is an issue + For Cosmo to only require email as and id - It's difficult to use email addresses since they change frequently -> BCM re: Sheila's email + We should be able to associate multiple emails with an account but not implemented yet. + If our Cosmo account includes all email addresses then there is no problem otherwise we need tools and a ui for this. + To make the account creation process smoother - when you submit a list of emails for sharees, cosmo returns token's that get inserted into the sharing url for each user, matches to an email and shows the reg field with that info when they are presented with the new account setup. -> Pieter + Supplying a person's email address to a service is a breach of confidence - knows people who are uncomfortable with this + People are relunctant to make their email available to more spam - how would we feel about phone numbers + Also people could be receiving unsolicited email from servers they don't know + Using tickets from personal contacts prevents this. + Ok if the sharing invitations come from people personally, then this is ok. -> BCM - re: Pieter's email + The email notifications come from Chandler not the server. + Email is not as sensitive as a phone number. + We can apply filters to email for unsolicited mail and spam. -> Bobby - re: Pieter's email + Doesn't like to give his email to a service + Ashkan's proposal... + Proposals for getting a small amount of security without requiring signup + A) Use the recipients email address as a barrier to get read/write access + Send sharing notifications to user via email addresses - record these + If they do not have accounts, ask them to verify their email address so Cosmo/Scooby can do a match + B) Allow calendar creator to 'approve' changes made to the calendar + Send sharing notifications to user via email addresses + Specify for each recipient if they require approval to make changes + If you try and make changes are don't have account, we check to see if you have approval - if not, either prompt for account or allow anonymous changes pending final approval by calendar owner + If we had checked "requires approval" the calendar creator then gets emails from Scooby/Cosmo requesting that the following changes made by the anonymous user to be approved + Option 2 potentially doesn't work well if the calendar creator is not involved directory in managing the calendar. + Comments: -> Mimi + Allows us to track who changed a collection without requiring an account + We would need to bring back the sharing detail view. + 2 fields for entering list of read-write emails then list of read-only emails + Mitch proposal/ideas.. + Ideas for making sharing via tickets more secure + Make additional security a choice not a requirement + Attach passwords to calendars + Comments -> Mimi + Optional password fits in well at a workflow perspective - bundled with the url + Suggests remember me feature -> BCM + URL containing a ticket = a url containing a ticket and a password - just have people enter the ticket + Doesn't see how this is more usable for people to enter a calendar specific password than to log into the server since the auto account creation seems like a good alternative. -> Mimi + Tickets are harder to type in but if we separated it out, that would be ok. + Feel's Ashkan and Jeremy's proposals are similar. Ashkan's doesn't require a password and isn't presented as an account. Shares sent to diff email accounts won't have to be coordinated into one account. + Bobby's suggestion... + Suggested that the URLs we send to casual collaborators expired after some short amount of time or only work once as a compromise for the security concerns. + SMALL GROUP CLARIFICATION + An important theme that came out of this thread is understanding exactly what the needs and expectations are for our target users in the Beta and 1.0 timeframe. + Mimi + Some assumptions people are making don't hold true for small workgroups + Think about how the nature of trust changes for sm groups (5-30) vs large vs gigantic + Assumptions for Beta/1.0 Ecosystem: 1. There is no IT department setting up a sharing service for the 'company'. (Calendars without IT) 2. In many cases, there isn't even really a 'company' or 'company policies' 3. You may not even be given a 'company' email address 4. Everyone knows each other in the collaboration group. In other words, there is intrinsic, unstructured trust. 5. There is a real need for more than 1 person to collaborate heavily on a single item - stamping storyboards + It's not that sm groups require less security it's that they often work work or can't work in a framework designed for large groups + Sm groups have a vested interest in not screwing up those trust relationships. + People know who they are giving their information to + The point at which the security framework should change is when: 1. We can make it more secure without making it more onerous for small workgroup users. 2. We are ready to target medium to large size workgroups that have different group dynamics and different trust relationships. + Priscilla + Definition of small groups is not clear - 2 distinct types #1 - Sm professional organization that has policies and structure #2 - Sm informal groups - book club, study group etc + Trust is not different based on small vs large, it's more a matter of formality and the dynamics and expectations may not be related to size. + For group #1, you are required to use the software to collaboration ie: company policy + For group #2, it's more group consensus + Calendars without IT + If a small company uses Chandler/Cosmo/Scooby without the OSAF hosted service is this considered part of the ecosystem? + No company policies really only applies to group #2 not group #1 + Only informal groups would have no email + Disagrees that there is some unstructured trust within the group and it would feel rude to give differing levels of privileges + ACLs would help to focus the collaboration so that more than one person can collaborate on an item + Companies like LPFI would have some IT resources (contracted) even if they weren't affiliated with other geeky organizations. + Feels strongly there are some social rules that structure interactions. + Jeffrey + Feels that both of the groups described by Priscilla are similar. Regardless of structure they often has issues such as insufficient tech resources. + Feels there are really trust shifts between these groups. + The members will generally follow in both types of organizations, but you almost always bump into people who will not but doesn't think this is related to whether or not the org is professional or not. + Sees the Chandler/Scooby collaboration as more bi-directional. + It would be cool for Chandler/Scooby to do evite-like things where people could change shared data is restricted ways. + Feels that enabling the non-ACL parts of this workflow in a generalized way would take a lot of work and probably not realistic for the short- term. + WHERE WE ARE NOW & NEXT ACTIONS: + There seems to be general agreement that we need some security model/privileges in order to accommodate all potential users in the long-term. + We need to be able to support additional security as a choice but not a requirement for all users. + There is acknowledgment that going with forced security or none in the short-term will be a barrier for some people. + There is some suggestion that tickets are not appropriate for the long-term. + We don't yet know the cost of any of the proposals that were presented. + Spelling out the target user group and their needs in more detail will help us figure out the right solution for the short-term and the long-term. + There are definitely some options in the short-term (Beta), that would meet the design requirements and enhance the security for users. + The design and dev teams will continue to explore the optimal solution to put in place for 1.0. + The design team would also like to do a LAST CALL on the idea of using the tickets as a password as a proposal for Beta.

[1]

about | contact Other archives ( Real Estate discussion Medical topics )