This wiki service has now been shut down and archived

From ESIWiki

"Digital Rights Management" has had a very poor press. It generally refers to techniques used by media companies - creators of digital music or movie files - to prevent unfettered copying of their content. DRM's bad press deserves taking seriously, and perhaps my topic here needs an entirely new name, as a result!

However, the same kind of ideas have much broader potential, with goals that many would judge much more socially-relevant:

• Various software vendors have toyed with "self-destructing email" which cannot be forwarded to third parties, and documents which cannot be opened outside a certain company's intranet. These are typically very weak protections right now, but they point to real needs that many people have.

• There are many scenarios in which self-destructing data is quite desirable: whether to avoid forensic analysis by attackers (erase your hard disc before disposal), or to avoid violation of privacy (by employing the digital equivalent of a shredder, as soon as data has been put to the use it was intended for), or, indeed, to simplify regulatory compliance (though regulators are increasingly requiring long-term retention of logs).

• When I upload a photograph to Picassa, or Flickr, or Facebook, I immediately loose control over it: anyone (typically either "friends" or "world") may take a copy, and re-export the photo to another photo sharing site -- now accessible to their "friends" rather than merely mine. I might not wish this to happen -- perhaps because it violates my copyright; perhaps because it leads to potentially sinister uses for family photos; perhaps just because it is another invasion of my privacy.

• Concerns about, say, experimental data, or software, are quite similar to those described above for personal photographs. In some kind of collaborative project context, I may wish to share movable resources, but retain control over their use: whether simple copy protection, or more elaborately, that they might be used with some software and not with other software; that those permissions might expire in time, or when the collaboration ends.

• A particular case of the above arises in short-term medical collaborations: many parties may have short-term access to patient notes; we would wish to ensure that such access is limited to the proximate purpose of the case conference.

• Certain such applications have added complexities of regulatory compliance - which may require strong logging and audit capabilities - or the data itself might need to be held in long-term archival storage, with the expectation that an authorized party extracting data from the archive should be able to access the protected data (so, for example, an ephemeral encryption used for my holiday photos might not be suitable for attaching controls to clinical trials data - but some control is likely to be necessary!).

The intention of this page is that it should develop to be a paper on the nature of DRM requirements for eScience. In that case, the foregoing would need to be expanded, and where possible, referenced. A subsequent section would deal with architectural issues: integration with suitable identity management regimes, trusted computing used for enforcement, the nature of the key management service, issues like backward- and forward-secrecy for dynamic collaborations, and so on.

Input is welcome. Please indicate your changes clearly, if you want to be credited in (or an author of) the paper.

(This is work in progress in the Trust and Security in Virtual Communities theme.)

Example

Here is a nice paper describing how the MPEG-21 standard can be used to apply rights management to patient records.

--Apmapm 04:18, 30 January 2008 (GMT)