Posted on
by

I asked this question over on Hacker News, as well as Quora, but I thought I’d also ask it here…

The UK plans to intercept all electronic communication. They currently don’t plan to snoop on content, but as noted elsewhere connection data is just as invasive.

To me this is both a civil liberties and business risk problem. I view my list of business contacts as confidential information and I don’t trust the government not to leave this information on a train somewhere.

Legal solutions are one thing, but the snoops keep raising their heads, so my feeling is that we need to actually find a way to make this sort of thing technically impossible.

Content encryption is already largely solved, although for email we still need a critical mass of people using PGP or similar.

VPNs just seems to push the problem to another jurisdiction, and if this is an agenda all governments will one day pursue, this will become decreasingly useful.

What can an individual do to protect content and connection data? Onion routing for mail servers? Do technical solutions rely on everyone doing it and so are unlikely to get much traction?

So what are your thoughts? What can we build?

Posted on
by

The Simple Download Manager is another itch scratch to open source software project tale, basically I needed a simple way to serve files for download and keep some statistics. So, like a good open source citizen I’ve made it available under the GPL, hopefully it’ll save someone some time!

Usage is very simple; clone the git repository onto your web server, put your downloads in the “downloads” directory, and describe them with a manifest in “products”, e.g.


DownloadManager::registerProduct(
new Product(array (
'productid' => 'ExampleProduct12345',
'name' => 'Example',
'description' => 'An example download',
'file' => 'downloads/example.zip',
'tags' => 'download, example',

'gacode' => 'GA-12345',
'icon' => 'gfx/download.gif',
))
);

Have fun!

» Visit the project page on Github…

Posted on
by

I have previously written about using Git to add revision history to existing rsync backups. Having performed a number of configuration changes and system upgrades recently, I have found another use of Git which has proven invaluable.

It’s a fairly obvious hack, but it turns out that turning selected configuration directories (for example /etc/apache2/ and /etc/exim4/) into in situ Git repositories is a very handy thing to do.

The revision log you get in a Git repo gives you a very handy place to note down the reasons behind a certain configuration change. This provides a very handy historical context for a change, meaning you’re less likely to remove something odd that turns out later on to have been important.

Having configuration under version control also means that even if you do accidentally remove or change something that later causes problems you can easily roll them back.

Another handy feature is the ability to easily branch, so you can very quickly experiment with some wild configuration settings and very quickly revert them to the original working configuration should they turn out to be problematic or if you run out of time to complete them.

So, give it a try!