<Cosmo folks, please scroll down to look at the list of Questions.>
I talked to Jeffrey and Morgen about all things read-only and we came
up with the following proposal:
Plugging the Read-only Security Hole:
As we've talked about in the past, Cosmo moving to an item soup
creates some interesting scenarios around read-only sharing.
+ User A shares a collection read-only with User B.
+ User B adds items from the read-only share to a different
collection and publishes it to the server.
+ All of a sudden, User B can edit items from User A's read-only
share *and* sync those edits to the server, which eventually make
them back to User A!
Why does this happen?
1. On the desktop, read-only-ness is not tracked on a per-item basis.
Instead, items inherit read-only-ness from the collections they
appear in. As a result, read-only items become read-write-able, as
soon as they are added to read-write collections.
2. Cosmo is now a giant soup of items. Instead of storing items with
the same UUID redundantly in separate collections, an item that
belongs to multiple collections exists once on the server. This is
great because it means that we no longer have to rely on Desktop
clients to propagate edits on an item across all the collections that
item appears in. However, this also means that if User B edits one of
User A's read-only items via their read-write collection, the server
can now connect the dots and User B's edits will find their way back
to User A's read-only share. Gasp!
Thankfully, there is a relatively easy 'hack' we can do for Preview
that Jeffrey almost has working. We have logic on the Desktop that
iterates through all of the collections that an item belongs to and
checks to see if they are read-write or read-only collections.
Previously, we were liberal. If an item belonged to a read-write
collection and a read-only collection, we allowed the user to make
edits. That was before Cosmo acquired the powers necessary to
propagate changes to items across all the collections it appears in
on the server. Now that Cosmo is an item soup, we're going to be more
conservative on the client side. If an item belongs to both a read-
write and a read-only collection, we will always disallow the user
from making edits to that item.
We realize that this would create funny edge cases. For example:
+ User A shares a read-write collection with User B.
+ User B takes some of the items from User A's read-write collection
and adds them to a collection they share back with User A, read-only.
+ All of a sudden User A can no longer edit some of their items
because they re-subscribed to their own items via a read-only share.
However, we don't think this is a big deal. This is an edge case and
in any case, it's simply an inconvenience whereas being able to edit
read-only items is a serious security hole.
Questions:
+ Are there any concerns about going down this path?
+ How should we address this problem for the Hub UI? Can we do
something similar to what is being proposed here for the Desktop? Or
should we just punt this to Post-Preview? It seems like it's really
more of an edge case for the Hub UI because in Preview, users will
not be able to add items from one collection to another. The only
time this problem will come up is if a single user is subscribed to
the same item via 2 different shares, 1 read-write and the 2nd read-
only.
===
(Dis)Allowing Local Edits to Read-Only Items:
We would like to punt this feature to Future for 2 reasons:
1. If we allow users to edit read-only items and the items have been
added to read-write collections, we re-open the security hole we just
patched up with the proposal above. While those edits won't be synced
up via the read-only collection, they will be synced to the server
via the
2. It's unclear there are any compelling use cases for the feature as
it exists today. We all agreed that what you really want is the
ability to privately 'annotate' shared items (read-only and read-
write). Annotate meaning, ADD your own 2c to shared items, not be
able to destructively edit the item and have it potentially get out
of sync with the version that's on the server.
So we will want to revisit this functionality in the Future with the
following in mind:
+ Expanding the notion of 'local edits' to read-write items;
+ Providing a forcing function to prevent users from accidentally
committing destructive edits to shared items;
+ Providing visual feedback to distinguish local edits from what is
shared.
This means, the Lock button should just disappear from the mark-up
bar! And the pencil with the x through it should stay as an un-
clickable icon.
Mimi
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
