Friday, December 5, 2008

Alternative to music DRM.

Lots of people don’t like DRM mainly because it’s a bad solution. A few problems with it are: that it is dependent on a central server that eventually shuts down, you lose the music if you change your computer, and you can’t make back up copies.

Most people say the best alternative is no DRM and sell music for cheap which is a lot better from the customers perspective but the music companies really don’t like it because there is no anti piracy methods and they think they will make less money.

An alternative implementation I have thought up is to create a new container for the music file. The container would hold the music and metadata and very detailed information about the user who bought the music online and it would be digitally signed with the private key of the publisher. The players for this format would refuse to play the music if it was not properly signed.

If the information is changed then it would not validate.

As far as the end user is concerned the file would play where ever they copy it too. And would but just like a non DRM file. Now you may ask “how does this stop piracy? If the music can be copied anywhere then it is no better then No DRM!”

It works differently then DRM because instead trying to stop people from making any copies it makes it easy to know exactly who is making illegal copies. If a music file is found being distributed online you know exactly who bought it and can easily go to court. After a while people would realize how easily they can be caught and stop putting music online or sharing it with friends. Also if a computer has a bunch of music on it, it would be easy to tell if they bought it or if it’s an illegal copy.

This solution requires no central server just the authorized player that has a list of authorized publishers. It is no where near perfect and is easier to circumvent then current DRM, but it has one major advantage over DRM: it does not harm legitimate users. People who follow the law would have no desire to circumvent it, only people who want to pirate it. Only scenario where legitimate users would want to circumvent it would be to play music on some device that does not have an authorized player for it.


This kind of DRM can be easily applied to movies and computer games. It could actually be more effective on computer games then on music.

Monday, December 1, 2008

Fast Persistent Data Storage Idea

There are several types of data storage technologies out there. The hard drive is cheap but slow seek speeds kills it when random access occurs, and a physical impact can literally kill it. Flash memory is faster then a hard drive and can withstand physical impacts but it has a limited lifetime do to the number of writes it can take. Random access memory like ddr3 is even faster then the flash memory and does not have lifetime issues, but is volatile meaning it looses its data when it loses power.

A while ago I thought of an idea on how to have the speed of ram but have it persist like flash. Its rather simple really, just combine on a single chip or board a equal amount of ram and flash and a capacitor to power the ram long enough to write the rams contents to the flash.

So this is how it would work:

When powering up the device (ram, flash, capacitor, and controller) would copy the contents of the flash over to the ram and charge the capacitors.

Until the capacitors are fully charged access to the drive would be denied.

When the device is accessed all reading and writing is done to the ram.

When the device looses power it copies the Rams data over to the flash. (Could add logic to only copy what has changed.)

This increases costs quite a bit but it gets rid of all the weaknesses of known storage technologies. It will be shock resistant, fast, long lasting, and its data persistent.

Porting Mono's SslStream to SilverLight

I have recently run into another problem with Microsoft’s stripping of the silverlight runtime. This time I was looking into using Sockets, because of the crippled WCF implementation. But sockets have been badly stripped. The only thing in the System.Net.Sockets namespace is the Socket class. No TcpClient no UdpClient and no NetworkStream. The System.Net.Security namespace is also gone. Meaning no SslStream.

With no SslStream and a sorely lacking implementation of WCF, silverlight is pretty insecure. Not in the fashion of a computer virus but in how FTP transmits passwords in clear text.

I’m not sure what kind of applications Microsoft expects people to write without being able send files larger then a few megabytes with WCF or to secure their Socket’s data with an SslStream. I’m starting to think Microsoft made a very bad mistake with trying to shrink the runtime so much. I bet people will either write insecure applications and blame silverlight or avoid it all together. Deep market penetration caused by a small download will mean nothing if developers don’t write programs for silverlight.

Anyways that’s enough complaining about the free framework that Microsoft spent a lot of money to write.

A rather simple yet time consuming solution to this issue is to port Mono’s implementation of .Net APIs that are needed. I’m not sure how much effort will be needed, but it should be rather simple to do. Write access to Mono’s repository would be required keep it synced with Mono so that’s not something I can do. Basically you would just sprinkle some compiler directives to exclude classes and methods that are not possible. Also add extension methods to extend silverlight classes that don’t have needed methods. Then write build scripts that compile those for silverlight. For limited subset of classes like the NetworkStream it should be relatively easy to port them to silverlight. Classes like the SslStream will require more effort because of its reliance on Certificate stores.