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

[Sheila Mooney]

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.







-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osafoundation.org/pipermail/design/attachments/20060728/7f15d573/attachment.html