Image of the glider from the Game of Life by John Conway
Skip to content

Why I Cryptographically Sign My Email

Yesterday, I received a disturbing phone call. Someone very close to me, call him John, might lose his job, because a slanderous, offensive email was sent with forged headers, claiming to be John. John certainly did not send the mail, and those close to John know that the tone of the mail does not seem like something John would send. The email made its way to John’s boss, human resources, IT, and other departments. The director of IT said that whoever sent the email, will get fired. Hopefully, they understand the principle of innocent until proven guilty, and all that John has to do, is cast reasonable doubt that he sent the mail. Examining the mail headers should deliver that doubt. I’ve told John that I would be willing to examine the headers, along with his IT department, to help in any way I can. Hopefully, this ends well.

I’ve never known anyone personally that this has happened to, until now. But, I’ve been cryptographically signing my email since 2004. Every single one. I have almost 10,000 emails in my Sent folder, all of which are signed. Further, I think I’ve been very clear to my friends and family, that it is their responsibility to verify the signature. Should they receive an email claiming to come from me, they should doubt the authenticity of the mail if it is not signed.

Of course, this does not prove anything about future email. I may wish to stop signing my mail at anytime. But, all I need to do is cast reasonable doubt that I sent the mail. A back history of over 7 years and 10,000 cryptographically signed emails should cast enough reasonable doubt as to the message is question, should I be placed in that situation. Along with anyone being able to forge email headers, it’s all over. Unless you can clearly, logically, and rationally prove that I sent the mail, there is enough doubt surrounding it, that I remain innocent.

I know others don’t see email the same way I do, and treat their email experience differently, such as John. And in all reality, if setting up OpenPGP or S/MIME wasn’t such a major PITA, it might be more widely used. But for the time being, all I can do is continue to lead by example. For me, the 15 minutes it took for initial setup, and having to provide a passphrase every time I wish to send an email, is peanuts compared to threats, such as this. Of course, if the organization John worked for required S/MIME on their email (I’ve worked for one such organization that made this requirement), then it would be clear that the mail was a fake.

UPDATE: Turns out that this organization has a utility to send messages to anyone in the organization. It’s not email, but some custom, proprietary application. Further, it requires no authentication. Anyone can send messages to anyone pretending to be whoever they wish.

DISCLAIMER

DISCLAIMER: By sending me email, you agree to the following:

  • I am, by definition, “the intended recipient”.
  • All information in the email is mine to do with as I see fit and make such financial profit, political mileage, or good joke as it lends itself to. In particular, I may quote it where I please.
  • I may take the contents as representing the views of your company.
  • This disclaimer overrides any disclaimer or statement of confidentiality that may be included on your message.

Protesting SOPA/PIPA

Starting Jan 18, 2011 at 00:00 UTC, this blog will be joining many others to protest SOPA and PIPA. I strongly oppose the views outlined in the bill, and with a Google Pagerank of 4/10, with almost 650 RSS readers, and about 1,500 hits to my site per day, I’ll be taking advantage of these numbers, and showing my disgust for SOPA/PIPA. Join me, and many others, by joining the strike at http://americancensorship.org. Now, a note to my (current and future) political representatives in Utah.

Dear Jim Matheson, Rob Bishop, Jason Chaffetz, Orrin Hatch and Mike Lee:

If you vote in favor of supporting SOPA and PIPA passing, not only will you not get a vote from me, I’ll launch an online campaign to make sure I take as many people with me this November in doing the same (I’ll tell you right now Mr. Hatch, that Pete Ashdown already has my vote, but its not too late to withold the campaign). The ball is in your court.

Encrypted Mutt IMAP/SMTP Passwords

Rather than storing your IMAP and SMTP passwords in plain text on disk, you can store them encrypted using GnuPG, OpenSSL, the GNOME Keyring, or any other method of password storage encryption. It still requires a “master password” from you to decrypt the file(s) on the fly, and set the appropriate passwords, but then it will remain in RAM in plain text for the duration Mutt is running, and no worries about the password in plain text going to disk.

Here’s how I set mine up using my GnuPG key. First, I created a ~/.mutt/passwords file. The file is in plain text. Before encrypting it, here are its contents:

set imap_pass="password"
set smtp_pass="password"

I then encrypt that file with the following command:

% gpg -r your.email@example.com -e ~/.mutt/passwords
% ls ~/.mutt/passwords*
/home/user/.mutt/passwords /home/user/.mutt/passwords.gpg
% shred ~/.mutt/passwords
% rm ~/.mutt/passwords

The last two commands are to ensure that the temporary file you created for encryption is securely wiped from the disk using the GNU Shred utility. Now, you should only have an encrypted binary data file that contains your passwords. All that is left is to configure Mutt to decrypt them when starting up. You can set that easily in your Muttrc:

source "gpg -d ~/.mutt/passwords.gpg |"

The string is just a standard string. Also, it’s important to have “|” at the end of the command, to pipe the output to Mutt, so it can be appropriately sourced.

At this point, you should be able to launch Mutt, be asked for the passphrase for your private GnuPG key, and it should log you in to your IMAP account. You should also be able to send mail as normal, logging automatically into your SMTP account. The only time you are asked for a password, is your GnuPG passphrase when starting Mutt. If your “gpg-agent” is already running, and you’ve configured GnuPG to use the agent and added your private key to it, then starting Mutt won’t ask you for your key passphrase, and will use the agent instead.

Other than temporarily creating the plain text file to encrypt, which stores your passwords, and which you promptly and securely shred later, your IMAP/SMTP passwords for your remote account are never on disk in plain text.

Happy encrypted hacking!

My Google Voice Rant

So, I’ve been a Google Voice subscriber for about 2 years. I have one of the most awesome phone numbers you can get: 686-8086 (it has an inside geek reference to x86-based CPU architectures, and also to my PGP key ID of 0x8086060F. Awesome, eh?!). I’ve used it for SMS text messaging, receiving calls, and placing calls (almost 4,000 total calls). I’ve used it for conference calls as well. I’ve blocked spammers, recorded calls, transferred calls, and pretty much have used it fully. After all this, I have some gripes.

  • I get A LOT of missed calls when people call my Google Voice number.
  • I get A LOT of static on the line versus calling my cell directly (I honestly don’t understand why).
  • Managing the “other” numbers for contacts is messy.
  • Conference calls only support 4 people- you, and 3 other callers.
  • Conference calls can only be initiated when people call your Voice number (you cannot invite people to the call).
  • When using SMS on Android, the notifications are filled with the name presented twice- once for the Google Contact contact, and then again for the Voice Caller ID.
  • Unless you’re using Android (or maybe other OSes), calling from your phone will not show the Google Voice number on their caller ID, unless you call your Voice number first, then follow the phone tree to dial the number you wish to call (a PITA).
  • Some cell phone providers offer unlimited minutes when calling other cellular phones. Using Voice means calling a landline, which means using your minutes, regardless of who made the call.

I like the spam options of the service. It has come in handy. And I’ve recorded a few phone calls for logging reasons. However, I’ve found that using Google Voice in totality is becoming more of a pain than a benefit. Losing calls is especially annoying, definitely when you’re waiting for a job offer (ugh). I’ll continue to hand out the number to companies and people that I don’t care much about, but I’ve been handing my cell phone number out more and more lately, because Voice is just getting in the way.

Anyway, just had to get this off my chest (missing a call this morning was REALLY upsetting, and sparked the post).

Making Sense of Hashed Hosts in ~/.ssh/known_hosts

I don’t expect you to follow this post completely, but it’s so amazingly cool, I have to blog it. Consider the hashed sections of ~/.ssh/known_hosts file for (recent) OpenSSH clients, not including the public key parts:

|1|kFJT5z0x3ndyutgZ4E5pRk+ORBA=|hzXvdYUudo+qK9BGlFWtSAUXlXc=
|1|8wo1+FO0hkATPgQZoeNHeIlvAjw=|dt/a9jz9CnLKP72j+Jr8MKMjgEE=
|1|pvBQEKEGLnH0RCJr+8Dmqqnvlrs=|fJJvjyG/TmHFnuIX57nDThq/C4M=
|1|HKV4DzgDkajXoUHf9B82JBu7J10=|c/K+MdJvWaZeJFs/W7iqhqo0wvE=
|1|rtvQhRVnNanQZYkLUMbjoBGNhn0=|0U6a1LUQqLL6P1T2Wji3VWw69pw=
|1|0ziSYi4c+xBXGEBZcNN1LMhYUc4=|qRSN5GSPyQi+fmaVz2zNwkmKoy8=
|1|6nv6Vpk3AYgICHxJGVgVdsYRuq0=|fBNOIz1l3RW+N61jyDPunKX9n7E=
|1|+b4uA+Mq7RHRAFW21qv8aO3rIRs=|1eizMri01IxEKrXquBnwTYP61Ow=
|1|BkB0PZu2qtsLID/Ibe/D68gANQU=|qW6uAzcpecOOKNI4zEvngyfpGkI=
|1|n+QrRn7QXeAJ5hRe2M8v8IspihE=|EqUxXdSeIF1cl1fQjl5zILebkGY=
|1|BOKuKnWojy028tJf9Y671lws0d0=|SuBQJmJZp5JNVYG/rP9yb9ZhJcE=
|1|WACsxtodOiM89kf4rNPLgF1CXZ4=|UTccVeLDZJF3wlH8V05XJNlsOBw=
|1|o6FFoirXYblM7wBMdeJDYGMPI58=|5jJB7T7itY702ZHHByXtSpGk9SE=

The column fields are similar to that of the /etc/shadow file on GNU systems, except where the “$” is the column delimiter, “|” is in this case. If the string was “|1|o6FFoirXYblM7wBMdeJDYGMPI58=|5jJB7T7itY702ZHHByXtSpGk9SE=”, then the breakdown is as follows:

  • |1- HASH_MAGIC. This tells the client that the host information has been salted and hashed with the SHA1 algorithm.
  • |o6FFoirXYblM7wBMdeJDYGMPI58= This is the salt applied to the host- base 64 encoded 160-bit string.
  • |5jJB7T7itY702ZHHByXtSpGk9SE= This is the base 64 encoded version of the hashed host

Now, if you want to get at the actual strings, not base 64 encoded, you could run the following command (I admit, not elegant, and could probably be better solved without nesting, and a single awk(1) statement, but I’ll get to that later):

% echo $(echo o6FFoirXYblM7wBMdeJDYGMPI58= | openssl base64 -d | xxd | cut -c 10-48) | sed 's/ //g'
a3a145a22ad761b94cef004c75e24360630f239f
% echo $(echo 5jJB7T7itY702ZHHByXtSpGk9SE= | openssl base64 -d | xxd | cut -c 10-48) | sed 's/ //g'
e63241ed3ee2b58ef4d991c70725ed4a91a4f521

There you have it. Very cool. Now, the only question is how to apply the salt to the hostname, to get to the hash? I’m working that out, but I wasn’t motivated enough to get to it. Of course, there’s no application to this, that I can tell, unless you want to brute force the known_hosts file.

Boycott GoDaddy

I generally don’t jump on boycotting bandwagons, usually because they are severely misguided and misinformed, and they’re usually interested in spreading FUD more than just reporting the issue at hand. However, on December 29th, 2011, I will be transferring all of my 15 domains away from GoDaddy, because they support the SOPA and Protect IP bills. You can read more about this at http://www.reddit.com/r/politics/comments/nmnie/godaddy_supports_sopa_im_transferring_51_domains/. Further, there is a boycott site for boycotting GoDaddy, where you can pledge that you will be moving your domains. This site is found at http://godaddyboycott.org/.

December 29th is the day, if I don’t feel the itch to do it before then.

Expand URLs in Irssi

If you’re an IRC junkie, and spend hours a day in Irssi, then this post might be useful to you.

It’s all the rage these days to shorten URLs with fancy URL shortening services. Heck, even I have one. They are certainly nice to have, when links are exceptionally long, such as search result URLs, and just the mere wrapping from one line to the next breaks the URL (not to mention, any additional characters added in the line break, such as spaces, other characters, etc.). I’ve used, and still use, link shortening services for IM, IRC, email, Identi.ca, Twitter, etc., only when I suspect the link could break as a result of line wrapping. I use them sparingly, and only use them if they provide a preview feature, giving the link to the preview.

While they have their advantages, they certainly come with a cost. Link rot is a very real concern, should the link shortening service go offline. You can nest shortened links in each other, concealing JavaScript/CSS mouse hovers. They can contain all sorts of nasties, and you don’t know what you’re getting into, unless you use some sort of software to expand the URL for you, before you actually follow the link. I’ve already blogged about using a simple shell function to expand shortened URLs (post at http://pthree.org/2011/10/18/use-wget1-to-expand-shortened-urls/). Well, now it’s time for Irssi to automatically provide the function for me.

Presenting https://github.com/jcande/Expand-URLs. This is a simple Irssi script that will identify URLs in a given notice, whether in private or in public, and expand them using the http://longurl.org service (I think a patch for doing the lookup without a 3rd party should probably be submitted, as any 3rd party expanding service might go offline).

For me, this script is exceptionally valuable, because I connect to a local Bitlbee instance with Irssi, and use Bitlbee to connect to Twitter. Unfortunately, Twitter wants to track your clicks with their http://t.co service. Every link longer than 19 characters (20 for HTTPS) submitted to Twitter is automatically shortened with this wrapper. They claim that the service is to identify malicious links, and prevent them from being posted, should one be identified. But certainly, a company the size of Twitter can do so much more with this new “service”. They could track what links are clicked and when. They can use this information to identify what stuff you’re interested in, and when you use the service. They can track who clicks the link by IP or ISP. Of course, it would be foolish to not sell this information to advertisers, to target additional advertising on Twitter or other sites, based on this info.

At any event, this is one of the few Irssi scripts that I find really, really useful for day-to-day. It makes the Twitter timeline a bit chatty, now that lengthy URLs are being shown, and a few break due to line wrapping. And that is a pain, no doubt. But, the vast majority of links don’t break, and it’s nice seeing where I’ll be taken when visiting the link. Keeping Twitter from tracking me, despite the occasional link breakage, is worth it.

P.S.: There is also a WeeChat script at http://www.weechat.org/files/scripts/expand_url.pl.

A Note About Removing Files With find(1)

I’ve seen on the internet, and elsewhere, that when there are too many arguments for rm(1) to handle, that the following command will suffice:

% find /path -exec rm -rf {} \;

While certainly functional, it’s not optimal. If there are thousands of files (as is often the case at my job), this command is slow, slow, slow. The reason being are all the excessive fork() and exec() calls for each pass with rm(1). Instead, you could optimize find(1) by using “-delete”:

% find /path -delete

This is much more optimal, but it has one VERY nasty side effect. If you place “-delete” in the wrong spot in your find(1) command, you could delete all the files listed under “/path” before processing the necessary logic. From the find(1) manual:

Warnings: Don’t forget that the find command line is evaluated as an expression, so putting -delete first will make find try to delete everything below the starting points you specified. When testing a find line that you later intend to use with -delete, you should explicitly specify -depth in order to avoid later surprises. Because -delete implies -depth, you cannot usefully use -prune and -delete together.

One nice benefit of “-delete”, however, is the proper handling of NUL characters in your filename, such as spaces, tabs or the newline character. Thankfully, there is another option, which is not only supported in GNU/Linux, but also in FreeBSD (and perhaps others):

% find /path -print0 | xargs -0 rm -rf

This avoids the excessive fork() and exec() system calls from our first command, and doesn’t have the nasty side effects of “-delete”. Further, because of “-print0″ as a find(1) argument, and “-0″ with xargs(1), we can handle files properly with NUL characters. Time the three commands above, and you’ll see that the last is most optimal.

We can squeeze some extra juice out of the command, though. All we need to do is cd(1) to the directory we wish to operate our find(1) command on:

% cd /path && find . -print0 | xargs -0 rm -rf

Working with removing millions of files (yes, I do actually remove that many, often), I have found this latest find(1) command to be the most optimized in terms of sheer speed. It moves. You may find the same results as I.

FYI.

Steganography

I have been familiar with steganography for a number of years. In fact, back when I was in middle school, I developed a fascination for encryption, and hiding messages, mostly so I could pass notes back and forth to classmates during class. It wasn’t long before I found “invisible ink”, which is a form of steganography. While I’m certainly no expert on the subject, I decided to have a bit of fun with my email.

I placed a hidden message in my email headers for a bit (I’ve since stopped, for various reasons). I considered it an “Easter Egg” of sorts, waiting for someone to notice. Here is what I placed in the headers:

Crypto-Challenge: iVBORw0KGgoAAAANSUhEUgAAADwAAAA8AQMAAAAAMksxAAAABlBMVEX
       ///8AAABVwtN+AAAAtklEQVQokXXQMQ6CMBQG4McCiykXMPEKsuEiV2nCBdoLWNgN
       Xqld7MYZeoQSFgbisyZWER//9E1//vcAYhQOvkB0X3AQotBAoZ5lV9hpA63ZxCP5Q
       SiE5N28QpjRxT0rhFzi7BWUlx3LQvMH+x1jx7IEAoer8hVqR4Crhp1fhf9QI976tF
       oAIGlYWTkCCr3I7yTCpTkaDQTqWUhjtFtCNizNgEbbZxMFDnIYrHUEwjPRnywQiHk
       CI/3gDHrryF4AAAAASUVORK5CYII=
Crypto-Hint: image/png

Quickly, you should identify the “Crypto-Challenge” header as base 64-encoded string. The hint says it’s an image, of type PNG. So, the following Python code should do the trick:

1
2
3
4
# assuming the 'img_string' variable is the actual base64 string above
f = open('crypto-image.png','w')
f.write(img_string.decode('base64'))
f.close()

Running that code with the base 64-encoded string above gives the following image:

Scanning the QR code reveals the text “42″, of which most geeks should recognize as “The Answer to the Ultimate Question of Life, the Universe, and Everything”.

Of course, steganography isn’t encryption. It’s security by obscurity, which isn’t security, where a message is hidden by obscuring it through some means. Wikipedia has a great article on it at https://en.wikipedia.org/wiki/Steganography.

What can you do with hidden messages in images (or vice versa, as in the case with my email “Easter Egg”)? Well, for one, you can easily get around email attachment restrictions. For example, take a ZIP archive. Perhaps some organization blocks email with .zip attachments. Why not convert the archive to base 64, then convert the result to an image. You might end up with something like this:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
from PIL import Image
import base64
import math

# function to return max image size
def get_size(size):
    width = height = int(math.ceil(math.sqrt(size/3)))
    diff = int(((width * height) * 3) - size)
    return (width, height, diff)

# open our binary non-image file
f = open('archive.zip','rb')

# convert the binary to a base64-encoded string
enc_bytes = base64.b64encode(f.read())
f.close()

# get file size to hold data (square)
(w,h,d) = get_size(len(enc_bytes))

# pad with zeros, if necessary
if d > 0:
    for i in range(d):
        enc_bytes += ('\0')

# create our final image
img = Image.frombuffer('RGB',(w,h),enc_bytes,'raw','RGB',0,1)
img.save('image.png')

Your final image might end up like:

In our case, I just created a file from /dev/urandom, zipped it up, and converted to an image. Thus, the reason the data in the image appears so random. More structured files will show actual structure in the final image. Also, notice the string of black at the bottom as a result of our padded zeros to adjust for a square image, without losing data.

Of course, to get back to the archive, you just need to reverse the process of converting the image to a base64 string, then back to the original file. Now, I’m no Python expert, and I realize there is much more to add to the code, such as “try/except” blocks for testing files, writable directories, etc. The point of the code was just to demonstrate an overall algorithm.

Hopefully, this is of some interest to some of my readers. I’m open to code improvements. Thanks to https://diablohorn.wordpress.com/2010/12/04/whats-in-a-picture for use of the code above.

Burgers As A Service

There is this burger shop near my home that makes the most amazing burgers, fries and shakes. Bar none. The burgers, of which there is quite the variety, each have their own “secret sauce” that gives each burger its own unique flavor. The fries also have various dipping sauces you can order, each of which are “secret sauces”. Lastly, the shakes, which seems to have a never ending array of flavors, each have their own “secret recipe” to the flavor. Because of these trade secrets, the burgers, fries and shakes are outstanding!

It’s more than just taste too. Portions are epic. They have the “Big Ben” burger, which cut in half would produce two Big Macs from McDonald’s. Then there’s the “Double Ben”, with two patties and the “Triple Ben” with three patties. Add on the amount of fries, and the size of the shake, and you could easily feed a family of four with one order of the Triple Ben.

Lastly, the service is amazing. Every time I’ve visited, I’ve gotten outstanding service from the employees, and the turn around time on preparing my meal is fast. Maybe not as fast as a “fast food” joint, but certainly not as long as your standard dine-in restaurant either. As a result, I recommend Burger Bar in Roy, Utah to anyone and everyone. If you’re a burger, fries and milkshake lover like I am, you’ll love this burger stand.

However, despite the amazing food, epic portions and fantastic service, Burger Bar operates on trade secrets. The recipes for their burger sauces, dipping sauces and shakes are all proprietary. Further, they aren’t free. I pay ~10-12 dollars for lunch whenever I want to pay them a visit. If I bring a party of 6 or 8, I don’t get a bulk discount either. So, aside from the food and the service, everything about the experience is proprietary and vendor-controlled.

I’m okay with that. So why is it that some people aren’t? Well, not with burgers, but with SaaS, or “software as a service”. Of course, I’m referring to Facebook, Google+, Gmail, Bit.ly, and other software vendors that provide an online service to their userbase.

It seems to be the latest “fad” (call it what you will) to oppose proprietary SaaS solutions, or sites with proprietary JavaScript licenses. Companies, such as Facebook, operate on trade secrets. Their server-side code certainly isn’t open to the public, and their JavaScript is obfuscated as much as possible to prevent prying eyes from making any sense out of it (as well as minimize bandwidth). Now, I no longer have a Facebook account, but I left Facebook for other reasons. Mostly, if Facebook was a burger joint, I’m confident that they are trying to poison me, without me catching on. But that’s beside the point. Facebook offers a service, entirely proprietary, much the same way Burger Bar offers a service, entirely proprietary.

Yet, it’s okay to eat the burger, but not okay to use Facebook. It’s okay to ignore the trade secrets of a restaurant, but not okay to ignore the trade secrets of a software vendor. Now, don’t get me wrong. I’m certainly not advocating, endorsing or condoning trade secrets, such as copyrights, patents, trademarks, etc., where the intent is to defend your intellectual property at all costs. All I’m saying is, when it comes to software, I view SaaS a bit differently than installed software.

Continuing the food analogy, when I prepare food in my home, I want to know what’s in it. The FDA in the United States feels the same, and as a result, ingredient lists are required to be printed on every packaged food source. So, when making my own burger, I have the right to know exactly how to prepare it, down to making my own “secret sauce”. I have the source code to my burger, so to speak, and I can make all sorts of fantastic burgers with that “source”. Yet, when I visit a restaurant, I don’t need to know the “source code”, so long as I feel confident the restaurant isn’t trying to poison me or make me sick.

I treat my computer much the same way. My laptop is my home, where I can make my own recipes to create my own software. I have full control over my data, and by having access to the source, make sure the software is respecting my data too (among other things). Google is my restaurant, where I can order software, perhaps pay a premium, and enjoy a good experience, with someone else’s trade secrets. I decide what data to give them, and what not to. I still have full control over my data. So, although I don’t have access to the source, I don’t have to give them my Social Security Number either. On my laptop, having access to the source code is key, and the foundation for a lot of my Free Software principles. On a web site, regardless of the site, I’m not interested in the source code so much, as I am having a positive experience that allows me to interact in a safe and productive manner.

I share this post, because I just finished reading http://ebb.org/bkuhn/blog/2011/11/24/google-plus.html. Bradley Kuhn argues that you won’t find him on these services, such as Twitter or Facebook, because of the trade secrets. I applaud him for sticking to his principles, and not compromising. However, does he eat at burger joints where trade secrets have been critical to their success? I’m curious where the line is drawn. Why is it okay to eat and physically digest trade secrets, but it’s not okay to execute them in your browser? As a result, I believe Bradley may be distancing himself from those that love him, and just want to interact with him online. In fact, I would say he’s distancing himself from the very people he wants to advocate to. How can more people use Free Software, if you are only hanging out with the people who already do, and you are not hanging out with the people who don’t?

Just my thoughts. I’m not interested in trolling, so don’t take this article as such. Only as discussing an angle to SaaS that I don’t think many have thought about. If you’re interested in arguing in the comments, please be civil. Thanks.

Tab Completing Aliases For Multiple Accounts In Mutt

In mutt, you can setup multiple accounts, and use account hooks (complete with key bindings) to change to those accounts. I have a Gmail account and a work account. In my Gmail account, I use goobook to access my Google Contacts, and I can successfully tab-complete the addresses when composing mail. But, I have not been able to tab-complete my aliases for my work account. Well, I figured it out, and if this is bothering you, here’s the solution:

In my ~/.muttrc:

folder-hook "gmail.com" "source ~/.mutt/gmail.rc"
folder-hook "example.com" "source ~/.mutt/work.rc"
source ~/.mutt/gmail.rc # open gmail on startup

In my ~/.mutt/gmail.rc:

bind editor <Tab> complete-query
bind editor ^T complete
set query_command = "goobook query '%s'"

In my ~/.mutt/work.rc:

bind editor <Tab> complete        # default Mutt setting
bind editor ^T complete-query     # default Mutt setting
unset query_command               # default Mutt setting
source ~/.mutt/work_aliases

Notice the differences between the key bindings for “complete” and “complete-query” in the different RC files. Also notice that I’m unsetting query_command in my work.rc config. This is necessary to tab-complete the aliases out of the ~/.mutt/work_aliases file (the account details for my Google Account reside in ~/.netrc).

Hope this is helpful to someone else. I’m sure this is only helpful for a very small subset of users, but I wouldn’t be doing my due diligence if I didn’t post it. https://www.xkcd.com/979/ is relevant.

Unknown Scheduled Downtime

Someone is purchasing our house, and we have to be out by the 28th of November. We will not be in our new house until Dec 3rd, at the earliest. During that week, I don’t know where to host my server to maintain a constant connection. Hopefully, I can find a solution, but worst case scenario, it will be down that entire week. I hope not, but heads up just in case.

Thanks, and sorry for any inconvenience.

Use QR Codes For Accessing Wireless Access Points

If you have an Android device with a camera, you can install the ZXing Barcode scanner [1] which supports the following method. It is my understanding, however, that other barcode scanners do not support this, so as cool as this is, it may only serve a very limited audience. The ZXing app doesn’t even support this method on iOS, as far as I know.

The ZXing team has a proposal for scanning barcodes to access wireless access points using a MECARD-like structure [2]. The structure of the format is like this:

WIFI:T:WPA;S:mynetwork;P:mypass;;

The parameter “T” can be one of “nopass”, “WEP” or “WPA” for the security type. The parameter “S” is your wireless access point’s SSID (make sure you append “_nomap” to prevent Google from tracking you [3]). The parameter “P” is the password, if any, of accessing the access point. So, a QR Code containing this information could be something like:

Hopefully other barcode scanners pick up on the proposed standard, and make this more ubiquitous. The obvious advantage is not having to type in lengthy passwords on a small screen. At any event, hope this is useful for some.

1: https://code.google.com/p/zxing/
2: https://code.google.com/p/zxing/wiki/BarcodeContents#Wifi_Network_config_%28Android%29
3: http://pthree.org/2011/11/15/google-wants-to-track-your-physical-location/

Google Wants To Track Your Physical Location

From http://googleblog.blogspot.com/2011/11/greater-choice-for-wireless-access.html:

We’re introducing a method that lets you opt out of having your wireless access point included in the Google Location Server. To opt out, visit your access point’s settings and change the wireless network name (or SSID) so that it ends with “_nomap.” For example, if your SSID is “Network,” you’d need to change it to “Network_nomap.”

Great. Just great. Google will now be tracking my wireless access point unless I append “_nomap” to the SSID. How many people do you think are going to do this? How many people have even changed their default AP login from “admin:admin”? Google is taking advantage of people, and they know it. I hope the backlash is severe, because I find this to be a breach of trust. Whatever happened to “Do No Evil”?