THE PROPOSAL
ISSUES TO RESOLVE
SPRINT 3 PLAN
IMPLEMENTATION TASKS
USE CASES
PROBLEM USE CASES
USER EDUCATION/NOTIFICATION REQUIREMENTS

THE PROPOSAL

Throughout the process of trying to come up with a plan for access control, we have been pulled between two conflicting goals: privacy of content, and making it easy to share content. What we have decided is that in the short-term we need to emphasize privacy over convenience. We need a plan that is relatively simple in design, so we can build onto it, rather than coming up with something very complicated for convenience of the user, when we are not entirely sure we have it right yet. The plan below will require the user to do a lot of the management of items' permissions. While less convenient to the user, it is at least transparent, and hopefully relatively straightforward in concept. Over time we will take measures to improve user experience.

Privileges on Libraries and Items:

• READ
• DOWNLOAD (which implies read)
• WRITE (which implies download+read)
• ADMIN (which implies write+download+read) - You must have admin rights over an item or library to pass on permissions to others.

Privileges on Albums and slideshows:

• VIEW
• MODIFY
  
  
• Album and slideshow permissions are completely distinct from permissions over the items in them.
• You must have READ on any items you put in your alb/ss.
• You must have ADMIN on all items to be able to give VIEW/MODIFY on your album to others.

Item-specific permissions:

• Item-specific permissions can be set from within a library or an album. _\[Not sure about slideshow, or search results?\]_

• Items always still inherit permissions from the library they live in; you can use item-specific permissions to add privileges, but not to take away privileges.
• Album and Slideshow permissions will have NO impact on, or relationship to item-specific permissions. So, if you change privileges on an alb/ss, it has no impact on the items it contains.
• Users must explicitly set permissions on items. They do this by selecting one or more items in the thumbnail window (in either a library or album), and clicking the 'share' icon that we will add to the bottom of the screen, with the other item-level icons.
• In albums and slideshows, there will be the option of applying "batch permissions" on all items.

User Experience Managing Item-specific permissions:

• Items that have privileges independent of their parent library will have a little share icon in the bottom right corner (or in some other way, will have a visual marker so its clear which ones have special privileges). This will make it easier to manage these privileges.
• Selecting an item, and then clicking the item-share icon will bring up the share window, and show existing privileges. User can then add or remove privileges.
  • Users other than the owner should be prohibited from removing privileges from the item owner - even though alfresco enforces this, we should give the user error message, so they know.
• If multiple items are selected, privileges they all have in common will appear, but not privileges that differ. If a single item is selected, all existing privileges on it will appear.
• If the user does not have share privileges over a particular item, then when they click the share icon, they will receive an error. We are unlikely to be able to check beforehand and make the icons disabled if they don't (which would be best); more likely we'll need to let the backend enforce this, and report errors after the fact. This is another area that could use some enhancement in future.
  
  

Items in Albums and Slideshows:
A PERSONAL album or slideshow is one which only its owner can see.
A SHARED alb/ss is one which the owner has shared with one or more users.

• PERSONAL ALB/SS: Anything you can read, you can drag into a PERSONAL album or slideshow.

• SHARED ALB/SS: You must have ADMIN on any items you want to drag into a SHARED alb/ss.

• If you try to share a PERSONAL alb/ss, the IME will check to see if you have ADMIN on all the items in it. If you do not, then an error message is returned saying "you cannot share this as you don't have permission to share all the items in this alb/ss". In some way the UI will hi-lite, or at least list, all the items the user does not have SHARE over, so they can remove them from the alb/ss if they still want to share it.
  • Important future enhancement: should offer a link that says 'Request Access', which would send an email to the owner of that content. Ideally the owner could then simply respond YES or NO to the email, and it would be taken care of. This is not a feature for anytime soon, probably codfish or beyond.

The result is that, unless an item or its library is explicitly made 'shareable', it cannot be shared. Even though this will create some places that are irritating for users (like when they are told they cannot share an album, or copy items because they don't have privileges, and then have no idea what to do about that), for the time being we will hold the privacy of people's content, and not surprising them by sharing things they didn't mean to have shared as the higher priority.

Revoking Privileges:

• In order to be able to take away privileges once they have been given, we will have to make thumbnails private in albums and slideshows. In libraries and search results, thumbnails will be public. There will be 2 different URLs for thumbnails: one is the publicly accessible url, over http, that goes directly to alfresco. The other URL will go to the IME, and will be over https. For example:
  • Public URL:  http://isda-thalia6.mit.edu:8080/alfresco/guestDownload/direct/workspace/TEST/ac05bad4-7cba-11dc-a3e8-abc6d12769f5/thumbnail    (or /medium or /large)
  • Protected URL: https://hst.thalia.mit.edu/item/ac05bad4-7cba-11dc-a3e8-abc6d12769f5/thumbnail   (or /medium or /large)

• If READ privileges on items have been revoked for the album/ss owner, then everyone (including the owner) will see the 'not authorized' icon instead of the image. If ADMIN or WRITE privileges have been revoked, but READ remains, the items will still be visible.
• CASE which illustrates a gap: User B creates an album with items she has admin on, but is not the owner of. Shares with User C. User B's admin privileges are revoked. User C can still see the items in the album. - we decided this is ok; permissions they granted when they could are still there. They just no longer have the rights to grant anyone else permissions in future

• In albums and slideshows, we will not put the URL to the items in the xml. Instead, we will construct the URL from the item id. The images will be served over https, which will have performance implications. But it allows us to enforce the access restrictions in the case where someone grants share rights to a user, that user shares the image with others, it gets into various albums and slideshows, and then the owner of the content revokes the share privileges. In this case, once a privilege is revoked, the item will show the 'not authorized' icon.
  • QUESTION: if User A grants User B share rights, and User B then grants User C share rights, if User A later revokes User B's rights, is User C's share rights affected? NO; User A will be able to see all users that have privileges over the items, so can also revoke C's rights, or not, as he chooses.
  • As a more general rule, any privilege that User B passed on while she had admin over the items will not be affected when User A revokes B's admin rights. The only change is that User B can grant no more rights from that point forward.

Sharing albums and slideshows 

• If the user grants view/modify on the alb/ss, others will be able to see the content even if they do not have read on them, because we will authenticate items as the album owner.
• Removing privileges will have no impact on the item-level privileges that were granted. We should probably have some sort of messaging that reminds the user of this -- to review item-level privileges and make sure they are what they want. We may even want to prompt this before allowing them to revoke privileges, similar to the confirmation when trying to delete things.
  

ISSUES TO RESOLVE

• MODIFY permissions on album poses problems – because we authenticate as the owner (User A), if a second person (User B) is given modify, and drags items to the album (which he can, because he has modify on the album, and is an admin of the items he is dragging), if the album owner does not have read on those items, no one will be able to see them.
  • Possibly we will prompt the user to grant READ on the items, before dragging into the album (they click yes, and we set the permissions on the selected items)
  • However, this does not entirely resolve the issue. We now have a problem in the opposite direction. If User B grants READ to User A, that solves the ability for everyone to see stuff. However, it allows User A to SHARE (grant access to others) the items by granting READ on the album. If we keep strictly to our privacy model, granting READ should not allow them to then share the item with others (which should require ADMIN).
  • Perhaps this is the scenario where an implied permission is appropriate: User B must grant User A (album owner) read. By dragging to an album that someone else owns, the user is implicitly giving others permission to share – they know its not their album. We could also remind them.
  • How does this play out with an equal-ownership sort of situation, where one user is the album owner, the other has modify, and they both want to be able to grant privileges over the items to others? They both need to be admins over the items...

IMPLEMENTATION TASKS:

• UI Changes:
  • Add share button at item level in library and album
  • Album: remove download
  • Ideally, have indication on items that they have individual permissions distinct from the library
  • Clicking on one or more items, can set/change permissions
  • To view existing permissions in order to remove them, need to only click on one image

  • Sharing albums or slideshows: have to check for item-level share (dependent on #2) \[let the backend handle this\]

• IME Changes:
  • Get permissions on multiple items
  • Flag on items - custom permissions yes/no
  • Item level permissions
  • Personal vs. Shared Album (not sure what needs to happen to implement this distinction)
  • Sharing albums or slideshows: have to check for item-level share
    

USE CASES:

User A owns items AND album

• If album is personal to A, there is no impact on item-permissions

• If User A gives READ or MODIFY to others on an album:
  • It will have no impact on item-permissions
  • They can all see the content because we authenticate items within albums and slideshows as the owner of the alb/ss.

User A owns items, has MODIFY on album; User B owns album:

• When dragging items to the album, User A is prompted: "Do you want to allow Album Owner to share these items with others? If so, you can give them ADMIN rights over the items. Or, you can just give them READ on these items.
  • They must select either read or admin; if they select neither, they can't drag the item to the album
  • THIS IS A WACKY IDEA, ONLY HALF-BAKED. ITS THE MOST PROBLEMATIC SCENARIO, AND WE NEED TO THINK IT THROUGH.

SAP & HST:

• Judy uploads files to a library. She creates an album, and gives Jamie MODIFY on it. Jamie makes changes, and then is ready to let the publisher know that they are ready. Jamie cannot give the publisher download rights unless Judy explicitly gives her ADMIN on either the library, or all the items in the album. Jamie tries to share, gets the error message, and goes and tells Judy to give her access. More likely, in departments, share should be assigned with read for departmental users.
• Everyone on the team needs to be an admin of the libraries where the content lives. Once we have groups, this will be very easy to make work.  

Stellar:

• Professor A gathers content from Rotch, and from Vue, and creates a slideshow. She is able to give her students READ on the slideshow, because we will assume that all content that is public is shareable by anyone.
• Professor B has a library, and gives Professor A read access. Professor A takes some content from Prof B's library, and adds it to her slideshow. When she tries to share it, she is notified that she cannot, because she does not own all the content in the library. She must ask Professor B to give her SHARE on the items/library. She must remember that Professor B is the one who gave her the content...
  

PSB:

• User called "PSB-Seller" (or something like that) is admin over all content. All content is readable by public.
• Public User creates an album, and drags images to it. They pay PSB and reference the album name (might need some kind of generic naming/number in albums). PSB should already be able to see all the albums. Maybe this means they go in as super-admin, maybe its some sort of PSB-specific customization. They do a batch-permission on all items in the album, setting DOWNLOAD for that user, and the user can download the items. When PSB wants to restrict access, they do another batch permission assignment, and take away download on all the items.
  • One place for user confusion is that PSB Seller may think that deleting the album gets rid of privileges. Must be educated, so they know to remove the item-level privileges.

Public Domain:

• There was a big party, and 7 people each upload pictures to their personal libraries. All of their libraries are private. One of them creates an album, and gives all 7 people modify rights on that album. Then everyone can drag images to the album. Everyone dragging to the album must give the album owner at least READ on the items. To allow everyone to share it, each person must give all the other people ADMIN on the items (unlikely that they'd want to do this, cumbersome; but could be ok that the owner must be the one to assign permissions to others, in this scenario).
  • Only the album owner can share the album. No one else can.
  • The album owner can only share it with others if everyone gives her ADMIN rights over all their items.

Need to lock down suspected bad content:

• Ownable service has been implemented. If content needs to be locked down, owner's permissions would be removed.
• 2 cases: content is found out to be truly illegal, and there could be legal proceedings; OR content is found to be acceptable, all previous rights should be reinstated.
  
  

PROBLEM CASES:

These are cases that raise issues we need to address, either in our model, or in other ways to avoid certain problems.

• Collaboration in albums is limited in the model described here. If we do not allow "share" to be set on an album, then only the album owner can share the album. This can be a problem for a truly shared album.
• The album owner can only share it with others if everyone gives her ADMIN rights over all their items. This is a problem, because users may want to share, and allow others to see their content, but probably don't want to give others the right to delete the item... If one of those users has read over their library, they could go in and delete the item. MAYBE... we only let the user do things in libraries that match the LIBRARY permission level. So, even if a user has share on an item, it only really allows them to give others read, it does not actually allow them to delete the items. In this way, granting "ADMIN" on an item is implicitly granting a different kind of 'share', that only allows others to read the item. We could even call it "share" instead of "admin" at the item level...

• When a user is given the error message that they cannot share something, because they don't have adequate access, there will not be an easy way for them to know how to do anything about it. I'd like to see a feature in the future where they can click to request access.

USER EDUCATION/NOTIFICATION REQUIREMENTS

• TBD