Sharing Meeting Notes

• Sheila, Morgen and Mimi met to figure out what sharing format issues (from the thread discussion) will impact the UI.

Morgen - summary of where we are in the sharing format discussions

• Reached an agreement that we would not move to a "soup" model data store in the Beta timeframe.
• Won't focus on advanced feature support in the short-term.
• Instead, sharing format re-write will center around fixing the problem where Chandler is publishing both cloud XML and ICS files.
• Basically, in the short-term we are only solving the dual resource problem.

Implications for planning and implementation

Secondary Items

• We will address issues related to sharing secondary items in the 1.0 timeframe, but not for Beta
• This means that for now, a single secondary item (1 UUID) will be duplicated and stored separately in each resource that points to that secondary item ie: If I have 2 events with the same location, the 1 location item will be duplicated and appear as separate items in each resource on the server.
• When we move to the soup model data store, we will be able to get rid of this duplication and have different resources point to a single instantiation of a secondary item.

Implications for design and user experience

Tags, Labels, Collections and Collection names

• We will not be sharing labels (e.g. tags and user-define attributes)
  • This means we will not be supporting some of the more borderline small workgroup / Web 2.0-like usage scenarios (e.g. A group of people tagging and managing a mailing list or RSS feed together)
• However, we will continue to share the 'collection tag' (aka the tag that IS the collection that is being shared); and
• We will continue to support allowing users to change their personal display name of the collection without affecting the collection display name for other sharees. (ie. A shares their 'Work' collection with B. B renames it 'AWork' while A's collection name remains 'Work').
• However, changing the display name of the collection does not change the UUID of the collection. Therefore, if B later receives items from A via a different share (ie. Office) and those items happen to belong to the original shared collection ('Work'), those items will auto-magically point to the right collection ('AWork'), even though B has a different collection name ('AWork') for this collection than A ('Work'). This functionality works today.

Sharing secondary items - The Sharee's experience

• We will share secondary items (e.g. Contact and Location items that are linked from shared items)
• If/when we provide affordances for editing and manipulating secondary items (e.g. Right-click to edit a contact, Drag a contact to the sidebar and/or summary pane to add it to a Collection, etc)...we will need to make sure we de-activate these affordances for secondary items that the user did not create and/or were not explicitly added as primary items to a shared collection they subscribed to.
• We need to do this primarily to prevent sharee's from accidentally editing contact and location items that the sharer never intended to share with them.

• In the short-term we will not attempt to reconcile shared secondary items with pre-existing items in the sharee's repository (e.g. User already has a contact item for a secondary contact item they receive via a subscription to a share.) However, we recognize that this is something we will need to support this in the future, so we need to make sure we don't do things that prevent us from implementing this functionality later on.

Scooby Update Issue

• If we have an event on multiple calendars and a Scooby user updates this item on one particular calendar, the changes won't get reflected in the other collections until the Chandler user synchs.
• This isn't that bad for Beta since we are focussing in on a casual collaborator for Scooby not a Chandler user viewing their calendars remotely. The users' workflow will be more structured. This problem is a further incentive to go with the casual collaborator for Beta.

Implications for Security

Problem-space overview

There are essentially 3 levels of trust in our current model:

1. Trusting the user - Making sure sharees don't accidentally violate the security expectations of the sharer (e.g. Sharers don't expect sharees to be able to edit secondary items that they didn't explicitly share.)
2. Trusting the remote client - Making sure that we can prevent malicious hackers from editing items and collections they weren't granted access to edit.
3. Trusting the server - Making sure the server can detect and reject invalid edits.

In the Beta timeframe, we must address 1. However, we will be unable to address 2 and 3 completely. We think we can live with this for the following reasons:

1. We believe the scenarios in which a malicious hacker gains access to make unauthorized edits are heavily mitigated:
   • I need to first gain access to a read-only share.
   • Then, I can figure out the UUIDs of items (primary and secondary) that are contained in that share.
   • Then, I need to gain access read-write access to a share from the same sharer.
   • Then I can create new items with the same UUIDs as the items that I technically only have read-only access to and replace the sharer's version of these items with my own.

Possible future solutions

• When we move over to the soup model, can Cosmo keep track of UUIDs for individual items? If a client tries to sync and upload 'newly created' items that have the same UUID as items that are already on the server, these 'new items' should be automatically rejected.

Assumptions

• We are designing for small workgroup sharing where tickets are rarely handed out to more than 10-20 people at a time. We need to warn potential users that the Chandler system is not secure for providing semi-public access to calendars (e.g. sending tickets out to 300, 3000, 30,000 users).

-- SheilaMooney - 04 Aug 2006