Hi Brian, see below...
On Aug 21, 2006, at 3:18 PM, Brian Moseley wrote:
On 8/21/06, Mimi Yin <[EMAIL PROTECTED]> wrote:
To clarify again. would it be fair to say that an URL that does not
include a ticket IS more hackable if the sharer does NOT password
protect the share.
no, because nobody would be able to access the url except the sharer,
who can present his cosmo username and password.
unless the user includes *some* sort of credential - a ticket, or a
username and password - the url is not accessible.
I think I see where the disconnect is. I'm assuming that it would be
possible to do something like, allow sharees to access shares with
just a plain English URL
osaf.us/bcm/calendar/read-write
But we wouldn't want to do this, because this is just way too easy to
guess.
But from your perspective, this would be a public share? and not
something we support today, correct?
(I can see how from an implementation perspective, there is a clear
divide between this and an URL with an embedded ticket. However, from
the user's perspective, it's more a matter of degree. An URL with an
embedded ticket is just the same as a public URL that's harder to
guess. There are lots of 'public' URLs out there that look a lot like
our ticket URLS. e.g. http://www.amazon.com/gp/product/B000E84CQQ/
sr=1-1/qid=1156200454/ref=sr_1_1/002-9300654-2621649?ie=UTF8&s=wireless)
That's the crux of the design concern regarding security. Users
receiving ticket URLs will treat them as URLs, something you can pass
around with ease, not as something with an embedded security measure.
What if the user doesn't want to password protect the share?
then they get the default read-only and read-write tickets, just
like today.
or do you mean, what if the user wants the share to be public? hm.
we'd have to figure out a way for the sharing process to communicate
that to cosmo, and we'd have to add the notion of "public" to cosmo's
security model. this is where we start to get into acl land.
Well i'm assuming that either way, we want the URL (without a
password) to be the same as the URL (with a password). Which is why
I'm assuming that the URL (with a password) would have an embedded
ticket. Because we wouldn't want to provide an URL (without a
password) that didn't have an embedded ticket.
Are you saying the 2 options should be:
+ Provide a URL (with embedded ticket) OR
+ Provide a URL (without embedded ticket) + password?
sort of. what i'm really saying is:
+ provide a url with an embedded ticket chosen by the user (like your
password suggestion) OR
+ provide a url with an embedded ticket chosen by the server (like
today)
that way the server always has a ticket with associated privileges,
but the ticket string can either be something random or something
memorable.
This doesn't address the problem of users not understanding that the
URL is something they shouldn't post on websites and blogs. if we
have a separate password that is 'out-of-band' as in something you
have to type in that is separate from the link you click on...then
users are less likely to compromise the share because people
understand about not posting passwords in public forums.
The extra layer of security we're offering here...is a security
measure (password) that is de-coupled from the link you click on to
access the share.
To reiterate the requirements and the thinking behind them...
We want to make that password something that is human-readable, ergo
we'd like to use a user-defined password, as opposed to a ticket.
However, we want this to be optional...so we must make sure that even
without the de-coupled password, the share is relatively secure.
ergo, we'd like to
We don't want the user to have to re-publish with a new ticket when
they enable and disable password protection. I can easily imagine
scenarios where users decide to enable password protection after the
fact.
As a result, the URL sharers provide (with or without password
protection) needs to be the same.
Therefore, the URL sharers provide (with or without password
protection) needs to have some 'built-in', 'in-band', 'embedded'
security measure (ie. tickets).
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
