[sword-devel] DRM entries in .conf files

[Michael Rempel]

----- Original Message -----
From: "Chris Little" <chrislit@chiasma.org>
To: <sword-devel@crosswire.org>
Sent: Sunday, December 16, 2001 7:48 PM
Subject: RE: [sword-devel] DRM entries in .conf files


> > Understood. It would considerable effort and time to
> > implement a DRM solution. It would be interesting to think
> > about and discuss though. Don't you think the likes of Thomas
> > Nelson would be more likely to grant access to there
> > translations if we could demonstrate there protection?
>
> I agree.  I'm okay with allowing copyright holders to prevent user X
> from giving their content to user Y.  I'm not okay with copyright
> holders telling user X what he may do with their content once he's paid
> for it, so long as he doesn't violate their copyright.  I don't like DRM
> implementations that allow for content expiration, limiting printing,
> limiting viewing, etc.
>
> If you can think of a good solution that protects the content that can
> fit within our system, I'd love to hear it (assuming you can explain it
> in small words that I would understand). :)
>
> Our current implementation is at least as secure as any of the others
> I've seen.  Our content is really & truly encrypted, rather than relying
> on key files that tell them they should be unlocked.  But our weak link
> is that content is secured by a single key (per module) rather than
> unique keys for each user.  And it's relatively easy to just copy the
> whole tree to another computer (but I think that's probably the case
> with all Bible software).
>
>
> > I understand what CopyrightHolder, CopyrightDate and
> > TextSource refer to, but I am lost on the purpose you intend
> > for License and QuoteLimit. Can you elaborate?
>
> License indicates the type or terms of the license.  Examples would
> include "public domain", "non-commercial use", "permission to distribute
> granted to CrossWire", etc.
>
> QuoteLimit would be the maximum number of verses/chapters/books a user
> is allowed to quote, frequently 500 verses provided that the entire text
> of a single book is not quoted.
>
> > > Separately, I would add a "Writable" field, indicating that a module
>
> > > may be written to.  This would be set for modules like personal
> > > commentaries and modules that are being used in distributed editing
> > > systems.  And possibly a "WriteKey" field to hold a unix crypt()
> > > password, or some kind of MD5 hash if Mike prefers :), to be checked
>
> > > whenever a write operation is attempted.  (But the hash can't use
> > > either the module or the .conf file since both can be modified.)
> >
> > OK, now I'm confused. I thought you didn't want to try and
> > protect the content?
>
> These are just indicators to a front end that they should/should not
> attempt to write to a given module.  If there's no Writable field, they
> shouldn't write.  If there is and there's a WriteKey field, it's
> contents should be used to determine whether a user has permission to
> write to the module.
>
> For example, suppose there's a public distributed editing setup for the
> Leningrad codex.  User A has proven that he has a good command of
> Hebrew.  User B doesn't know the difference between aleph and bet.  User
> A should be allowed to help, but User B should not; so User A is given a
> password and User B is not.  Somewhere along the line, that password
> gets checked against the value in WriteKey to confirm that User A has
> got a valid password for editing the file, so the engine allows him to
> do so.  There's also a really good argument that this shouldn't be
> handled by Sword at all, and the front end should do user permissions
> and authentication independent of Sword. :)
>
> --Chris

I would make the editor generic enough to edit anything.

What about a double key, one for the codex, one for me to authenticate, and
a database to arbitrate in case administration has decided I am no longer
welcome, my password expired etc. The key for the codex is cookie based, the
key for me is password &/or machine cookie. Then a session cookie assigned
by the database (or middle tier if you go there) that tells the editor who
you are, and what you can do on each page of the public editor.

This authentication so it doesnt cost much in the editor, but it knows about
editor content.

As far as dot net resistance goes, I am with you all the way. Limited rights
copyright needs to be resisted, but an alternative that might work well is a
semi-limited copyright that requires re-authentication every so often in a
manner similar to my double key notion above. The internet could provide a
key authentication every 10th session and following until successful, or
until say 20 sessions without authentication were done. These values could
be configurable by the publisher within limits you set.

The result is a resonably portable, reasonably secure copy of the
publication, with single machine license enforcement that can be transfered
in case of a hard drive failure, easy validation of payment, hard to fail
authentication, and makes hacking very hard to do.

Michael