[Design][Proposal][Cosmo] Editing Read-only items

[Mimi Yin]

<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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osafoundation.org/pipermail/design/attachments/20070501/0dc98d97/attachment.html