Two topics for today: DRM and Bresenham's algorith.
(Actually, I'll talk about Bresenham later
to keep it on a separte page.)
First, DRM.
I read an article a couple of days ago where the author claimed that the music companies
giving up DRM on music is a bad idea and will further hurt the music industry. I think he's
probably right. I think DRM is actually really important. I think we really need a strong DRM
infrastructure. The problem is that music is a terrible place to start working on the DRM problem.
You want to know why we need DRM? Well, let's see, has any company lost its credit card
database this week? Anyone stolen a laptop full of social security numbers they weren't even
supposed to have in the first place? If you want consumers to care about DRM, you should use it
to protect information consumers care about protecting! DRM should be used to protect your bank
statements, your medical records, your social securiy number, your credit card number.
If the music industry cared about protecting your credit card number as much as they cared
about protecting their song, we'd be much better off. It's exactly the same: here we have a
piece of digital information that we want to securely give a copy to another person such that only
that person can access it and no one else. No one else should be able to read the original data.
No one should be able to make a readable copy of the data. If the companies that use this data find
the DRM too onerous, maybe we'll finally get better DRM.
- DRM should be used to protect data that everyone - consumers and businesses alike - agrees
is important. Financial records and medical documents are the place to start. Once you have a
workable system in these areas, using DRM in other fields like music will be easy and I think more
accepted by the consumer.
- DRM needs to be ubiquitous, in that it is used everywhere all the time to protect sensitive
and semi-sensitive data. It should be harder to make data public than it is to make it private.
- DRM needs to be ubiquitous, in that it should be a low level service of the operating system
or hardware. Anything that transforms data should probably be aware of it. Perhaps it belongs
at the sound and video driver level.
- DRM will probably require trusted software or hardware. Obviously any system is breakable, but
people are more likely to accept a secure OS (and be interested in protecting their system's
integrety) if the stuff they really care about is secure, not
just the music they want to share with their friends.
I was starting to work on a wishlist of features for a good DRM system. I'll put down my
thoughts, but DRM is hard. I can already see cases where putting two features together allows you
to defeat the system. That's why we need people working on this seriously and not distributing
root kits that crash your computer.
- DRM protection should not require "phoning home".
- DRM protected files should be secure by
defualt. I suspect that every DRM protected file should always remain in its encrypted state, at
least whenever it is on physical media (kind of like EFS). Moving the raw encrypted data should
be easy; accessing its content should be secure.
- I'm imagining a DRM system would involve files encrypted and locked to a person's identity.
Even if someone else gets a hold of the file, without being able to provide the correct identity,
they could not read the file. (This would require a solid identity management system as well.)
- If you could do identity management by fingerprint, then you could keep your files DRMd on
your laptop and even if someone stole your laptop, they couldn't read the files. Your walkman
would have a fingerprint reader to enable it to play digital music. You could take your memory
card and stick it in a friend's car radio. The radio could copy the files to its hard drive but
could only play the songs if you were in the car to give it your fingerprint.
- In the real world, it's difficult to copy things like a book. It's perfectly reasonable to
have lending libraries and used book stores because you can't keep the book and give it to another
person at the same time. You can re-sell your book - it retains some value and you can get that
value back by selling it to another person. I'm sure publishers would prefer otherwise, but I
think people generally agree that purchasing an object generally implies the right to sell it to
another person, since you have to give up the object to do so. It would be cool if a DRM system
could support this. Perhaps you could transcode a file from your ownership to another's, giving
up your ownership by destroying the original file (requires trustworthy software). (How does
digital cash work? Maybe something similar would apply.)
- It's interesting to think who would be the proper owner of a DRM protected file and what
rights you would want to give them. If you wanted to purchase something online, instead of
giving your credit card number and identifying info, you would write a digital check, save it
in a file that only your bank would have permission to read, and give it to the merchant. The
merchant would give that unreadable file to the bank, which would accept it and pay the merchant.
The merchant could not misuse your account information because he would never have it.
- Documents owned by a business could be DRM'd to a computer controlled acount. It could be
checked out by an employee to their personal identity, or their personal business alias. No
employee who did not have reason to see a document would ever be able to read it and it would
provide very strong audit tracking.
- How would you handle medical records? If you used a system similar to the business system
I mentioned earlier, I think it would certainly make HIPAA compliance much easier.
- Of course, if you start using secure documents, then you have to work about key recovery. If
someone dies, all their documents are forever more unreadable. Law enforcement also gets upset if
it can't read other people's files. Never an easy problem.
I wonder how many other people lay awake at night and think about these things?
[
< Prev
|
Calendar
|
Next >
]
| Su |
Mo |
Tu |
We |
Th |
Fr |
Sa |
| 27 |
28 |
29 |
30 |
31 |
1 |
2 |
| 3 |
4 |
5 |
6 |
7 |
8 |
9 |
| 10 |
11 |
12 |
13 |
14 |
15 |
16 |
| 17 |
18 |
19 |
20 |
21 |
22 |
23 |
| 24 |
25 |
26 |
27 |
28 |
29 |
1 |
C o m m e n t s :
(nothing yet)