random neuron misfires

This morning, I was checking my Google AdSense and Google Analytics statistics, and noticed a bump in the number of hits to my 9/11 Commission Report page.

I decided to hit the referer logs and look at where the traffic was coming from, which led me to these three company pages.

If you look closely at the first one, they have a copy of the 9/11 Commission Report, nicely annotated, converted to Windows CHM format, available for purchase at $14.95.

Closer examination of a page like this shows that they have some footnote links which link to the footnote index.

Comparing that to my own version, you’ll notice that they are IDENTICAL.

If you compare that to the original 9/11 Commission Report from the .gov site, you’ll notice that these footnotes do not exist at all, and they aren’t in the PDF version either.

Why? Because I created them! I put them there, painstakingly by hand… every… single… one (this is also referenced in my detailed ChangeLog for my HTML version of the report).

I took the PDF version, created a fully semantic, validated version of the content, page-by-page, footnote by footnote, making sure everything met with the highest standards. I then converted it to Plucker format, with the end result that looks very nice on the Palm (I also converted it to iSilo format as well).

They also conveniently used the images I google’d around for, and put in my version. There are quite a few “easter eggs” in the version I have which makes it easy to spot someone who has taken my copy, instead of using the upstream version. I won’t mention what they are, but these three sites are guilty of violating the copyright on the HTML presentation and corrections in my version. They also stripped out the meta tags identifying it as mine, as well as the HTML comment that warns not to steal the work without permission.

They knowingly elected to violate the copyright by taking my work without permission, and are selling it.

One of these companies even went so far as to claim it as their own version, their own creation (and yet, my hidden “corrections” to the original content are mysteriously in their copy).

This morning, I decided to send the three of them a Cease & Desist takedown notice. They have been given 24 hours to remove the unauthorized reproduction of my work, before I begin taking a walk with them through the legal system.

This email is to notify you that you are henceforth forbidden from redistributing, selling or promoting derivative copies of my works, specifically the “9/11 Commission Report” as referenced here:

http://www.[…]

Failure to remove this work from your website and all partner websites within 24 hours will result in direct legal action against your company for copyright violation as well as other applicable laws, and proper financial restitution will be assessed at that time.

As the original author of the HTML work you have stolen my without permission, I take direct issue with your redistribution of my work.

Prior authorization is required by the license which you agreed to when you decided to download, convert and/or sell the work as your own.

Please feel free to contact me to discuss your options.

I have quite a bit of experience chasing down copyright violations.

I am not happy about this, but I will be vindicated, as always…

Yes, I’m sad to see her go.

She’s been with me for 10 years.

We’ve been through a lot together.

We moved across the country together, and then we moved back.

She’s supported me through many tough times, and carried a heavy load when I couldn’t do it myself.

I treated her well, and we never had any trouble. When she was feeling ill, I’d take care of her and nurse her back to health.

I’m talking, of course, about my 1987 Jeep Comanche pickup truck (that’s really her in the photo below)…

Not a spot of rust, not a single dent, nothing at all wrong with her, and at 129k miles, she’s still running solid. She’s a bit of a tough starter in the cold, but what 20 year old truck isn’t?

But I had to trade her in. It was time.

The dealership gave me $2,000 for her as a down-payment on a new vehicle. They’ll probably just sell her for scrap, but she deserves more than that. Maybe a collector will scoop her up and keep her alive… I certainly did.

If the funding comes through, I’ll be the proud new owner of a 2003 Chevrolet Avalanche, which looks something like the photo below:

I don’t drive much, but this suits my driving and recreation tastes perfectly. It’s completely reconfigurable, so I can use it as an SUV, or a full-size pickup, or for a quick ride into the woods for camping or mountain biking, or whatever I want. It has enough room for Seryn and her friends, or myself and 6 of my friends, or whatever I want to carry.

It was time to get into this century and get a new vehicle; something safe and reliable.

It was sad to see my old truck go, but this one should last me just as many years.

I use encryption.

A lot.

I don’t really have a convenient way to use encryption for the backups I use when I store them offsite at “The Vault“, and my backups have become too large now to fit conveniently on a single or double DVD.

Here’s what I was previously doing:

mkisofs -v -o ${DATE}_backup.iso -RU --joliet-long  \
        -input-charset iso8859-1 -cache-inodes      \
        -hide-joliet-trans-tbl -hide-rr-moved -f .

gpg --encrypt --recipient 'David A. Desrosiers'     \
        ${DATE}_backup.iso

From here, I get a file called 03-02-2007_backup.iso.gpg, which I burn to DVD. The gpg-encrypted file is about 60% of the size of the original. This means if I have a 6gb .iso file, I get a 4gb gpg file I can then burn to DVD for backups.

But now, my backups and my data is too large to fit on a single or multiple DVDs, so I decided to use one of my 500gb PATA drives, TrueCrypt the whole drive, rsync my data to the drive, close the TrueCrypt volume, and transport that to the vault offsite.

Since TrueCrypt works on Windows and Linux, I can use the same drive and volume on both systems. What I can NOT do, is use a FAT filesystem on the encrypted volume, if I want to store my Linux filenames and data on it.

Here’s how that works (all user input is bolded). Note, for a drive of this size (500G), it will take a VERY long time to format (at least 14 hours):

$ sudo truecrypt --create
Volume type:
 1) Normal
 2) Hidden
Select [1]: 1

Enter file or device path for new volume: /dev/sde1
Filesystem:
 1) FAT
 2) None
Select [1]: 2

Hash algorithm:
 1) RIPEMD-160
 2) SHA-1
 3) Whirlpool
Select [1]: 3

Encryption algorithm:
 1) AES
 2) Blowfish
 3) CAST5
 4) Serpent
 5) Triple DES
 6) Twofish
 7) AES-Twofish
 8) AES-Twofish-Serpent
 9) Serpent-AES
10) Serpent-Twofish-AES
11) Twofish-Serpent
Select [1]: 10

Enter password for new volume '/dev/sde1': 
Re-enter password: 

Enter keyfile path [none]: Hit ENTER

TrueCrypt will now collect random data.

Is your mouse connected directly to computer where TrueCrypt is running? [Y/n]: y

Please move the mouse randomly until the required amount of data is captured...
Mouse data captured: 100%  

Done: 512.85 GB  Speed: 10.03 MB/s  Left: 0:00:00  
Volume created.

You’ll notice a few key things in here:

• I chose to create the volume without a filesystem. This will become clear in a moment
• I chose to use Whirlpool as my hash, because it has been proven to be quite secure.
• I also chose Serpent-Twofish-AES as my encryption algorithm. There’s a good breakdown of the various encryption algorithms that might be useful for you to read, if you’re curious.

So now we have an encrypted 500GB drive, /dev/sde1 in this case, ready to be mounted, formatted, and have data copied to it.

Let’s do that. To do this, we need to mount the volume through truecrypt as follows:

$ sudo truecrypt /dev/sde1
Enter password for '/dev/sde1': 

To check the volume, do the following:

$ sudo truecrypt -vl
/dev/mapper/truecrypt0:
 Volume: /dev/sde1
 Type: Normal
 Size: 501988772864 bytes
 Encryption algorithm: Serpent-Twofish-AES
 Mode of operation: LRW
 Read-only: No
 Hidden volume protected: No

The next step is to format that volume with the fs of choice. Depending on what you plan on putting on it, XFS, ext or ext+journal (ext3) will be fine. I’d recommend staying away from ReiserFS, based on my personal experiences with it. You WILL lose data if you use it.

Now we can mount with truecrypt’s passthrough to mount(1) it and begin formatting it (this example below is for a 100M test file for this blog post, not the 500G drive I am using in production):

$ sudo mke2fs -j -m0 /dev/mapper/truecrypt0 
mke2fs 1.39 (29-May-2006)
Filesystem label=
OS type: Linux
Block size=1024 (log=0)
Fragment size=1024 (log=0)
25688 inodes, 102396 blocks
0 blocks (0.00%) reserved for the super user
First data block=1
Maximum filesystem blocks=67371008
13 block groups
8192 blocks per group, 8192 fragments per group
1976 inodes per group
Superblock backups stored on blocks: 
        8193, 24577, 40961, 57345, 73729

Writing inode tables: done                            
Creating journal (4096 blocks): done
Writing superblocks and filesystem accounting information: done

This filesystem will be automatically checked every 28 mounts or
180 days, whichever comes first.  Use tune2fs -c or -i to override.

I usually immediately run a fs check on the drive. To do that, do the following:

$ sudo tune2fs -C400 /dev/mapper/truecrypt0 
tune2fs 1.39 (29-May-2006)
Setting current mount count to 400

Followed by:

$ sudo e2fsck -C -f -y /dev/mapper/truecrypt0  
e2fsck 1.39 (29-May-2006)
/dev/mapper/truecrypt0 has been mounted 400 times without being checked, check forced.
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure                                           
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
/dev/mapper/truecrypt0: 11/25688 files (9.1% non-contiguous), 8914/102396 blocks

Now we must unmount the truecrypt volume and remount it with truecrypt again to begin copying data to it, and we’ll use rsync to do that…

$ sudo truecrypt -d /dev/mapper/truecrypt0

We mount it again, which prompts us for our password:

$ sudo truecrypt /dev/sde1 /mnt/external
Enter password for '/dev/sde1': 
cd /
sudo rsync -avSP --delete root etc home var user@localhost:/mnt/external/System\\\ Backups

That last command may look a bit odd, since we’re just doing it on the same physical machine, but there seems to be an issue with stacking local directories that are rsync’d to a mounted local directory, so I add the user@host to make sure its done correctly. Also note that “System Backups” doesn’t exist yet; rsync will create it. The three backslashes are necessary to escape the space. Not two, not four, it must be three.

Once the rsync is done, we can unmount it with standard umount(1):

$ sudo umount /mnt/external

One more check of the drive to be sure the data is intact:

$ sudo e2fsck -C -f -y /dev/mapper/truecrypt0

And now we can unmount it with TrueCrypt:

$ sudo truecrypt -d /dev/mapper/truecrypt0

That’s it. It seems like a lot of steps, but once it is done, it should “Just Work(tm)”

Some final notes: If you want to use XFS, you can use the same device that we used to format it to ext3, but just use the ‘-f’ argument to XFS to force the format.

If you want to use ext2 for raw speed, no journaling on the drive, you can just omit the ‘-j’ option that I used to format it, or you can use ‘mkfs.ext2’. Likewise, if you want to use ext3, you can use ‘mkfs.ext3’. I generally just use the “old-school” method, “mke2fs -j”.

Look up the other options I’m passing here in the requisite manpages to understand what they do (tunefs, mke2fs, etc.)

There’s another site that describes how to make a hidden TrueCrypt volume on Linux in great detail if you’re interested in an alternate approach to TrueCrypt on Linux. Give it a read and use the one which suits your needs best.

Have fun!