Skip to main content


Showing posts from May, 2012

To boldly Go where Node man has gone before

With all the chatter about how uber-amazing Node.js  is I figured I'd do a little comparison with my favorite language du jour: Go .  Node's claim is that it's "a platform built on Chrome's JavaScript runtime for easily building fast, scalable network applications." So, easy to build; fast; scalable. Here's the canonical Node program for Hello, World from the Node home page. var http = require('http'); http.createServer(function (req, res) { res.writeHead(200, {'Content-Type': 'text/plain'}); res.end('Hello World\n'); }).listen(1337, ''); console.log('Server running at'); And here's the equivalent program written in Go. It's a little longer because Go insists on explicitly importing the things you use and has a little more boilerplate (such as having a func main() ). package main import ( "net/http" "log" "fmt" ) f

Simonoids. It's 'Simon' in an Altoids can powered by Arduino

The classic game Simon came out in 1978 and used a microcontroller (one of the first) at its heart: the TMS 1000 .  The circuit for Simon is pretty simple and can be seen in the patent filing # 4,207,087 .  Its simplicity makes it ideal for implementation as a hobby project with a microcontroller such as Arduino. My Simonoids is an Arduino-based Simon game that fits inside an Altoids can: The four illuminated keys are a SparkFun 2x2 Button Pad  and the associated PCB fitted with four different colored LEDs.  Each LED is connected to a single Arduino digital pin with a 330 ohm resistor to limited the current passing through it to about 10mA. The four LEDs are soldered into the PCB with the cathodes tied together, the anodes go to the Arduino via the 330 ohm resistors.  The four buttons are also tied together and jumpers are in place in the middle of the board to wire them correctly.  In total the PCB uses 4 digital pins for the LEDs and four digital pins for the buttons.  Th

Patching the Internet

When CloudFlare approached me about joining the company there was one thing that really stood out about the potential for their service: the ability to 'patch the Internet'. CloudFlare sits between people's browsers and the web servers they are trying to reach.  All the traffic (DNS, HTTP, and HTTPS) passes through the CloudFlare network.  This blog post was served up (and protected and accelerated) by CloudFlare. But as the traffic passes through CloudFlare it's possible to modify it, and that opens up huge potential for fixing Internet problems on an enormous scale. Today, CloudFlare has rolled out a service that informs people that they've been infected by the nasty DNSChanger malware.  This makes sense for CloudFlare to do because so many of the web's users touch CloudFlare sites every month.  In this case CloudFlare is helping to protect end-users, just as it protects web sites. And this sort of virtual patching can come anywhere in the network

Reverse authentication for banking

A persistent problem with retail banks is that they phone you and then ask you for information.  A common scenario is that the bank's fraud department calls because of a suspicious debit or credit card transaction.  What follows is, from a security perspective, dangerous. Either the bank just assumes that you'll accept that they really are your bank (and not some random person trying to get private information from you) or they'll go through some weak authentication (such as telling me half my postcode).  Sometimes they have the audacity to call me and then ask me to prove that I am me even though they just called me. All this ridiculous nonsense can be fixed by use of the two factor authentication tokens that banks are now giving out.  In the UK Barclays has PINSentry, HSBC has Secure Key, NatWest has Card-Reader.  These tokens are usually used for logging in to online banking or authorizing a transaction, i.e. they are used so that you can prove to your bank that you