(keitai-l) Re: iAppli Piracy

From: James Santagata <jsanta_at_audiencetrax.com>
Date: 07/15/03
Message-Id: <5.1.0.14.0.20030715124049.00a7dbc0@audiencetrax.com>
At 04:07 PM 7/15/03 +0200, you wrote:
>There is a lot of debate about DRM and piracy (P2P, post-Napster, Kazza =
>etc, etc.) and how this as a business issue is blocking the deployment =
>of data services in Europe. This (the logic goes) is because content =
>providers e.g. Java games suppliers, and aggregators e.g. Bodaphone =
>Live, are afraid of piracy eating into profits. One proposed solution to =
>this is so-called DRM - digital rights management - for which a standard =
>is being developed inside the OMA.
>
>My question is how does piracy and DRM related issues affect the data =
>market in JP? I would be very interested on the opinion of the list as =
>to what really happens in JP about this 'problem' and how the JP =
>experience may transfer to the ROW (rest of the world).

Whatever the medium (desktop, mobile wireless, STB, packaged media), there
are a whole host of issues related to DRM. First off, you have to ask yourself
what objective(s) will using DRM serve?

To offer some level of protection to the content for your 
monetization/business reasons
or just to assuage whatever fears the content providers have about their 
content being
"pirated" or freely shared (that is, to get the content providers to put 
the content out there)?

In the past, I've worked with a number of DRM vendors in the digital media 
space and found in almost case (every case?) their DRM "solutions" offered 
very, very little true protection even in the most modest of relative terms 
-- forget about anything even remotely approaching "absolute". Unless you 
want to talk about the absolute disaster that was known as Liquid Audio.

Worse, with these "solutions" or techniques, it became clear that the more 
"relative" protection
they offered the more using this DRM greatly increased the time and costs 
of creating media, managing media and distributing the media.

Even worse, some of these "solutions" introduced additional points of 
failure, reliability, availability, dependencies and even more points for 
hackers to attack to get at content, customer accounts or disrupt the 
services. This is especially true where key servers are utilized.

And no matter how "transparent" this DRM was supposed to be on the consumer 
side it meant one thing - more hassles for the consumer when something went 
wrong (things
always go wrong) and customer support issues - meaning more costs. And, in 
almost every case, the more transparent and strong the DRM is for the 
customer the more complicated technology it is again increasing support and 
implementation issues.

All of these issues translate to real-world costs and the question will 
eventually arise, "Hey, who
is going to eat them?"

Are they going to get passed on to customers and if so, will customers just 
accept them or balk and walk away?

In some if not many of these cases, one only needs to have a product that 
offers "DRM"
(with no definition as to what that is or a benchmark to rate them against) 
to blow some smoke
up the content providers skirt to get them to license or make content 
available.

In that case, my advice is to go for the absolute cheapest, weakest but 
stable hassle free
form DRM you can find.

If I were to create or license a DRM system, my criteria would be:

- cheap cost
- weak protection (stronger protection usually more cost, more hassles, 
less stable)
- stable
- hassle free (creator/publisher & consumer)


-- James
Received on Tue Jul 15 22:57:33 2003