D-R-Aime?

... and other observations
What is DRAime? It's a blog that talks about D, R and ...M! I know what the D stands for, I know what the R stands for, but I have yet to understand what the M is for.
Management? Mismanagement? Misery? Mystery? All bets are on!
(For those who don't know, Aime, in french, is pronounced M and means to like - which gives us DRM)

Saturday, July 30, 2005

When Hillary Rosen is on your side, you know something is weird...

From this article:

"The problem is that the iPod only works with either songs that you buy from the on-line Apple iTunes store or songs that you rip from your own CD’s," Rosen writes. "But . . . other music sites have lots of music that you can’t get at the iTunes store. So, if you have an iPod, you are out of luck. If you are really a geek, you can figure out how to strip the songs you might have bought from another on-line store of all identifying information so that they will go into the iPod. But then you have also degraded the sound quality. How cruel.
It's a little bit like the DVD+R and DVD-R fight, it's a little bit like the VHS vs BETA fight, but with one exception. There are multiple DRM solutions from Apple, Microsoft and Real to name a few. Compatibility is definitely not a guaranteed right. That would clearly be a downgrade from CD days, but I'm sure everyone knows that. One reason why I believe Hillary does not like the Apple model is that they kind of keep it for themselves.

Friday, July 29, 2005

Cool idea...

I like this idea...

Thursday, July 28, 2005

Copy paste?

A few days ago I was having a discussion at my workplace about Windows networking. The issue was, when it is recommended to use a workgroup and when it is recommended to use a domain.

We have bought the exam cram books on Windows Server 2003. One thing I like about those books is that you can get the digital version on the cd that comes with the books. I opened the pdf file and started hunting for a passage that I liked.

I found it, but trying to copy paste a few lines of text proved to be... impossible. They had disabled the copy paste functionality. The best I could do was to copy paste the screen and include the bitmap in my email... or recopy the text.

I'm not sure what the moral of the story is, but clearly the M of DRM does not stand for Managing expectactions.

Monday, July 25, 2005

Fighting for what exactly?

Sometimes, I think it's really easy to lose track of what is at stake in this "Digital Rights" issue. For example, it can sometimes be tricky, even very tricky, to differentiate between what is better for the common good and what is really only better for our own person. In this debate, I think we often lose focus on what the real issue is. For example, why is it so tempting to be a "geek" and to be against all form of digital restrictions? Is it because it's cool? Is it because it's fair? Is it because geeks have no vested interest in the companies that support digital rights?

A few years ago, Divx, the DVD format that had special "features", died. A cause for celebration? I'm not sure. Although I'm pretty sure I must have been happy, if you strickly look at features, Divx was a good thing. Why not have, in addition to all that DVD brought us, some flexibility in terms of time. Why are we willing to go to the movie theater to see a movie, pay 10$ for something that only lasts 2 hours, with no opportunity to pause or restart the movie, yet a medium like Divx did not sound appealing?

I think the answer lies in the word "trust". Let me make an analogy:

When you think about a criminal court case, the standard is to be innocent until proven guilty. The has to be proved beyond resonable doubt. Clearly, it could be the reverse. Why not assume people are guilty and lower the treshold to having resonable doubts that the person is actually guilty?

It works both ways. I think the same issue lies in the digital world. We can assume people will abuse the system and that the system will not be able to defend itself or we can assume that people will respect it and that the system will be resilient enough to deal with the problems. If we think the former, then we want to tip the balance on the other side, and implement things like DRM or software activation. If we think the latter then we think those serve no useful purpose.

Of course, we must not forget the overall picture. Which way does the balance tips? All the limitation tools make the balance tip on the side of those that need leverage to protect their property. Not having those tools tips the balance of the side of those that refuse to give that leverage.

The thing is that once the balance tips, it's very hard to ensure it only tips "so far".

Think of it as tug of war game: there is no way the cord will stay in the middle. The knot (or flag or whatever is in the middle) is going to be on one side. The problem is, once it's on that side, can you really ensure it doesn't go all the way to the "other side". You can't... so you assume it's safer for you to keep the cord on your side, and keep control of what is going on.

And I have to say that's what I am fighting for. I want to not only keep the balance on the side of the people that fear these tools, but I also want to keep the cord near the middle so that both side stay "in the game". I think DRM and similar technology have a place, I think that they can even bring great features (like the ones DIVX) brought, but unfortunately I'm worried that if we let go of the balance we might completely tip the balance in a way that I just can't stand.

I fight for a fair system, one that keeps everyone happy and that slightly tilts on the side of individual rights. I don't want a chaotic world, but I don't want a world that controls me either.

It's give and take, but can we please take a little bit more than we give away?



Thursday, July 21, 2005

Legal P2P, part 4

One topic I wanted to discuss was the topic of recalls. Consider this: What happens if you suddenly feel the urge to listen to your song, when somebody has it borrowed. In the basic system I have described so far, you would be out of luck. The best you could attempt would be to try to find the user that has your file checked out but it would not be garanteed that you could find him.
There are some solutions though:
The most obvious one would be to borrow somebody else's file. You could request a short borrowing cycle, or a longer one.
If we moved to a centralised system, the main server could receive your recall request and execute it when it would find the person that has your item checked out.
The third solution would involve DRM: all songs could be encoded with DRM that would "phone home" everytime a file needed to be played. This way, you could revoke the license of the person that borrowed your file and wouldnt have to worry about the other person connecting or not connecting to the network to respond to your request.

Tuesday, July 12, 2005

Legal P2P, part 3

Today I will write about how data would be protected...

This is something that might be fuzzier than the rest of the other topics. Let's just state something that might be obvious to some but not all.

When a particular user has access to data and to the key that locks this data, it's very hard to prevent that user from manipulating the data. This is a fundamental problem with DRM system.

Imagine you give someone a box that is locked. Can you just say "Don't unlock it" and feel confident the box won't be unlocked. How about if you left the key to the lock hidden in his house and said: "don't look for the key!". How effective would that be? It clearly wouldn’t be very secure. A few methods come to mind on how someone with the locked box and the key could circumvent the lock. One way would be to find the key. The other would be to pick the lock. There are others. The person could wait for you to come in the house and see where you take the hidden key from. Even more effective, the person could destroy the box to see what is inside, bypassing the lock in the process.

DRM systems suffer from the same problem. For audio, the bottom line is that you can always record the sound that comes out of your computer and re-encode it to make it a new unprotected file. This is the same as destroying the box. Yes, you might damage the contents, but at the end, you have the contents of the box.

The whole point though, is to discourage casual copying. Make life hard enough for most people that most people won’t care enough to go out of their way and “destroy the box”. My system would try to do the same; life would be hard enough for people that want to easily hack it yet would still be ultimately hackable. The reason why I am not that stressed is that at this moment, there are competing technologies that are clearly more suited for people that want to abuse the system.

My system would be in constant motion. I want to not only have a key within the system, but a bit like polymorphic viruses, I want the system to constantly be updating itself and the key to prevent casual abuse.

Files would be stored in a virtual drive. Inside my virtual drive, I would have data that would constantly be on the move. I wouldn’t store the stream in a big file with a known extension. Instead I would constantly change the key and re-encrypt the system as a whole. Clearly I wouldn’t be able to change all the data all the time. What I would do is simply encrypt one block of a song and then move to the next song. This way, you always have a hole within the data stream. The keys would be stored across that large space. Hence, a person trying to hack the system would need to find the locations of those keys and would need to be constantly doing that because all files would have individual multiple encryption keys. I believe this would make the system hard enough to hack yet would keep all keys local, which is essential for a system that is not centralized.

Monday, July 11, 2005

Legal P2P, part 2

Let's go over some of the details of the system described in part 1.

You might wonder, what would happen if the person that has the file "checked-out" refuses to return it. My proposal would be that the system would essentially render the file useless. I mean, what happens if you lend a cd to a friend and that friend loses it? The cd is gone (but not your friendship - hopefully).
Now, nothing would prevent you from reimporting the file into the system, but the point would be to make it painful enough to discourage you to use the system to share data with others, yet that would allow you to recover from these cases. I will make the analogy that it's like you backing up a cd and lending a copy to a friend. If he loses or destroys the copy you can always use your backup to make a new copy, but obviously that is a painful thing to do.
The second method would be to use DRM to prevent the file from working past a certain date. This way the application could essentially assume that the file would be usable past a certain point.
I prefer the first method because it doesn't require a centralised DRM. To be effective, the second system requires a central server that verifies if requests are valid or not.

Next time I will talk about the file system I would use to store all this.

Saturday, July 09, 2005

Legal P2P, part 1

A few months ago I had written about the interesting notion that P2P isn't sharing because both people get to keep a copy of the same thing, therefore doubling an item more than sharing it.

This got me thinking... why not do something different that follows the concept of sharing more closely.

Here's my idea. Imagine ITunes or the earlier versions of Napster. When you download a file, instead of actually simply making a copy, what I would do is to have the host machine encrypt the file that it has to prevent the host user from using it. The key to decrypt it would be then passed to the destination machine, along with the file in some encrypted format that would only be playable through that P2P. After the two weeks have elapsed, the destination machine would now attempt to return the "key" to the host machine. If it couldn't do that, the host machine would not be able to decrypt the original file, hence making it unusable to the host user. When the application could connect, the original file would be decrypted, the version on the destination machine encrypted (with the key sent back to the host machine), and everything would now be fine. This way, the concept of sharing would be respected. Only one person would be able to use the file at the same time.

Next week I will go into more details about this, I will answer some questions such as, what would happen if the destination computer dies, what happens if the host user wants to suddenly listen to his music, whether to use DRM, etc...

Friday, July 08, 2005

Oh well...

This wasn't very good news...

It's now going to be a free season on any technology copyright holders don't like. I guess the M stands for misery.

I really would be curious to know what new technology we will never know about?