On 7/11/06, Mimi Yin <[EMAIL PROTECTED]> wrote:
Yes, we understand that. We would like to associate ACLs with email addresses however, rather than username accounts.
ok, so when a sharee clicks a calendar link in a sharing notification and is taken in their browser to scooby, how does scooby know the sharee's email address in order to identify him and see if he has any acls? you might say "chandler puts the email address into the calendar link". but how do we know that the person who is supposedly represented by that email address is the one that is actually making the scooby request? how do we know that the sharing notification didn't get intercepted? for that matter, how do we know that this isn't a spammer using a list of email addresses purchased from a direct marketer?
+ How does the sharer find out other people's usernames in the first place?
perhaps his small collaborative organization has a web page that lists everybody's cosmo username. or perhaps they have agreed to use their email usernames as their cosmo usernames as well. or perhaps the sharer just asks the sharees. perhaps i need my memory refreshed :) but i thought we were targeting small organizations with high bandwidth interactions. i can't imagine that finding out somebody's username without resorting to yet more software could be very challenging in such a situation. we can also integrate with external services like corporate white pages and federated identity systems, but maybe those are a little further off. phase two.
+ What if they haven't created accounts?
tell them to go create one. it takes like 5 seconds.
+ Once the usernames are entered, how do I notify the sharees that they can share and where they can go to view/edit the share? Do I need to enter email addresses as well? Do I need to email the sharees to tell them to check their Cosmo accounts on Scooby?
well, if chandler's local addressbook knows about that person already, it can map the cosmo username to email address. for those address chandler doesn't already know, cosmo can implement an authenticated report that returns the set of email addresses corresponding to a set of usernames. when the user enters the list of usernames, chandler can perform the report and then send out sharing notifications as usual.
+ Can all sharees with read-access add accounts to the share? Or is the administrator the only person who can do that?
i suggest people with write access on the share, including the share owner, administrators, and people who have a write ticket on the share.
+ What if the administrator 'leaves the working group'?
another administrator removes his account or minimally his administrative privilege.
We ran into this very issue trying to share the Google spreadsheet for the Scooby Feature Ranking Matrix meeting. Fortunately, most people already had gmail accounts. Even still, only 2 people responded to Priscilla's request for gmail account information prior to the meeting. The meeting itself was interrupted 4-5 times by people having to give Priscilla their gmail accounts and then Priscilla entering the account information and firing off an invitation to share. Matt (sorry to call you out) already had a google account, but not a gmail account and was reluctant to get a gmail account in order to share (fortunately, his google account worked anyway, but we weren't sure for a little while because he was having trouble). It was nobody's fault. The workflow is just really onerous.
oh come on. people being lazy and not preparing for a meeting does not mean the workflow is onerous. you wouldn't imagine an osaf staffer not having an osaf email account, would you? it's a mandatory service for the organization. the same goes for sharing. when you start your job, or your participation in a project, you get an account on the sharing server along with an account on your mail server. (yeah it would be great if there was one single account somewhere that the mail server and sharing server could reference. someday we'll be able to do that.)
And this was with gmail accounts...which presumably have some use to the user beyond just the sharing scenarios. For us, we're asking casual collaborators to get cosmo accounts...which have no use to them beyond sharing 1 or 2 collections that they may or may not look at more than a few times a month.
so? creating accounts and logging into them is a way of life on the web. we've been doing this for ten years. i refuse to believe that people who would consider using chandler and who would understand and be interested in the notion of managing calendars online would balk at the creation of an account on a web service.
So the proposal above would actually require something like this: 1. Email the people I want to share with and tell them to go create an account on cosmo.
this can just as easily be done when the server is set up or the person joins the working group. there's no need to make it part of the normal sharing workflow. and even if you don't, it's really not a big deal. have you ever seen backpackit.com? if i want to share a page with somebody who doesn't already have a backpack account, they go through a simple registration process and then they get to the shared page. it's easy. an orangutang could do it.
2. Ask them to please email me back with their usernames 3. Enter people's usernames into Chandler and assign ACLs to each account (requires additional UI work)
radio buttons: [] read [] read/write [] freebusy no need for complicated general acl management stuff.
4. Enter people's email addresses and fire off an email to invite them to share and to point them to the share
not at all, see above.
> 2) let me grant read or read/write tickets if i want to, understanding > that anybody who gets their hands on the tickets can use them I worry about how to explain the difference between 1 and 2 to users in laymen terms. Secure sharing? Insecure sharing? Requires accounts sharing? Doesn't require accounts sharing?
shrug. me not good with words. "share with other cosmo users" vs "share with randoms". i dunno, where are the copy writers when we need them?
This was more of question for spamming. I'm not sure why an individual would want to graffiti someone else's calendar manually.
oh, well the spammer can simply use http to understand what features are available at that calendar url and then exploit them.
It seems like SPAM is undesirable for both public and private information. My question was more about how serious a problem spamming would be in the near-term. It seems like you don't feel like it will be a major problem?
certainly not in the near term. personal and group calendaring has been available on the web at yahoo for years. if they haven't been a major spam target than i can't imagine any cosmo installations, especially those for small workgroups, being attacked. i'm much more worried about my private data or my company's data being compromised. the good news is that if you solve the privacy issue, locking down access to the calendar except to those who i explicitly give access, then you deny access to both spammers and burglars. _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ Open Source Applications Foundation "Design" mailing list http://lists.osafoundation.org/mailman/listinfo/design
