For to be to make you smarter. For to be to get you dead.

Keyboard 2014-11-05

I have recently been investigating building or purchasing a 60% keyboard. Before committing to this investment, I wanted to get an idea of how much I actually use the keys outside of the 60% layout. There may have been some kind of tool to show me this but I decided to whip up a very rudimentary keylogger and let it run for a few hours while I used my computer.

I did say it was rudimentary. Better data might be attained with a better method of logging keystrokes, as xinput seems to regard holding a key down as a long series of press and release events rather than a single one. After collecting the data for a few hours I created a script to put the data into a useful format for me to digest.

This script reads the keylog and creates a "heat map" of which keys I actually pressed. Here is the generated image:

keyboard heat map

Update: I have regenerated the map with a few days of data to give a better view of my usage.

Some notes before interpreting the data:

I have my caps lock mapped to super (windows key) because it is the modifier I use for my window manager functions. I do not actually turn caps lock on and off that frequently.

I have my escape and tilde (left of number 1) keys swapped. I'm not sure I like this just yet as I type ~ more often than I had realized.

I only had the keylogger running while I was doing work-type things. I boot into Windows if I am going to play games and I did not log any data during those times although I'm not sure the differences would be significant.

All in all I think this really shows how little keys are used outside of the 60% layout area (at least by me during the time of this experiment). In any case, this has strengthened my resolve to acquire a 60% keyboard.

heartbleed 2014-04-09

In light of the recent heartbleed bug, I have taken an opportunity to review my server configuration and ensure that everything is up to snuff. To facilitate this, I used the wonderful Qualys SSL Labs tool. Their best practices seemed extremely reasonable to me so I set out to ensure I was following all of them

First of all, I had to make new server keys and certs because of the potential that they were compromised. Personally, I can never remember how to work the openssl command line tool so I have set up a makefile to do all that nonsense for me:

This makes my life much easier since I can just make clean all when it's time for new certs. The dhparam.pem rule is because nginx by default uses openssl's default DH parameters which are only 1024 bit and that will weaken the security of clients using ephemeral keys which kind of defeats the purpose.

With the certs in place, I have the following nginx configuration:

This configuration has netted me a coveted A+ from Qualys:

SSL Labs Overall Rating: A+

However, I did have to make some compromises to do this.

First, I have disabled use of SSLv3 (because it is broken). This precludes IE6 from accessing I cannot think of anything less controversial than this. If for some reason you need to support people using IE6 you should review your life choices. According to Qualys, this also precludes YandexBot 3.0, which is apparently a bot from a Russian search engine. This is more unfortunate than not supporting IE6 but not so much that I am going to use a broken protocol.

Second, as mentioned earlier, I am using 4096 bit DH parameters to match my 4096 bit key. This apparently precludes Java 6u45 from connecting. As far as I am aware Java 6 is no longer supported so it's probably time for any clients using this to upgrade to something less broken.

Lastly, I have excluded 3DES from the list of ciphers my server is willing to use. This was probably not entirely necessary since 3DES is not really broken but it does use 112 (or 108) bit keys which are a tad too small for my taste so it got the axe. This precludes IE8 on Windows XP from connecting. As with the other sacrifices, this product is no longer supported by its makers so I see no reason for it to be supported by me.