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

[Mikeal Rogers]

It's also problematic because one of the design requirements we're putting forward is that users don't feel like they're creating / maintaining an account. Jeremy's proposal meets this requirement because the accounts are auto-generated (although asking users to pick and remember a password is still problematic). I don't understand why this is a design requirement. Users create accounts online all of the time. They are used to it, they do it on multiple web services already. I really don't like the idea of auto-generating accounts. I would rather see us be more explicit with the user and tell them we are creating an account on their behalf, let them tell us how to name/identify this account, etc. I understand that Chandler doesn't require a login. But, this is another case where Chandler is not a web application and Cosmo/Scooby is. The requirements and expectations are different. I'd like expand upon this a bit. Most web applications stick to the model of "some people have write, some have read, some have nothing". Most sites say that "anyone can read" except maybe people explicitly blocked from the site. And a group or list of people may be able to write to different pieces of the site. Tickets are bad solution for reasons we're already discussed. I don't think we should force everyone to create an account, but I think it's fair to say "if you want everyone to write to this calendar then EVERYONE can write to this calendar" like a wiki. And it's fair that we also say "you can create a list of users who can edit this calendar". When a user comes to the site who has been invited to the calendar we should allow them to write to it without any real barrier to entry, if anything to boost our own success, and there are many examples of sites that do this (evite). BUT we should not be creating an account for every single person who is invited, only those that accept the invitation. Here is another possible way to solve this problem.  This is Jeremy's proposal; you enter a list of emails to invite and chandler/scooby handles the rest: (1) it looks to match users to emails in the cosmo DB, (2) if matched "do the right thing"  if not, create a new account. username == email (3) send email to all these new users (4) when the new user gets to scooby and attempts a non-read action, we prompt for them to enter their email and password.-- we offer an affordance for new users to choose a password. All of this implies that chandler and scooby can do what every other app on the web does-- send automated emails. The issue I have is item 3, in which an account is created for every invitee that _may_ access a calendar.  This sort of rampant user creation is a bad idea. If we are successful, which we all hope that we are, we'll have thousands of dangling user accounts. If the issue is that we need to be able to allow the owner of a calendar to send invitations to a set of people, and those people to be able to use the calendar without logging in (or at least know that they are logging in), but later may get the full benefit of an account then this is solvable without creating an account for every user we send an invite to. When an owner of a calendar creates a list of email invitees to that calendar let's send them all a different url to access the calendar. That url has the invite information somehow referenced in it, either it's a big hash that cosmo has information about like tickets, or it could just have some url parameters in it. Once the user actually goes to that url THEN we can create an 'unverified' account for that email address. Now we can decide what level of service 'unverified' users can have without creating one for every person who may decide to look at a calendar. -Mikeal

_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

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