• 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.

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.

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!

• 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).

|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.

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

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.

% 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.

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:

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:

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.

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.

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.

Thanks, and sorry for any inconvenience.

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/

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”?

Case in point: I just filled out a form for a survey to “enter to win a $1000 shopping spree). You know, the crap that you constantly get bombarded with at the checkout stand when the cashier gives you your receipt. I always ignore them, but then thought to myself “I’ll never win if I don’t at least try”, so I gave my first survey a go. At the end of the survey, it asked for my email address. I figure they’ll sell it for marketing purposes, and I have a Google Mail address, so I’m not really that worried about the SPAM (their SPAM filters are amazing). But, I would like to track who they are selling my address to. So, I gave them the following address:

aaron.toponce+survey-provider@gmail.com

To which, I received an error that the email address is not a valid address. AHEM! Yes it is, and it’s this lack of support for standards that I’m talking about. My email address was rejected, yet it’s perfectly legal according to RFC 5322. You see, according to that RFC, I get the following flexibilities with my email address:

• ASCII upper and lower case letters (a-z & A-Z).
• ASCII digits 0-9
• ASCII characters !#$%&’*+-/=?^_`{|}~
• ASCII dot (.) so long as the local part of the address does not contain the dot consecutively, and it does not start with a dot.
• ASCII characters ” ” (space) and “(),:;<>@[\] are allowed with certain restrictions.

So, I could have the following email addresses, all of which are perfectly legit according to the RFC:

• “[Aaron Toponce]“@gmail.com
• a&t@gmail.com
• aaron.toponce+business@gmail.com
• aaron’s-travel-agency@example.travel
• {atoponce}@gmail.com

Yet, these will get ejected outright in most web forms I’ve come across. Specifically interesting is the .travel TLD. I’ve had web forms enforce TLDs that are less than 4 characters, which is absolutely absurd for the .travel and .museum TLDs. I’m guessing one of two things is happening with these web forms:

1. The developer used the regular expression [A-Za-z0-9_\-\.]+@[A-Za-z0-9\-\.]+ for validating addresses.
2. There is absolute denial for the use of “plus-addressing” as a DEA.

I’m guessing the first is more likely the scenario than the second. Regardless, Of course, when we’re talking about the rules of RFC 5322, we’re no longer talking about regular expression syntax. We’re talking about grammar. If your page is designed in PHP, Python, CGI, or whatever, you should use a real parser for parsing the email address, rather than reinventing the wheel yourself. What’s unfortunate, is this disease of not properly parsing valid email addresses is found in some big companies and sites too, not just the little guys.

Now, Google COULD provide true DEAs, such as Yahoo! Plus does with their subscribers, However, I should be able to create an DEA with an already existing email address, rather than creating completely new ones, because people refuse to conform to the standards. So Google, if you’re reading (I know you are), you may want to consider proper DEAs, seeing as though “plus addressing” isn’t working, and it is important to some.

Stéphane Bortzmeyer has already blogged about this, and he uses the #ral hashtag on Identica and Twitter to vent his frustrations, which stands for “Refus d’Adresses Légales” or “Rejection of Legal Address”. Well, I’ve determined that I will be doing the same, although I’ll bacronym the hashtag to “Rejected And Legal”, along with the url to the site that refuses to adhere to the RFC.