Is DRM in scope? (was: PaySwarm and illegal sales? ...)

On 08/22/2011 03:56 PM, Steven Rowat wrote:
 > On 8/20/11 9:02 PM, Manu Sporny wrote:
 >> Requiring a secure database where works are registered sounds like a
 >> centralized solution, or at least a solution that requires some sort
 >> of centralized control.
 >
 > Yes; and perhaps that will be necessary in the long term.

It /may/ become necessary for people that want to place very strong 
restrictions on the content that can be bought and sold online. Let's be 
very clear - you are talking about the enforcement of Digital Rights 
Management (DRM). There has not been a single technological DRM solution 
that has been successful at preventing the duplication of copyrighted 
material. I believe that creating a DRM mechanism (CSS, HDCP, AACS, BD+) 
is not the goal of this group - creating a universal payment standard is 
the goal.

That is not to say that someone can't come along and build a DRM 
mechanism on top of PaySwarm. DRM is a decision that the content creator 
and those that represent content creators must make based on their 
business model.

Please note that I'm not making a value judgement on the use or lack of 
use of DRM. I'm purely making a technological point that there is no 
known technological solution to DRM. I don't believe that there ever 
will be a technological "solution".

You will find that many content creators are discovering that they can 
get more customers without DRM than with DRM. Additionally, once a 
customer has access to a stream of bytes, there is absolutely nothing 
that you can do (today) to prevent those bytes from being duplicated.

The other issue with DRM is that we absolutely shouldn't place that sort 
of centralized control mechanism into the core protocol as it will 
enable gatekeepers on the network from day one. The gatekeepers would be 
the body that manages the centralized database. We have seen what 
happens with the Certificate Authorities - we would be wise not to make 
the same mistake on the Web again:

Trust Agility
http://blog.thoughtcrime.org/ssl-and-the-future-of-authenticity

Having a central authority will make wide and rapid adoption far less 
likely. What you are describing is the equivalent of requiring every 
single person on the Web to register their web pages with a central 
authority before they are allowed to publish those web pages. Imagine if 
we required that of publishers on the Web in the beginning. We wouldn't 
have the Web.

Even if this was an opt-in mechanism, how do you enforce that software 
developers build that mechanism into their software? We can't assume 
that everyone is going to follow the rules and play nicely and the only 
recourse we have today are the courts, governments, and copyright law.

All this to say that I don't think that DRM should be a part of the 
first set of specifications. I believe that even if we end up spec'ing 
some DRM mechanism, that it'll be broken before final specification is 
shipped.

What we should talk about, however, are certificates of authenticity 
that acknowledge that what you are about to purchase has been verified 
and is being offered by Sony Pictures, or Universal or Pixar. That 
ensures that when the digital contract is signed and the money leaves 
your account, that you have a verifiable record that you purchased the 
content from a valid source and you have a valid license to do what you 
want to with the content. This is different from DRM - it is effectively 
a certificate of authenticity and is important when attempting to access 
other material, using that certificate of authenticity, or when trying 
to prove that you paid for a particular piece of content in the 
unenviable position of having to do so as a result of a court proceeding.

PaySwarm absolutely does provide this certificate of authenticity 
mechanism as it is implemented today.

-- manu

-- 
Manu Sporny (skype: msporny, twitter: manusporny)
Founder/CEO - Digital Bazaar, Inc.
blog: Uber Comparison of RDFa, Microformats and Microdata
http://manu.sporny.org/2011/uber-comparison-rdfa-md-uf/

Received on Saturday, 27 August 2011 17:44:04 UTC