|
List Info
Thread: Anonymous access to read-write tickets and security concerns
|
|
| Anonymous access to read-write tickets
and security concerns |
|
2006-07-13 18:40:51 |
|
On Jul 12, 2006, at 5:26 PM, Mimi Yin wrote: 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.
--> towns
|
| Anonymous access to read-write tickets
and security concerns |
|
2006-07-14 23:30:43 |
|
| True, users create accounts all the time for services they decided to invest time and effort and sometimes even dollars in to use.
Users are generally loathe to create accounts for services somebody else wants them to use. That's the key difference between the Hub user (who is happy to go through the trouble of setting up a Cosmo account) and the Casual Collaborator who never heard of Chandler, Scooby, Cosmo, the Hosted Service or the Ecosystem...and is for better or worse, being forcibly collaborated with.
Creating and managing accounts is a pain, and unless a person really wants to use a service, they'd just as soon as not use the service if it means creating and managing yet another account. The thesis is that in our 0.3 use case of updating a shared office calendar with PTO information, the Casual Collaborator is an example of someone who: presented with a choice between sending an email or creating and managing an account in order to use a new collaboration tool, would just as soon as not use the service, thereby saving themselves the trouble of having to create an account.
In other words, the interests and goals of the Collaborat-OR and the Collaborat-ED are not aligned. The Hub/Coordinator gets all of the benefit out of getting everyone to use the Ecosystem...But the Casual Collaborator is the one that has to surmount hurdles to make the collaboration work. (There is an analog to this scenario in the way that calendaring, scheduling and invitations has been set up to work.)
This misalignment of interests and goals is why:
+ Evite doesn't require user accounts to RSVP. + Flickr doesn't require user accounts to view pictures. + Many e-tailers (including Amazon) are now allowing users to make purchases without creating accounts. + It's one of the reasons why Microsoft created Passport.
It's why it's impossible to get some of my friends and family on IM to chat with me, because they don't use IM enough to feel like it's worth setting up an account. Yet, once in a while, it would be really useful to be able to chat.
Instead I should be able to send them an email when I know they're online...pinging them to click on a link and engage in a chat with me by using a temporary 'anonymous' account.
I'm also guessing this is one of the reasons why shared calendars on Yahoo and Hotmail never really took off, even though they've been around for a hundred years.
+ Does anyone have anecdotes about services that have been successful at getting users to sign up for accounts? + Does anyone have anecdotes about services that have had a hard time getting users to sign up for accounts?
Perhaps a few case studies will clarify the issue for all of us.
Mimi On Jul 13, 2006, at 11:40 AM, John Townsend wrote:
On Jul 12, 2006, at 5:26 PM, Mimi Yin wrote: 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.
--> towns
|
| Anonymous access to read-write tickets
and security concerns |
|
2006-07-14 23:30:43 |
|
| True, users create accounts all the time for services they decided to invest time and effort and sometimes even dollars in to use.
Users are generally loathe to create accounts for services somebody else wants them to use. That's the key difference between the Hub user (who is happy to go through the trouble of setting up a Cosmo account) and the Casual Collaborator who never heard of Chandler, Scooby, Cosmo, the Hosted Service or the Ecosystem...and is for better or worse, being forcibly collaborated with.
Creating and managing accounts is a pain, and unless a person really wants to use a service, they'd just as soon as not use the service if it means creating and managing yet another account. The thesis is that in our 0.3 use case of updating a shared office calendar with PTO information, the Casual Collaborator is an example of someone who: presented with a choice between sending an email or creating and managing an account in order to use a new collaboration tool, would just as soon as not use the service, thereby saving themselves the trouble of having to create an account.
In other words, the interests and goals of the Collaborat-OR and the Collaborat-ED are not aligned. The Hub/Coordinator gets all of the benefit out of getting everyone to use the Ecosystem...But the Casual Collaborator is the one that has to surmount hurdles to make the collaboration work. (There is an analog to this scenario in the way that calendaring, scheduling and invitations has been set up to work.)
This misalignment of interests and goals is why:
+ Evite doesn't require user accounts to RSVP. + Flickr doesn't require user accounts to view pictures. + Many e-tailers (including Amazon) are now allowing users to make purchases without creating accounts. + It's one of the reasons why Microsoft created Passport.
It's why it's impossible to get some of my friends and family on IM to chat with me, because they don't use IM enough to feel like it's worth setting up an account. Yet, once in a while, it would be really useful to be able to chat.
Instead I should be able to send them an email when I know they're online...pinging them to click on a link and engage in a chat with me by using a temporary 'anonymous' account.
I'm also guessing this is one of the reasons why shared calendars on Yahoo and Hotmail never really took off, even though they've been around for a hundred years.
+ Does anyone have anecdotes about services that have been successful at getting users to sign up for accounts? + Does anyone have anecdotes about services that have had a hard time getting users to sign up for accounts?
Perhaps a few case studies will clarify the issue for all of us.
Mimi On Jul 13, 2006, at 11:40 AM, John Townsend wrote:
On Jul 12, 2006, at 5:26 PM, Mimi Yin wrote: 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.
--> towns
|
| Anonymous access to read-write tickets
and security concerns |
|
2006-07-15 00:01:12 |
|
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 |
| Anonymous access to read-write tickets
and security concerns |
|
2006-07-15 00:01:12 |
|
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 |
| Anonymous access to read-write tickets
and security concerns |
|
2006-07-15 00:19:03 |
thanks for the deeper explanation. i buy your argument now.
see below
for a comment, though.
On 7/14/06, Mimi Yin <mimi osafoundation.org>
wrote:
> This misalignment of interests and goals is why:
>
> + Evite doesn't require user accounts to RSVP.
> + Flickr doesn't require user accounts to view
pictures.
> + Many e-tailers (including Amazon) are now allowing
users to make purchases
> without creating accounts.
> + It's one of the reasons why Microsoft created
Passport.
the difference between our stuff and these examples is, i
think, the
degree of privacy that is/could be required.
my personal calendar is a very private thing, and i only
want a few
people at most to even have read access to it. i would be
very upset
if a ticket-bearing url was to escape into the wild and
would probably
immediately nuke all of my data from the server. i would
most
definitely not use tickets to share my calendar, and i would
require
that anybody i shared with have an account on the server and
be forced
to identify themselves to the server with (minimally)
username and
password.
now, maybe i'm not one of the target users, and maybe
sharing my
personal calendar with select friends and family is not one
of the
target use cases. if that's the case, then i'll shut up.
i do understand that for evite- or flickr-style
collaborations,
requiring an account is probably not necessary. luckily
cosmo does
support tickets, and i don't see anything in the original
proposal
that would keep chandler from using them for these types of
sharing.
_______________________________________________
scooby-dev mailing list
scooby-devlists.osafoundation.org
http://lists.osafoundation.org/cgi-bin/mailman
/listinfo/scooby-dev
|
|
| Anonymous access to read-write tickets
and security concerns |
|
2006-07-15 00:19:03 |
thanks for the deeper explanation. i buy your argument now.
see below
for a comment, though.
On 7/14/06, Mimi Yin <mimiosafoundation.org>
wrote:
> This misalignment of interests and goals is why:
>
> + Evite doesn't require user accounts to RSVP.
> + Flickr doesn't require user accounts to view
pictures.
> + Many e-tailers (including Amazon) are now allowing
users to make purchases
> without creating accounts.
> + It's one of the reasons why Microsoft created
Passport.
the difference between our stuff and these examples is, i
think, the
degree of privacy that is/could be required.
my personal calendar is a very private thing, and i only
want a few
people at most to even have read access to it. i would be
very upset
if a ticket-bearing url was to escape into the wild and
would probably
immediately nuke all of my data from the server. i would
most
definitely not use tickets to share my calendar, and i would
require
that anybody i shared with have an account on the server and
be forced
to identify themselves to the server with (minimally)
username and
password.
now, maybe i'm not one of the target users, and maybe
sharing my
personal calendar with select friends and family is not one
of the
target use cases. if that's the case, then i'll shut up.
i do understand that for evite- or flickr-style
collaborations,
requiring an account is probably not necessary. luckily
cosmo does
support tickets, and i don't see anything in the original
proposal
that would keep chandler from using them for these types of
sharing.
_______________________________________________
scooby-dev mailing list
scooby-devlists.osafoundation.org
http://lists.osafoundation.org/cgi-bin/mailman
/listinfo/scooby-dev
|
|
| Anonymous access to read-write tickets
and security concerns |
|
2006-07-15 01:44:52 |
> Mimi wrote:
> It's why it's impossible to get some of my friends
and family on IM
> to chat with me, because they don't use IM enough to
feel like it's
> worth setting up an account. Yet, once in a while, it
would be
> really useful to be able to chat.
>
> Instead I should be able to send them an email when I
know they're
> online...pinging them to click on a link and engage in
a chat with
> me by using a temporary 'anonymous' account.
>
Maybe the link in the email you send to a CC (cas.
collaborator)
would expire after a short amount of time, or only work
once, perhaps
satisfying somewhat bcm's worries about security?
Bobby
_______________________________________________
scooby-dev mailing list
scooby-devlists.osafoundation.org
http://lists.osafoundation.org/cgi-bin/mailman
/listinfo/scooby-dev
|
|
| Anonymous access to read-write tickets
and security concerns |
|
2006-07-15 01:44:52 |
> Mimi wrote:
> It's why it's impossible to get some of my friends
and family on IM
> to chat with me, because they don't use IM enough to
feel like it's
> worth setting up an account. Yet, once in a while, it
would be
> really useful to be able to chat.
>
> Instead I should be able to send them an email when I
know they're
> online...pinging them to click on a link and engage in
a chat with
> me by using a temporary 'anonymous' account.
>
Maybe the link in the email you send to a CC (cas.
collaborator)
would expire after a short amount of time, or only work
once, perhaps
satisfying somewhat bcm's worries about security?
Bobby
_______________________________________________
scooby-dev mailing list
scooby-devlists.osafoundation.org
http://lists.osafoundation.org/cgi-bin/mailman
/listinfo/scooby-dev
|
|
| Anonymous access to read-write tickets
and security concerns |
|
2006-07-17 17:05:25 |
Absolutely. There will always be people who will not be
comfortable
with the way we're doing sharing.
How much effort we're going to expend in the Beta timeframe
to make
everyone comfortable with sharing is partially a target user
issue
and partially a personal choice thing that is independent of
the
whole target user exercise.
For some people, it won't matter what 'role' they play in
their
organization. It doesn't matter if their organization is a
small
group, a large enterprise or the government. They won't
share without
user accounts.
Nevertheless, there are a handful of 'target user'
considerations to
take into account.
+ If you really, really, really, really, really need to
share your
calendar. (e.g. you're Mitch) Then you might put up with
the security
risk in order to make your life easier/possible.
In the end however, I think we all recognize tickets are an
interim
solution and that eventually we will need to offer something
more
robust.
Mimi
On Jul 14, 2006, at 5:19 PM, Brian Moseley wrote:
> thanks for the deeper explanation. i buy your argument
now. see below
> for a comment, though.
>
> On 7/14/06, Mimi Yin <mimiosafoundation.org>
wrote:
>
>> This misalignment of interests and goals is why:
>>
>> + Evite doesn't require user accounts to RSVP.
>> + Flickr doesn't require user accounts to view
pictures.
>> + Many e-tailers (including Amazon) are now
allowing users to make
>> purchases
>> without creating accounts.
>> + It's one of the reasons why Microsoft created
Passport.
>
> the difference between our stuff and these examples is,
i think, the
> degree of privacy that is/could be required.
>
> my personal calendar is a very private thing, and i
only want a few
> people at most to even have read access to it. i would
be very upset
> if a ticket-bearing url was to escape into the wild and
would probably
> immediately nuke all of my data from the server. i
would most
> definitely not use tickets to share my calendar, and i
would require
> that anybody i shared with have an account on the
server and be forced
> to identify themselves to the server with (minimally)
username and
> password.
>
> now, maybe i'm not one of the target users, and maybe
sharing my
> personal calendar with select friends and family is not
one of the
> target use cases. if that's the case, then i'll shut
up.
>
> i do understand that for evite- or flickr-style
collaborations,
> requiring an account is probably not necessary. luckily
cosmo does
> support tickets, and i don't see anything in the
original proposal
> that would keep chandler from using them for these
types of sharing.
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>
> Open Source Applications Foundation
"Design" mailing list
> http://lists.osafoundation.org/mailman/listinfo/design
_______________________________________________
scooby-dev mailing list
scooby-devlists.osafoundation.org
http://lists.osafoundation.org/cgi-bin/mailman
/listinfo/scooby-dev
|
|
| Anonymous access to read-write tickets
and security concerns |
|
2006-07-17 17:05:25 |
Absolutely. There will always be people who will not be
comfortable
with the way we're doing sharing.
How much effort we're going to expend in the Beta timeframe
to make
everyone comfortable with sharing is partially a target user
issue
and partially a personal choice thing that is independent of
the
whole target user exercise.
For some people, it won't matter what 'role' they play in
their
organization. It doesn't matter if their organization is a
small
group, a large enterprise or the government. They won't
share without
user accounts.
Nevertheless, there are a handful of 'target user'
considerations to
take into account.
+ If you really, really, really, really, really need to
share your
calendar. (e.g. you're Mitch) Then you might put up with
the security
risk in order to make your life easier/possible.
In the end however, I think we all recognize tickets are an
interim
solution and that eventually we will need to offer something
more
robust.
Mimi
On Jul 14, 2006, at 5:19 PM, Brian Moseley wrote:
> thanks for the deeper explanation. i buy your argument
now. see below
> for a comment, though.
>
> On 7/14/06, Mimi Yin <mimiosafoundation.org>
wrote:
>
>> This misalignment of interests and goals is why:
>>
>> + Evite doesn't require user accounts to RSVP.
>> + Flickr doesn't require user accounts to view
pictures.
>> + Many e-tailers (including Amazon) are now
allowing users to make
>> purchases
>> without creating accounts.
>> + It's one of the reasons why Microsoft created
Passport.
>
> the difference between our stuff and these examples is,
i think, the
> degree of privacy that is/could be required.
>
> my personal calendar is a very private thing, and i
only want a few
> people at most to even have read access to it. i would
be very upset
> if a ticket-bearing url was to escape into the wild and
would probably
> immediately nuke all of my data from the server. i
would most
> definitely not use tickets to share my calendar, and i
would require
> that anybody i shared with have an account on the
server and be forced
> to identify themselves to the server with (minimally)
username and
> password.
>
> now, maybe i'm not one of the target users, and maybe
sharing my
> personal calendar with select friends and family is not
one of the
> target use cases. if that's the case, then i'll shut
up.
>
> i do understand that for evite- or flickr-style
collaborations,
> requiring an account is probably not necessary. luckily
cosmo does
> support tickets, and i don't see anything in the
original proposal
> that would keep chandler from using them for these
types of sharing.
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>
> Open Source Applications Foundation
"Design" mailing list
> http://lists.osafoundation.org/mailman/listinfo/design
_______________________________________________
scooby-dev mailing list
scooby-devlists.osafoundation.org
http://lists.osafoundation.org/cgi-bin/mailman
/listinfo/scooby-dev
|
|
[1-11]
|
|