See in-line...
On Jul 11, 2006, at 1:30 PM, Jeremy Epstein wrote:
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?
you dont have to. The permissions you assign have everything to do
with how you stamp events:
"invitations" only allow "reply actions" for the invitees
"meetings" may allow "accept" "reject" "tentative" and "schedule"
if you are not on the list for an event you can only look at it.
Maybe not even that.
etc...
that and the rule "you can never touch someone else's event" unless
you are made an "owner" of the calendar.
I think we've always imagined a more open collaboration model than
this. A lot of the usage scenarios / workflows we've sketched out and
storyboarded involve multiple people collaborating on a single item.
(See: http://wiki.osafoundation.org/bin/view/Journal/
StampingStoryboards#StampingWorkflow)
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".
or you scrape. IE "send to your friends"-- enter in you gmail
username and password. WE scarpe the address book and present
emails to you to send invites to. (this is more common then you think)
+ 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.
that is still the equivalent of making each user on windows an admin.
I'm not sure I understand.
they certainly could, but spamming isn't the main threat.
exposing the
ticket to the general public is.
+1 to that
This was more of question for spamming. I'm not sure why an
individual would want to graffiti someone else's calendar manually.
Not necessarily graffiti. Imagine someone taking mitch's ticket and
making a website ("pitch your idea to mitch" ), then submitting it
to slashdot.
This is where the ability to shut off an individual ticket would help.
Even so, I'm not sure how many people Mitch would give read-write
access to on his personal calendar. Which means that even if we
didn't have per-sharee read-write tickets, if the share was
compromised, it wouldn't be that much of a hassle to issue a new read-
write ticket and have 2 sharees re-subscribe with the new ticket.
The scale of sharing we're talking about in the Beta timeframe is
just very small.
It's one of those things where if you're a high stakes person, you
make sure to be extra careful about these things. And if you're not a
high stakes person, then why would anyone bother manually spamming
you in the first place? It seems like in most scenarios, it wouldn't
be worth anyone's time to spam shared collections unless it could be
done in an automated way.
I'm not trying to discount the scenarios that are being brought up.
They are legitimate and serious. I'm just wondering if we can get
away with what we have in the beta timeframe because of the nature of
the collaboration scenarios we're supporting.
===
On a related note, I'm starting to get confused with all the
different 'spammy' things that could happen. I think there are 2-3
very distinct scenarios and teasing them a part might help us figure
out which scenarios are more or less likely in the Beta timeframe.
How unwanted data gets added to a shared collection where the read-
write ticket has been compromised:
1. SPAM: Malicious or Commercial, Automated, Large-scale
2. Graffiti: Malicious, Manual, Small-scale
+ 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.
the same rules apply-- its actually likely that the spammer may
attempt to penetrate the cosmo server as it uses a more well
established protocol(calDAV).
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?
Ask that the next time OSAF gets slashdotted.
I'm drawing this from a current project involving some very
consumer stuff(podcasting) where there is an effort to sign up
members fast, yet still limit spam. The catch is in reducing the
requirements for sign up to the bare minimum. Right now cosmo
requires or appears to require six fields. it should only require
one-- email. Cosmo can mail a generated password to the user email.
Jeremy
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
