Item Soup and Read-Only Sharing

Just like in your personal Chandler Desktop data repository, items are stored on Chandler Hub in what we call a big item soup. This allows us to do neat things like figure out that a single item that is shared in multiple collections so that editing that item in one collection updates that item in all the collections it appears in. However, it also has interesting security and user experience side effects. We hope to revisit how items are stored on the server post-Preview. Design Discussion

To plug some of the more gaping security holes, we've locked down on view-only sharing to ensure that users don't unwittingly edit data they were never granted access. If you receive an item via a view-only share, you can never edit it, even if you add it to a different collection where you have view and edit privileges. This leads to the strange scenario where you might actually lose edit privileges on an item you created and published, if you share it with others with a view-only sharing URL and then they share it back to you with a view-only sharing URL.

Sharer shares 2 collections to Sharee, 1 RO and 1 RW, Sharee adds RO items into RW collection and can RW on all the RO items

• User A publishes collection C1 and C2; A puts event E1 into C1, and puts event E2 into C2
• User A gives user B a RW ticket for C1
• User A gives user B a RO ticket for C2 (because he doesn't want B to edit E2)
• User B subscribes to both
• User B copies E2 into C1, modifies E2 and syncs
• User A syncs and sees the change to E2 in C1 (and also in C2)

Sharee subscribes to RO share, drags RO item to another collection and publishes 2nd collection. RW subscribers to the 2nd collection can edit RO items added to 2nd collection. Original sharee can also edit RO item via Chandler Hub UI.

• User -Nebuchadnezzar shares Item 'Lunch with Nero' with User-Batsheva via the read-only Collection 'Nebuchadnezzar's Collection'.
• User-Batsheva adds Item 'Lunch with Nero' to another Collection 'Batsheva's Collection' which she shares with read-write access.

Question: Does it matter if User-Batsheva subscribes to 'Batsheva's Collection' read-write or publishes 'Batsheva's Collection'?

Any changes User-Batsheva makes to Item 'Lunch with Nero' will get propagated back to User-Nebuchadnezzar even if User-Nebuchadnezzar does not subscribe to 'Batsheva's Collection'.

via Edit/Update workflow

I don't think this one is such a big deal because Users A and B know that User C has the item. And User C clearly has some relationships with User B. It's just a little disconcerting because no explicit sharing relationship has been created between these 3 users and User C may be completely unaware of User A's existence.

• User A shares a collection read-write with User B using Chandler Hub Sharing.
• User B sends some of these items to User C.
• User C edits one of them and then uploads the item to Chandler Hub in a completely different collection that neither User A nor User B knows about.
• User A and B see User C's edits, even though neither of them are aware of the fact that they are 'sharing' with User C, just that User C has received the item via Email.
• User C is unaware of the fact that User A and B can see their edits, even without them explicitly hitting the Update button.

Funny Read-Write Scenarios

• User A shares a collection with another user, B
• User A decides to stop sharing that collection with User B and unpublishes the collection
• Even though the 'share has ended', User B still gets to keep the items in their local version of Chandler Desktop
• However, any items that make their way onto the server through other shared collections will still be 'shared' between A and B, even though User A and User B no longer share any collections.

• User A shares a collection with another user, B
• User unpublishes that collection
• However, both User A and User B have put items from their previously shared collection onto Chandler Hub via other shares
• User A and User B end up 'sharing' those items even though they have no explicit sharing relationship with each other

Edge Case Scenarios

Unsubscribe and Publish

• Subscribe to read-only share published to Chandler Hub
• Unsubscribe
• Publish collection to Chandler Hub
• Now I can edit formerly read-only items and my edits sync back to the person who originally shared them with me, read-only.

Re-sharing

• User A shares collection with me read-only.
• I add items from that collection to another collection and publish that to Chandler Hub.
• I send read-write ticket to my friend.
• Now my friend can edit items User A's read-only items.

Sort of Okay Scenario

Write access via Friend-of-a-Friend Chandler Hub Scenario

• Chandler Hub User C receives the same item via 2 shares from different people: Users A and B. A gave the Hub user read-only access and B gave our Hub user read-write access.
• A's confused because the Hub user can edit this item they
• But we think this is okay because A did grant read-write access to B and B then granted it to C. Definitely a little confusing, but chances are it's not a complete violation for User C to be able to edit an item of User A's.

Possible solutions

Solution	PPD	Chandler	Cosmo
Release note the issue for preview	OK	?	?
Store an item in multiple collections as two (or more) distinct items	OK	OK	Not OK
Segregate the server item soup by account	OK	?	?
No item soup in the server	OK	?	Not OK
Only allow the owner of an item to add/share it into multiple collections	Not OK	?	OK
Rely on desktop client sync to resolve problems with items in multiple collections	OK	?	Not OK
Per item access control	OK	?	OK

List discussions

• http://lists.osafoundation.org/pipermail/design/2007-March/006628.html
• "more fun with items in multiple collections" on Design: http://lists.osafoundation.org/pipermail/design/2007-March/006582.html
• "more fun with items in multiple collections" on Cosmo-dev: http://lists.osafoundation.org/pipermail/cosmo-dev/2007-February/002872.html
• "items in multiple collections and eimml" on Cosmo-dev http://lists.osafoundation.org/pipermail/cosmo-dev/2007-February/002869.html

-- MimiYin - 16 Mar 2007