Sunday, July 8, 2012

Digital Rights Management - Part 1 (Design)

Let me start off by saying that Digital Rights Management (DRM) implementations are generally despised by many users, myself included. If you don't believe me just Google "DRM" and "Stinks", "Sucks", or other appropriate negative word and you will get plenty of hits. The technical press is full of stories about Draconian measures, discontinued services, and software implementations that more closely resemble malware than anything else. In short, many implementations do little to stop piracy but in the attempt, tend to aggravate legitimate customers.

Although I don't like it, I understand the reason for it. Content owners who deliver popular movies, music, software, and books often lose lots of money when their stuff is widely pirated. (Although I don't buy their argument that every pirated copy is a lost sale.) I have worked for software companies where we estimated that there were in excess of 10 illegal copies of our stuff for every one we sold. When such conditions exist, it is perfectly understandable that measures are often taken to try and prevent it.

The main problem is that everyone seems to take a different approach, and most of the implementations are bad. Legitimate customers of digital content are often faced with several dozen techniques to activate their operating systems, application software, and the various forms of digital media content. License restrictions are often hidden deep within some "End User License Agreement" that was written by lawyers for lawyers. Some activations require dongles, constant Internet access, credit cards, or subscription services. The user may need a dozen different UserName/Password combinations to keep track of all their stuff.

Even the user who is willing and able to jump through all the hoops necessary to get legitimate copies of everything on their system, will find it difficult to remain legal or discover what is legal after the fact. Just try and browse through all the files on a large hard drive and figure out what is legal and what is not. If the computer breaks, can you legally transfer your stuff to a replacement computer? If you buy a second computer, how much of the stuff you purchased for the first one can be shared with the second one without an additional license purchase? If you upgrade hardware, operating systems, or change services is the stuff you previously purchased still legal? Can you make backup copies without violating the terms of the contract?

The average user often gets completely lost in the maze and ends up with either illegal stuff or simply never purchases in the first place because the terms were never clear. Staying legal is a huge headache for businesses and individuals.

Users are often left out in the cold when their subscription service goes out of business or the content owner disables a necessary Internet server that enables legally purchased content to continue to be accessed. Some license agreements and software implementations are way too restrictive and you often have to purchase something before you can even figure out what you are buying.

I could go on all day and cite examples of DRM implementations that aggravated me personally or someone I knew, but let me just say that I have yet to see a version that I have liked.

When I designed the Didget Management System, content protection and activation were built into the core architecture. They are purely optional features. The average user can set up a personal Didget Domain with several Chambers and use millions of Didgets without ever wanting to activate any restricted content, but if they choose to, the features are there to support it.

When designing the features, I had to take into consideration a number of factors. I decided that if the features were to gain acceptance and be widely used they had to meet the following design goals.

1) The implementation has to work. Content owners will not release their stuff using this system if it doesn't protect the data from unauthorized access in the vast majority of cases. No implementation is perfect and given enough resources, some people will try to figure a way around its protections, but it has to be effective in 95%+ of the cases.

2) The system must make it extremely easy for the end user to figure out what has already been activated, what is available for activation, and what are the exact terms for each individual activation.

3) It has to provide a single activation process that allows for multiple payment methods. The end user must be able to activate software or  a book using the same technique he used to activate his music or a movie. He should be able to pay for each activation using cash, a credit card, or some kind of account.

4) The system must provide flexible terms for activation so that content owners can provide a variety of ways to access their wares. One time use, unlimited use, limited term (e.g. 24 hours or one month), or a set number of accesses (e.g. 100 uses) are all examples of ways a merchant and their customers may want to conduct business for digital content.

5) The system must provide ways for content owners to allow existing customers to upgrade for a reduced price. It must be able to verify that the customer has a legitimate version that qualifies for the upgrade.

6) The system must provide ways for the customer to purchase content without ever revealing their identity to the merchant. The customer needs the option of an anonymous purchase using cash or an account where the account manager will see that funds are given to the merchant without purchaser information.

7) Any activations must result in the content being accessible for the full term of the contract without any further actions by the merchant. An Internet server cannot be required. Internet access cannot be required. A subscription service does not need to be current.

8) All activations must be valid for a set number of devices. When a user buys a song or a movie, it must play on all his devices without further activations. A simple synchronization is all that should be necessary to share or transfer access rights from one device to another. This mechanism must not work if the device is not one of the user's, however.

9) There are two ways most users are able to get access to restricted content - pay for it directly or get someone else to pay on your behalf (e.g. advertisers). Our system must enable both methods for activation.

My next post will describe our implementation and how it meets the requirements listed above.

Sunday, July 1, 2012

Didget Attributes

In most file systems each file or directory can be assigned a few attributes by applications either during file creation or at a later time. Directories are given the "Directory" attribute. Hidden files are given the "Hidden" attribute and static files are given the "Read-Only" attribute.

It is important to note that each of these attributes are just a mechanism to hint to any application how the file should be treated. Applications can ignore these attributes or change them at any time so they may not accurately reflect the user's wishes for the file or provide any meaningful security for the file stream data or file metadata.

In the Didget world, Didgets may also be assigned a number of special attributes that can be used to identify, search, or perform operations against any Didget. Some of them are like file attributes in that they are merely hints to applications and can be changed at will. Others provide meaningful protection and additional capabilities since an operating system or application cannot change them directly.

Didgets have 32 separate attributes. Some of them provide features that I have not seen anywhere else before. I will enumerate and explain each of them.

1) Prepended. Didgets have the unique ability to add additional data to the byte stream before the first data byte. Data must be prepended in 4096 byte chunks (the block size). Bytes in these prepended blocks can only be accessed using negative offsets. Byte 0 remains the traditional start of the file so that prepending data will not effect legacy applications. This allows extra metadata to be added to any given byte stream without worrying about breaking compatibility with an application that is not addressed to handle it.

2) Versioned. The Didget Manager has been designed to handle versioning of individual data streams. Unlike traditional Copy On Write (COW) file systems that are designed to version everything, the versioning capability in our system can be restricted to a small subset of Didgets. Didgets can have this attribute added or deleted at any time (with proper access rights) so you can turn versioning on or off for a single Didget or a whole group of Didgets. Snapshots can be taken any time the versioning is enabled.

3) Metered. This attribute is a critical piece of our "Digital Rights Management" capabilities. As a side note: I think DRM is generally a dirty word since it has been implemented so poorly (technically and administratively) in so many cases. Any Didget can be classified as "Metered" when it is published by the content owner to become a Public Didget. The terms for activation are clearly spelled out in the activation contract that is prepended to the data stream. Anyone who agrees to the terms can activate any Didget using the exact same set of activation procedures. This means that the process to activate music, movies, software, and books is exactly the same. I will address our whole new activation system in a later post.

4) Point Generator. Metered Didgets are activated using "Media Points". These points can be either bought or earned. Users are able to earn points by accessing Didgets with this attribute. Advertisers can produce digital content (i.e. advertisements) that a user can view or interact with to earn points that can in turn be spend towards any kind of other media.

5) Deleted. When a Didget is deleted, it is assigned this attribute (similar to moving a file to the trash bin). Deleted Didgets can be recovered until they are purged from the system. Purging requires special user rights so an application can delete Didgets but not destroy them.

6) Encrypted. This is just a hint to any application accessing the data that it has been encrypted. The application must be able to decrypt the data in order to use it.

7) Compressed. Just like the Encrypted attribute only for compression.

8) Sparse. Data streams can contain holes. Any Didget with a sparse data stream will have this attribute set.

9) Immutable. Data streams can be set with this "Read-Only" attribute to protect them from alteration. Public Didgets have this attribute set by default. Once this attribute is set, it cannot be cleared. Once immutable, always immutable. If you need a copy that is alterable, you can clone it into another Private Didget and change the copy all you want, but the original remains intact. Since Digits are accessed through their Didget IDs, you can't fool an application into reading your altered copy like you can with files by simply replacing a read-only file with an altered file with the same name.

10) Appendable. Immutable Didgets cannot have their existing data streams altered. However, with this attribute, additional data can be appended to the end of the data stream. Used in combination, it will be popular for logs that want new data added without the ability to change data previously written.

11) Self-Destruct. Any Didget with this attribute will be automatically deleted and purged from the system by the Didget Manager when the conditions for destruction have been met. This can be a specified period of time or a number of accesses. This will allow users to activate (e.g. rent) content for a specified period of time. When the period for activation is passed, the Activation Didget will be automatically be destroyed and the permission to access its Metered Didget with it.

12) Multiple Tags. This is a system attribute maintained by the Didget Manager. It is set when a Didget has two or more tags with the same key attached. For example, a photograph of three people may have three ".person.First Name" tags attached, each with a value corresponding to the first names of each person in the photograph.

13) Single Copy. Didgets with this tag are deleted and purged from the system when they are copied. This creates a software "Dongle" mechanism that enforces a single copy of any given Didget within the system.

14) Disposable. This attribute is somewhat similar to temporary files. Didgets with this attribute can have the space occupied by their data stream confiscated by the system when disk space runs out. An application does not need to come clean them up when disk space is low. This allows the user to fill up their disk with lots of HD video that they may never view without worrying that it will result in a "Out of Disk Space" error. As long as the space is not needed, the video is accessible. Backup policies can completely ignore disposable data.

15) Activated. Metered Didgets that have been activated by the user will have this attribute set. It is not a security mechanism since other measures are checked to insure that the activation is valid, but it is a quick way to see what has been activated and what has not.

16) Quarantined. Didgets that have yet to be scanned for viruses or other malware can have this attribute set. It may result in a warning to the user when it is accessed. (This can also be controlled through policies.)