I moved my website to my new domain, horns.by. I do like my new vanity domain, but it was not the most straightforward or cheapest setup. For anybody thinking about getting a Belarusian domain, there are a few things that should be known.

First, a .by domain is expensive. It is listed as $15, at least 33% more than I have paid for any other domain. This is the price before the 20%, or $3, VAT, bringing the total up to $18 a year. This was not the last of the unexpected fees, however. The registrar does not take any expected form of payment. What they do accept is wire transfer which added additional costs.

The monetary expense was not the only thing making a .by domain a poor value. The lack of DNS management provided with the domain was unexpected. To overcome this, I decided to use Cloudflare free DNS management. After getting it set up, everything has worked great.

When authoring HTML, if you find yourself writing an <input> element, chances are that you are going to need to label it. The proper way to label an <input> element is by using a <label> element. I don’t know how many times I’ve seen web developers omit this tag. Start using it. It aids in the accessibility of your site.

The main component of the <label> element is its for attribute. The value of the for attribute is the id of a form element. Form elements can be one of <input>, <select>, <textarea>, or <button>. The for attribute can be omitted if the <label> element surrounds the form element.

The only issue that I have with omitting the for attribute is in Internet Explorer 6 in which clicking the label will not activate the form element. I don’t have too many customers that still use IE6, so I omit the attribute depending on my customer. The W3 at one time did consider the omission of a <label> element’s for attribute a failure criterion in accessibility, due to a lack of its interface control being determined programatically, but I do not believe that this is still the case.

See below for an example of labels in use. Hint: click on the label, and not the checkbox.

I wanted to set up mutt to check my Gmail over IMAP. Mutt is a highly configurable TUI email client. Since it is so configurable and I am already conditioned to using Gmail’s keyboard shortcuts, I have decided to share my mutt configuration to emulate Gmail.

A couple of months ago, Fog Creek came out with WebPutty, a “simple CSS editing and hosting service.” It is a fantastic tool which hosts CSS files for me. This feature in itself is not that special, but what does make this service awesome is that it lets me write my styles in SCSS and it also has a pretty slick interface for letting me see style changes on the fly. I was loving it, but then I ran into a stumbling block, which I’ll get to in a bit.

Respond.js

I’ve been experimenting with responsive web design for a little bit now. To aid me in accomplishing this with older deficient Internet Explorer browsers, I turned to Respond.js. Respond.js will parse all of a web page’s CSS styles and emulate the supported media queries it finds with JavaScript to the best of its abilities.

To be able to retrieve the external CSS files, Respond.js performs an Ajax request. Since Ajax has a same origin policy, Respond.js cannot access stylesheets that are stored externally on a separate domain, such as webputty.net. Respond.js does have a solution for this: a proxy HTML file that must be on the external site hosting the CSS. I asked the guys at Fog Creek to implement this, and they have so kindly obliged.

WebPutty Responds

From: “Dane Bertram”
Date: Oct 5, 2011 4:05 PM
Subject: Re: (Case FC2120156) [webputty] Respond.js
To: “Kaleb Hornsby”

Hi Kaleb,

I just wanted to touch base quickly to let you know that we’ve added the Respond.js proxy to WebPutty and that you’re welcome to start using it now.

We’re still working on adding documentation, but for the time being, you can use the following to get Respond.js working with WebPutty (provided you’ve already got respond.proxy.gif and respond.proxy.js already on your own server):

<link id="respond-proxy" rel="respond-proxy"
  href="http://www.webputty.net/respond-proxy.html" />
<link id="respond-redirect" rel="respond-redirect"
  href="respond.proxy.gif" />
<script src="respond.proxy.js"></script>

We don’t have the proxy working in the editor just yet though, so if you’re trying to test your media queries in older versions of IE, you’ll have to visit your website directly (rather than via the preview pane in WebPutty’s editor).

Let me know if I can be of further assistance, if indeed this was helpful, or if this raises any other questions.

All the best,
Dane

For six months now, I have been a bad person. Love can make a person do funny things: to make compromises, to re-evaluate one’s own principles. In my case, it was the love of my Cr-48. It is sleek and lightweight, simple and not fancy. I do not ask for much and in return it gave me the two things I really ever needed in a laptop operating system: a web browser and SSH.

As attractive as the Cr-48 is, it blinded me to a major flaw in its SSH client. It lacked any and all support for SSH keys. I overlooked this flaw and made a compromise; I decided to allow password authentication on my home server, exposing my poor little machine to the evils that lurk in the dark corners of the internet. Fear not, I have since re-disabled passwords. I would like to say that it was because I learned my lesson and repented from my slovenly ways, but I am not disabling password authentication because it is the right thing to do. It is rather that Chrome OS now supports SSH keys.

SSH key support has been available in Chrome OS since at least before May, but it was not until today that I noticed it. There is no SSH agent, and the syntax to use a key while connecting to a host is a little annoying, but these are some freedoms I am willing to give up for security.

From crosh, the Chrome OS terminal, this is how I discovered the ability to use SSH keys:

crosh> ssh
ssh> help
connect                       - connect
dynamic-forward port          - dynamic socks proxy (-D)
forward port:host:port        - static port forward (-L)
help                          - this
host <hostname>               - remote hostname
key <file>                    - sets private key to use (-i)
nocmd                         - don't execute command (-N)
port <num>                    - port on remote host (-p)
exit                          - exit ssh subsystem
user <username>               - username on remote host
Note that this program can only bind local ports in the range
8000-8999, inclusive.
ssh> key
File '' is not a valid key file. Key files must reside
under /media or /home/chronos/user. Key files in the Downloads directory may
be specified with an unqualified name.

The next few sections will be a step by step setup guide for using keys on SSH.

Generate a Public/Private Key Pair

I generated the keys on my home server. Your syntax may vary.

$ ssh-keygen -f vinz-clortho
Generating public/private rsa key pair.
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in vinz-clortho.
Your public key has been saved in vinz-clortho.pub.
The key fingerprint is:
01:23:45:67:89:ab:cd:ef:fe:dc:ba:98:76:54:32:10 zuul@example
The key's randomart image is:
+--[ RSA 2048]----+
|                 |
|                 |
|        o . .E  .|
|       . = .o..+.|
|        S .. oo++|
|         .   .*.=|
|             oo.*|
|               o=|
|                o|
+-----------------+

Add Public Key to Server

After the keys are generated, the public key needs to be appended to the SSH authorized keys listing.

$ cat vinz-clortho.pub >> ~/.ssh/authorized_keys

Add Private Key to Chromebook

I copied the public and private keys from my SD Card to my Downloads directory. To open up the file browser, hit ctrl + m.

Establish SSH Connection

Even though the SSH help mentions a -i option, I cannot seem to get it to work, and I am stuck with the following syntax:

crosh> ssh
ssh> host example.com
ssh> user zuul
ssh> key vinz-clortho
ssh> connect
Enter passphrase for key '/home/chronos/user/.ssh/key-123...abc':

Shut Off Password Authentication

Finally, lets secure this sucker.

$ sudoedit /etc/ssh/sshd_config

Set “PasswordAuthentication no”.

$ sudo reload ssh

(Secure Shell Public/Private Key Pairs)