[sword-devel] DRM entries in .conf files

[Mike Dougherty]

On Fri, 2001-12-14 at 22:37, Chris Little wrote:
> I'd like to propose the addition of some new entries for .conf files,
> relating to copyright and digital rights management (DRM).  They would
> just be informational, and the front-end would have the option to enfore
> them or not (just like Adobe does with PDF's DRM).  And this is just an
> initial proposal, so please make suggestions if you see better solutions
> or additional problems.
> 
> First I propose 4 copyright information entries:
> "CopyrightHolder" to hold the identity of the copyright holder.
> "CopyrightDate" to hold the year of copyright.
> "License" to hold general license identification.  Valid values would be
> Public Domain, Freely Distributable, Non-Commercial Use, Permission
> Granted to CrossWire, Locked, etc.
> "TextSource" to hold electronic edition source identification, such as a
> website, program, or individual.
> 
> Second I propose a set of DRM entries:
> "DRMPermissions" to identify what permissions are to be granted to the
> user, according to a standard format, easily parsed by a program.  The
> permissions I can think of are: read, write, & print.  We should also
> make allowances for verse-based limits.  I propose the following a
> syntax such as "P500W0", meaning the user may Print up to 500 verses,
> Read unlimited verses (since it is unspecified), and Write no verses.
> "DRMWriteKey", "DRMPrintKey", "DRMReadKey" would contain encrypted
> passwords (I propose using Unix crypt() to generate them) for each of
> the DRM permissions-related operations.  Thus, a user could be prompted
> to provide a password in order to print/write to/read a module.
> 
> --Chris
> 

Wow, I haven't thought about DRM in quite some time. Kind of a blast
from the past sort of thing.... Anyway, here are a few thoughts,
questions, comments.

* Would the plan be to implement a Sword DRM solution, or take advantage
of third-party solution (or in the case of Windoze, single party)?


* Once the user has printed 500 times, or they decide they want to be
able to write something, how do they get new permissions or update their
old ones? Do they get a new .conf file? (I don't know what Sword does
about conf file versions, so maybe a version mismatch in this case is a
non-issue.)


* It might be better to keep the DRM information in a separate file
(probably in a separate directory "drm/"). That might address both
issues. If you use a third-party DRM engine the file would be in the
format they expect. If the user wanted to get new permissions or add
onto their existing set, all the application would need to do is
download (and merge) a new DRM license file. Then in the module conf all
you would need is a flag DRMEnabled=[true|false] to indicate that the
app will need to gain access to the drm.conf file (through a plugin, or
natively).


* How are you going to keep the user from changing the permissions in a
text based file? If they have DRMPermissions: P500W0 as a text entry in
their conf (or .drm) file, whats to keep them from editing it and
specifying different permissions, say DRMPermissions: P0W0, or even
using an empty string to allow themselves unlimited access?


* One way to handle the above situation is to use a MD5 hash (or some
other encryption) on certain fields in the {module}.drm file. So for
example the DRMWriteKey would be a hash of the module text, the write
permission scheme, and the users password. This would ensure that if any
of the fields were changed the module could not be opened.


* You are going to need a way to keep track of how many times the user
has printed, read, or wrote a verse. And you will need keep the
information from prying eyes (and hands). One way to solve this is to
come up with some sort of key format that is cryptic but parse-able.
Something like "499@QfjtWQh456KDir98BFBBFklW". The "@" symbol (or
something else you know is not going to be in a MD5 hash) delineates the
count from the hash (which could be made up of the permissions, count,
and password). So the file may have the following line:

DRMWriteCount:499@QfjtWQh456KDir98BFBBFklW

Then if the user changed "499" to "001" the module would not open. But
if they changed it back to "499" they could once again open the module.


* It's going to be pretty tough to enforce the per-verse rules. Most
apps (that I am aware of anyway) don't show just one verse at a time.
Depending on how the user has things arranged in the app they could be
viewing anywhere from 5 to 20 verses at a given time. Then there's
printing and saving to deal with in the same way. If it's per-verse
permissions there is going to have to be a lot of interaction between
the app and the DRM API/Module. You don't want to nick the user for
viewing previously viewed verses again (that would really bite since I
am constantly going back a forth between two or more verses). As an
example, every time the app is resized a verse count will have to be
sent to the DRM module. But not just all the verses because they may
have viewed some of them previously. So only a verse count that is the
different between the number that was already in the viewable area and
the number that is currently in the viewable area. And that is just on a
window resize event. Think about the level of complexity switching
between chapters and/or books, or searching, or whatever the app does
that may present a verse (or part of a verse-- which is another issue
all together). Another thing to think about is if the user only wants to
read 1 John 1:7-9, but all 10 verses get displayed. So is their verse
count going to incremented by 10? Should they get nicked for all 10
verses, or should they just get nicked for the 3 verses they wanted to
see? If it's only the three, what's going to keep me from entering 1
John 1:1 and reading the entire chapter, knowing that I am only getting
dinged for the one verse? That wouldn't be fair to the copyright holder.

Maybe a better way is to enforce permissions on the chapter (this would
work, at least in GnomeSword since it only presents a chapter at a
time), book, or even module. What would be even better is to give the
copyright holder the option to specify the granularity of the
permissions. In that case your permission syntax could have a two char
prefix:

    BP500 = book print 500 times.
    TW0   = translation write unlimited.
    CR100 = chapter read 100 times.

You could even go all out with something like:

    B01C01RWP500B01C00RWP0 

Would translate to Genesis 1 can only be viewed, printed, and/or saved
500 times, but all other chapters in Genesis can be viewed, printed, and
saved unlimited times. (But that's just cool stuff to think about, not
really practical in the real world, sorry about the tangent ;-).


Don't get me wrong I am not bashing DRM at all. In fact it may be the
only way we will be able to convince some copyright holders to allow
certain modules to be unlocked for the general public. I am just putting
stuff out there that will need to be thought about and addressed. In my
opinion the more secure you make the DRM the better chance you are going
to have in convincing copyright holders to grant access to their work
through your app. I don't really want to lock down the Word, but if it
will make the copyright holders happy so they allow the modules to be
included in the applications, it's better than not having them at all.

Another tangent: Can you tell I like MD5? In my opinion it's a good way
to validate that certain fields haven't been modified without storing
extraneous information (like passwords, checksums, and the like).
However, it is really bad if you want to be able to get information back
out. If the user lost (or forgot) their password you couldn't get it
back for them. You would need to regenerate a new one (and a new
{module}.drm file in this case).

/mike



-- 
******************************************
 Mike Dougherty -- Java Software Engineer
******************************************
 A banker is a fellow who lends you his umbrella when the sun is shining
 and wants it back the minute it begins to rain.
 		-- Mark Twain