Archive for June, 2011

Dropbox Encryption

With the recent security issues with DropBox you may be considering adopting an additional encryption strategy.

TrueCrypt a cross-platform encryption solution has been recommended by a few sites. It works by creating an encrypted disk file, which you can store in Dropbox. The one issue with this strategy is it is very hard to sync differences in the file. This means a few file changes could result in the re-syncing of your entire encrypted disk file, which really diminishes the value of Dropbox.

The solution I ultimately went with is BoxCryptor for Windows & EncFS for OSX. BoxCryptor is compatible with EncFS so data you use on one OS should be viewable on the others. The big advantage of BoxCryptor/EncFS over TrueCrypt is it uses a pass-thru filesystem. Instead of creating one big file that stores all of your data it encrypts each individual file (including its filename) separately. This is a big win when using syncing software such as Dropbox.

BoxCryptor is pretty straightforward to install and run on Windows so I won’t go into the installation details.

Installing EncFS on OSX requires a bit more work. Here are some basic instructions. Note, if you are going to share between Windows & OSX I recommend first creating your Secure directory with BoxCryptor, it’ll keep you from having to pass in special flags to encfs.

  1. Install the Mac Developer Tools (aka XCode)
    • If you have your Snow Leopard disk handy you can install the developer tools from there. I believe it is under the Extras directory.
    • If you are running the latest version of Snow Leopard and have the App Store installed, you can download and install XCode 4 from there, which will give you access to all of the needed tools.
  2. Download and install MacPorts
  3. To make sure macports is up to date, run sudo port –v selfupdate
  4. Then run sudo port install encfs
    • This should automatically resolve any dependencies
    • Note, this takes a long time to run, I recommend grabbing a cup of coffee after kicking it off
  5. Reboot your system
  6. Assuming your Encrypted file system is in ~/Dropbox/Secure run the following
    1. (optional) If you haven’t created your encfs yet run: mkdir ~/Dropbox/Secure
    2. mkdir ~/DropboxSecure
    3. encfs ~/Dropbox/Secure ~/DropboxSecure
      • It’ll ask you for the password
    4. You should now be able to see your files in the ~/DropboxSecure directory
  7. To unmount the encrypted drive run: umount ~/DropboxSecure

The overhead for the encryption is minimal. I was seeing about a 20ms increase in running the ls command on an identical directory. Now your files are secure even if your Dropbox account is compromised.

The Way of Testivus

Just recently I stumbled across and amusing viewpoint on testing. The Way of Testivus is an interesting slant on encouraging testing karma instead of testing dogma. It’s a fun and short read.

Unit Testing JavaScript

I’ve stumbled across a really cool unit testing framework for JavaScript that I wanted to share with everyone. It is called js-test-driver. Most JavaScript unit test frameworks need to be manually run, which requires a dev/qe to open a browser, start the tests, and verify the results. This doesn’t really scale or work for a CI environment. Js-test-driver aims to solve that problem.

The software itself is built with java and has a client and server side component. To start the server you just pass in a port and fire it up. Ex: java -jar JsTestDriver-1.3.2.jar –port 4224 It also has the option of passing in a list of browser executables, which the server will automatically start and setup to listen for unit tests. Additional browsers can be provisioned manually across a variety of devices by pointing to http://{the_servers_IP}:4224 in any browser window. Think Mobile. The client side is run by setting up a config file with some general information, including the server to connect to and the JavaScript files to load.

Example: jsTestDriver.conf

server: http://localhost:4224
  - bin/*.js
timeout: 90

The tests are then ran by calling the same jar file: java -jar JsTestDriver-1.3.2.jar –tests all

In my proof of concept, I was able to quickly get 8 browsers, (4 Windows browsers, 2 Mac browsers, iPad Safari, and iPhone Safari), up and running for testing against. The Unit Test itself was a very basic Hello World test. The command took more time initializing the jvm & connections than the actual unit tests, which only took 26ms to run across all of the browsers/devices.

Joshua@Quake ~/js-test-driver
$ java -jar JsTestDriver-1.3.2.jar --tests all
Total 8 tests (Passed: 8; Fails: 0; Errors: 0) (1.00 ms)
  Safari 533.21.1 Windows: Run 1 tests (Passed: 1; Fails: 0; Errors 0) (0.00 ms)
  Safari 6533.18.5 iPhone OS: Run 1 tests (Passed: 1; Fails: 0; Errors 0) (1.00 ms)
  Firefox 4.0.1 Windows: Run 1 tests (Passed: 1; Fails: 0; Errors 0) (1.00 ms)
  Firefox 4.0.1 Mac OS: Run 1 tests (Passed: 1; Fails: 0; Errors 0) (0.00 ms)
  Safari 6533.18.5 Mac OS: Run 1 tests (Passed: 1; Fails: 0; Errors 0) (1.00 ms)
  Chrome 12.0.742.100 Windows: Run 1 tests (Passed: 1; Fails: 0; Errors 0) (0.00 ms)
  Safari 533.21.1 Mac OS: Run 1 tests (Passed: 1; Fails: 0; Errors 0) (1.00 ms)
  Microsoft Internet Explorer 9.0 Windows: Run 1 tests (Passed: 1; Fails: 0; Errors 0) (0.00 ms)
Joshua@Quake ~/js-test-driver