Cool ideas
Monolith
And now we have another entry that fits into the gee, I had that idea a few years ago category: Monolith. The Monolith site introduces the concept:
Monolith is a simple tool that takes two arbitrary binary files (called a Basis file and an Element file) and "munges" them together to produce a Mono binary file (with a .mono extension). Monolith can also reconstruct an Element file from a Basis file and a Mono file.
In most cases, the resulting Mono file will not be statistically related to either file. If you compare the Mono file to the Element file, the Mono file will contain none of the information present in the Element file. In other words, the Mono file by itself tells you nothing at all about the data in the Element file. Only when combined with the Basis file will the Mono file provide information about the Element file.
Monolith can be used for exploring the boundaries of digital copyright, and the rest of this website is devoted to such an exploration. The core questions: What happens when we use Monolith to munge copyrighted files? What is the copyright status of the resulting .mono file? These questions are considered in depth below.
Joe Gratz dissects Monolith to let us know it won't fly, legally speaking:
But when you distribute the Mono file when everybody knows that you’re supposed to use Rohrer’s “file A” as the other file in order to get the MP3 back out, you’re just distributing the MP3 in a different encoding, like distributing it in some encrypted form, or in a ZIP file. Rohrer recognizes that MP3s are copies of sound recordings because “an algorithm exists that can convert an MP3 file into sound mechanistically without any additional information”. The same is true of Mono files.
I gotta agree with Joe here -- Monolith is too simplistic to effectively circumvent copyright law. As usual Joe boils it down to a concise point -- thanks!
My idea from back in day was a little more complicated than Monolith:
- Take a file, encode like monolith so it doesn't resemble the original file.
- Break the file into 3 parts by extracting the every third byte into one file, every third plus one byte into another file, and every third plus two bytes into a third file.
- Take these files and store them on servers in three different countries. At least one of these servers should reside in Russia.
- A downloader would then download all three parts from three different countries, and run it through a tool to combine the file back into one and decode it back to the original file.
I think this idea suffers from the same faults that Joe outlined. The unofficial legal advice I got was this: If it looks like its circumventing copyright and skirts around the finer points of copyright, any judge will nail it as a copyright violation. Makes sense -- that is consistent with what the courts have been doing. Thus, I never persued the idea.
Posted by Mayhem at June 9, 2004 11:37 AM
I unofficially agree with the unofficial legal advice you got. Even if you can convince them it's not a copy, you're sure as hell going to be a contributory infringer.
And anyway -- you may need more than three parts. If this went to trial, they'd produce an expert claiming to get something like music out of the one-third MP3. I don't know enough about the MP3 file format to say, but isn't there enough error correction to get something vaguely resembling an audio stream out of an every-third-bit MP3, with enough statistical munging?
Gotta say, though, the Russia idea has inherent appeal.
