Hi Brian,
I have a bunch of questions below plus a bit more explanation about
the user mental model and workflow issues around ACLs.
On Jul 11, 2006, at 9:48 AM, Brian Moseley wrote:
On 7/11/06, Sheila Mooney <[EMAIL PROTECTED]> wrote:
+ ACLs are a more common scenario to handle something like this
but the
current plan of record was to have ACLs for 1.0. From a PPD
perspective,
you can't have acl without also having user login. acls are attached
to specific user or group identities.
Yes, we understand that. We would like to associate ACLs with email
addresses however, rather than username accounts.
ACLs are also very complicated and there would still be
significant work to
figure out how to make this usable and doable in the current product
timeline.
it really doesn't have to be that complicated.
Past design discussions wrt ACLs have generally gotten pretty
complicated. Mostly around account look-up issues. The best solution
we've been able to think of is to
1. Allow sharers to send out read-write and read-only tickets to
sharees via email
2. Tickets are unique for each sharee
+ There are some questions about how ACLs fit in with our
"calendaring
without IT" organization goals.
access control seem pretty fundamental to sharing. i can't imagine one
without the other. we don't need the most flexible, general access
control system.
here's a strawman:
1) let me enter the cosmo usernames of people i want to give read or
read/write or freebusy access to, and deny everybody else.
+ How does the sharer find out other people's usernames in the first
place?
+ What if they haven't created accounts?
+ 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?
+ Can all sharees with read-access add accounts to the share? Or is
the administrator the only person who can do that?
+ What if the administrator 'leaves the working group'?
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.
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 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.
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)
4. Enter people's email addresses and fire off an email to invite
them to share and to point them to the share
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?
i know that as soon as somebody suggests entering usernames, there's a
storm of objection that there should be a directory or addressbook
that we can select usernames from. nah. i mean that would be cool, and
maybe we could do it later on, but for now, let us just enter
usernames. that's what the csg folks said a year ago, and it's still
good enough for "calendaring without IT".
+ Should we consider per user tickets? How difficult is this. Are
there
what does this mean?
Each sharee gets a unique ticket that can be turned off if it is
compromised.
other creative options ie: forcing anonymous users to decipher an
alpha-numeric string from a garbled up image?
that's captcha, and it's used to separate humans from malicious
programs. it's not a means of asserting identity to the server.
Correct. CAPTCHA was proposed as a way to deal with the SPAM issue.
PPD Questions:
+ Is a ticket URL essentially a potential security hole, the way
username/password is a potential security hole?
it's much more of one, because a ticket url is much more likely to be
communicated in an email or web page that could be intercepted or
harvested. people are pretty well trained to keep usernames and
passwords private. not so with urls, even if they are "magic".
+ How would a spammer exploit that security hole? Do they create
bots that
scan websites for ticket URLs?
they certainly could, but spamming isn't the main threat. exposing the
ticket to the general public is.
+ How do they figure out how to add content to Scooby once they've
found an
exposed ticket URL?
click the url and then use the scooby ui? :)
This was more of question for spamming. I'm not sure why an
individual would want to graffiti someone else's calendar manually.
+ Do they need to know what protocol Scooby speaks and tailor the
data they
add to that protocol?
no, because the url will take them to the scooby calendar/event
interface.
Sorry, this question was about automated spamming too.
+ How does the ticket URL approach compare with public websites
where the
content is available for anyone to search through, navigate
through and
view?
publicly harvested data is, well, public. it doesn't have the same
privacy issues that your personal calendar does.
+ Did Wikipedia have SPAM problems when they allowed anonymous edits?
i don't think that's relevant, for the reason above.
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?
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
