Some people have very strong feelings about the nature and the content of the Second Amendment to the Constitution of the United States. I do not currently have strong feelings about this amendment. I have never owned a firearm, so this right afforded to me has always been an intellectual one, rather than a practical one. As such, any modifications to the Second Amendment will have very little bearing on my day-to-day life.
A thought experiment recently occurred to me, though.
Imagine that a new constitutional amendment were to pass, either by two-thirds vote of all members of the House and Senate, or by two-thirds vote at a national convention, that substantially limited personal ownership of firearms. Would you support that amendment as the rule of law?
As a thought experiment, much is left out by design. Of course the specific nature of the changes imposed by the new amendment, and its implementation details, would effect how one feels about it. The thought experiment is not asking how you feel, but whether you would adhere to the Constitutional process and submit to the will of the people.
I can't begin to imagine how slave owners felt at the passage of the Thirteenth Amendment, knowing that one day a cultural (and commercial) institution was legal and the next day it wasn't. There's no doubt that many slave owners rejected the legality of the amendment. There were a lot of creative maneuvers executed after passage of the Thirteenth Amendment to preserve the previous status quo as much as possible, making every effort to subvert the spirit of the law.
I wonder what lessons we might learn from the Thirteenth Amendment about any potential changes to the Second Amendment.
Long time reader Bob O. sent the following (unencrypted) question to me in response to my GnuPG + mutt + OSX + GMail article:
Question on your GPG article: The paragraph on why you don't install your
private key on your mobile or home devices seems to imply that you have
better physical security on your work laptop than those devices. I realize
that this opens the article up to a discussion of how to secure your
private key, but could you add a brief overview of your choices on where to
store your private key?
This is an excellent question, and I did gloss over it in my original post.
My mobile phone is not currently encrypted, though I have thought about enabling that feature. Even if my mobile phone were fully encrypted, I'm still pretty suspicious of both Android and iOS against covert attacks from government actors. The Snowden revelations indicate that NSA, GCHQ, and potentially others have found very subtle ways to compromise a mobile phone without physical access to the device.
I could keep my private keys on a device at my house, but I'd have no real way of knowing if any of those devices were physically attacked in my absence. I realize it's unlikely that someone would break into my house for the sole purpose of accessing my GnuPG private key, but this seems like an easy precaution to take. The media on a Raspberry Pi is simply an SD card or external HDD, both of which would be easy to make copies of and then reconnect. Similarly, I don't keep my private key on my server at DigitalOcean because I have no way of knowing if the virtual machine had been cloned.
(Even absent a specific effort to obtain my GnuPG private key, the physical loss of a device containing said private key should necessitate a revocation of my public key. There's simply no good way to know if the private key was compromised or not.)
My work laptop is usually with me. It's a unibody MacBook, so it's not easy to access the hard drive directly (though I admit to ignorance as to whether there are easy ways to clone the hard drive without removing it). It also employs full disk encryption, so none of the data on the device is (easily) available to anyone who might gain access to it. OSX is not immune to malware, but it is fairly resistant to it, in general. If an actor were able to compromise my work laptop by way of specially crafted malware, there's little I could do: I don't think I'm quite paranoid enough to spot (or react to) a custom attack against me, whereas I am savvy enough to spot (most of) the general kinds of malware looking for easy marks.
So while I do think OSX may have some security advantages over my mobile phone, it's more a matter of limiting the exposure of my private key to the minimum number of devices that makes practical sense.
I do use a complex password for my private key, but if someone has access to a copy of my private key then they can attack it all day long. They can run through every permutation of every possible password until they get access. It might be time consuming, and it might be expensive, but eventually the key will be cracked.
This password for my private key is not stored in my password manager, and to the best of my knowledge not written down anywhere. By using the GPG agent I can avoid repeated entry of my private key password. This reduces, but does not eliminate, the risk of keyloggers.
There are additional things I can (and may) do to further enhance my security. I do not currently have an expiration on my GnuPG key. I should set one, and take the time to extend that expiration as needed, as long as my key hasn't been compromised. I should also generate a revocation certificate.
I don't believe that I'm the target of government (or other) surveillance, so extreme paranoia is not driving most of my decision making. Nonetheless, I'm trying to take reasonable precautions to protect my private key from easy exploitation. I do have an offline backup of my private key stored securely, in case my work laptop suffers a catastrophic failure. Hopefully I'll never need to use it.
A little over two years ago I generated a new GnuPG key. I had been using a 1024-bit key created in 2004, so I created a new 4096-bit key. I've used this new key only a handful of times since it's creation.
In early 2014 I joined Keybase with high hopes of seeing an increase in GnuPG adoption. A few folks I know use the service, and we've cross-validated one another; but none of them have sent me any encrypted messages. Of course, Keybase's larger utility is as much in "proving" my various online identities as it is in facilitating encryption.
At the 2015 Ohio LinuxFest, one of the birds-of-a-feather sessions was a keysigning party. There were about a dozen of us in attendance, some complete novices and some GnuPG experts. It was a great opportunity to meet a few new folks, as well as pick up a few GnuPG best practices.
All of this took place shortly after I declared my intention to learn mutt for my day-to-day email usage. Mutt has great support for GnuPG, and I was hopeful that this support would encourage me to use GnuPG as much as mutt.
I've learned rather a lot in the last couple of weeks, and this post is an effort to record and share some of that information for others. Aside from a few OSX specific bits, most of what follows should be generally applicable to Linux users as well.
All of what follows is my own opinion. You likely don't know me, so you should not trust my opinion. Do your own research, and figure out what settings make sense for you! If you find any factual inaccuracies in my suggestions, please contact me and let me know!
I've been using OSX exclusively for my day-to-day desktop computer use. (My employer has a few compliance requirements not yet easily satisfied by Linux, so this is as close as I can get to a POSIX-based system.) There are two ways to install GnuPG onto an OSX system: Homebrew or GPG Suite. I chose the latter, because it provides good Finder and Mail.app integration, but these are conveniences only.
The default options for GnuPG are okay, but not great. Depending on your level of paranoia, the defaults may be downright disastrous. One of the more interesting documents I found was Operational PGP, which was chock full of usefully paranoid suggestions. That, combined with OpenPGP Best Practices provided the bulk of my
In particular, ensure that you're not using old and insecure algorithms:
default-preference-list SHA512 SHA384 SHA256 SHA224 AES256 AES192 AES CAST5 ZLIB BZIP2 ZIP Uncompressed
personal-cipher-preferences AES256 AES192 AES
personal-digest-preferences SHA512 SHA384 SHA256 SHA224
Also ensure that you're not leaking information unnecessarily:
When using GPG Suite on OSX, be sure to make use of the GPG agent:
The agent makes it much less hassle to use GnuPG. And it will come in particularly handy with mutt, too!
There was some interesting disagreement after the Ohio LinuxFest keysigning party with respect to proper next steps. Do you encrypt the signed key that you send? Do you individually sign each user ID on a public key? Do you push to keyservers? Each keysigning party may have different norms, so be sure to get answers to these questions before taking any actions! The Debian keysigning instructions may be useful as a reference for possible best practices.
GNU/Linux users are encouraged to use caff, which handles much of the tedium of signing and sending signatures to the folks at a keysigning party. Unfortunately, caff doesn't work on OSX (despite being in homebrew). Additionally, caff sends mail directly from the host on which it is invoked, which may not work for laptops connected to residential ISPs. You may need to correctly configure a relay host in order to make the most of caff.
Once you have GnuPG configured, take a look at pass, a GnuPG based password management system for Linux and OSX. pass works well for individuals as well as groups. We use it at work, and it's proven extremely helpful.
Installing mutt on OSX is best accomplished with Homebrew:
brew install mutt was my first attempt, and this does work well enough. But this default incantation leaves out a newer feature of mutt's GnuPG support: GPG Made Easy (GPGME). GPGME allows you to drastically simplify your mutt config file with respect to GnuPG. In order to get mutt to use GPGME, you need to manually compile it:
brew install mutt --build-from-source --with-gpgme --with-slang
With GPGME, the relevant section of my
.muttrc file is this:
I realize that looks like a lot, but compare it with the recommendations from the mutt wiki.
If you're a GMail user, you can use something like the following to get mutt to connect:
set imap_user = "firstname.lastname@example.org"
set smtp_url = "smtp://email@example.com@smtp.gmail.com:587/"
set from = "firstname.lastname@example.org"
set smtp_authenticators = 'login'
set folder = "imaps://imap.gmail.com:993"
set spoolfile = "+INBOX"
set postponed ="+[Gmail]/Drafts"
set record="+[Gmail]/Sent Mail"
OSX users: take particular note of the
set smtp_authenticators directive. This resolves a bug with the homebrew formula for mutt. I was unable to login without this.
I don't want to type in my GMail password every time I connect, and I don't really want to leave a plaintext copy of my GMail password in my
.muttrc. Since I'm using GPG and the GPG agent, I can encrypt my password and decrypt that on the fly when mutt starts!
source "gpg -d ~/.mutt/passwords.gpg |"
For lots of other great suggestions about dealing with GMail, check out GPG / Mutt / Gmail by Ben Nagy. I particularly liked the recommendations for SSL hardening, and not blindly trusting SSL certs presented by IMAP and SMTP servers.
It's been a fun adventure learning some of the intricacies around GnuPG, mutt, and GMail. The fact that I'm using OSX does tend to complicate things, since so many howtos online are written for GNU/Linux users.
I still use the GMail web interface with depressing frequency, despite all the effort to configure and learn mutt. I'm trying hard to use mutt exclusively, but that's quite an uphill battle.
One of the interesting things that all of the above work does not address is shared access to my Inbox from my laptop and my mobile phone. I will not install my GnuPG private key onto my mobile phone, so any encrypted emails I may receive will need to lie unread until I can access them on my laptop. Similarly, I won't install my private key onto my VPS server, or a Raspberry Pi at home, or any other device I'm not likely to have in my immediate possession at most times.
UPDATE: I discuss private key security in a subsequent post.
So far this hasn't been an issue, given the paucity of encrypted emails I receive. If encrypted emails were to become more commonplace for me, I might need to revisit my policy against my private key on my phone, since my phone is where I read the surprising majority of my emails these days.
Eric Raymond's "How To Ask Questions the Smart Way" was published in 2001, and has been very popular ever since. It gets referenced on my local Linux User Group mailing list with some frequency (usually alongside an admonishment to stop top-posting). To be sure, it contains a lot of good advice for how to perform research, how to frame a question, and what salient information is generally a minimum required to solicit help.
And yet, I absolutely despise this document. Raymond spends roughly ten thousand words telling people what is expected of them when they seek help, including how not to react like a loser, but can't be bothered to write more than four hundred words on how to answer questions in a helpful way.
In an effort to remedy this glaring oversight, I share here some guidance I've learned over the last dozen years participating in open source communities, as both a novice and an expert.
Much of Raymond's treatise is predicated upon the assumption that the people providing answers are all Very Busy People, and their time is not to be squandered.
We take time out of busy lives to answer questions, and at times we're overwhelmed with them.
I counter that the people asking for help are equally Very Busy People, and deserve to be given the same respect that you expect.
Many times, people asking for help are frustrated. They may be under a deadline. They may have inherited a problem about which they know next to nothing. Solving the problem is not what they want to do: they want to do whatever it is that the problem is preventing them from doing.
The person asking for help is already taking time out of their busy day just to ask for help. Quite often in this day and age, the most expedient solution to an open source problem is to stop using open source. Anyone who takes the time to ask a question deserves our support.
Raymond's second piece of advice about providing answers is "Reply to a first offender off-line." The very verbiage of this advice makes clear that he perceives a power differential, and that people who don't ask questions in The One True Way are offenders.
Are we, as a group, more interested in enforcing a specific set of behaviors or are we more interested in fostering a culture of respect, collaboration, and participation? To view interlocutors as "offenders" ensures the former. I'm much more interested in the latter.
So if someone doesn't follow every one of Raymond's pronouncements for asking a good question (or, God forbid, top-posts!) I say "Who cares?" Be nice to them. Demonstrate that they are amongst friends. Gently and positively encourage them toward preferred behavior, but do so in a way that makes sense. There's a history to many of the cultural elements of open source, and new members won't be privy to that history. To scold, reprimand or "correct" people, off-line or on-line, is to promote a culture of negativity, and to preserve the perceived power differential.
Why not share -- openly -- the history of why cultural norms are what they are? To do any less is to say that things are the way they are by simple fiat.
An important corollary exists: be willing to accept that times have changed and the original reasons for any specific culture behavior no longer obtain.
If you subscribe to a mailing list with the intent of both asking and answering questions, take some responsibility for the fact that you have made a conscious choice. Other list participants aren't coming to you personally, begging for your wisdom. They're casting their questions into the ether, eagerly awaiting an answer from anyone. If you're too busy to deal with that, then perhaps you're a member of the wrong mailing list?
If you're a member of a technical mailing list, you must accept that there will be a steady stream of new participants joining the list. New members will be ignorant of the list's cultural norms. They may never have heard of Eric Raymond before, and so not realize the implied significance of your link to his screed.
You should be as patient with the first new member as with the ten thousandth new member. These are people who have taken their time to participate in the forum, just as you have. In time, they too will be expected to shepherd new members, such that the burden of cultivating culture is shared and distributed.
Successful communication requires real effort from all parties involved. It is not acceptable to put the entire burden for successful communication onto the person who is struggling to find an answer to a problem. If you want to help, you need to accept that there is a burden to you for doing so. You'll hear the same questions again and again. You'll have to repeat your answers again and again. You'll misunderstand people. People will misunderstand you.
The end result of your efforts will be a gradual increase in the number of like-minded people willing and able to help share the burden of providing help to those who need it. And isn't that community empowerment one of the reasons we all like open source to begin with?
I've been using a Samsung Galaxy S3 on Verizon for the past two years. Shortly after I got the phone, I installed CyanogenMod onto it. I've been extremely happy both with the device and with the software. I've been less happy with Verizon, in no small part because of their complicity with domestic spying efforts by the US federal government; but also because of their customer tracking efforts. I've also been frustrated at the amount of our monthly Verizon bill, and the on-going battle between our teenage daughter and our "family plan" allotment of mobile data.
I installed CyanogenMod onto the phone originally for two reasons. First, I wanted more frequent updates from the upstream Android project. Carriers are notoriously slow to update the OS on their phones. Second, I didn't want any of the bloat that Verizon "helpfully" pre-installs on their phones. I didn't need an NFL application, or their silly Navigator application, or anything else they stuffed into the phone for me.
I read with interest Tim Bray's post about his acquisition of the OnePlus One phone. I wasn't exactly in the market for a new phone, but I was intrigued enough by this phone to investigate a little more. All the reviews I read gave it pretty high marks. The price was certainly competitive. The "vanilla" installation of CyanogenMod was extremely appealing.
The problem was the sales model: in order to purchase a OnePlus One, an "invite" was needed. As I opined on Google+, this may have been a clever inventory control mechanism, or might have simply been a marketing gimmick. Either way, it prevented me from engaging with the company. I poked around a little, trying to find an invite, but quickly gave up.
Then Dan alerted me to a special promotion scheduled for January 20: the OnePlus store would be open for two hours without the need for an invite! I was able to purchase two phones: one for me, and one for Jonah, who was in need of a newer device. The units shipped surprisingly fast.
The OnePlus is a GSM phone, though, which does not work on the Verizon network. That's fine, as I wanted off of Verizon anyway. I switched to T-Mobile. The transfer process was easy, though I admit to being absolutely perplexed by "cell phone economics". Case in point: the T-Mobile offer to pay my Verizon early termination fee. In order for this offer to be valid, I had to trade in an old phone (Jonah's), and buy a new phone from T-Mobile. I was bringing two of my own devices to T-Mobile, but in order to get the ETF payoff, I was required to buy a phone from them.
The ETF for my old phone was $180. I bought a $30 phone from T-Mobile, which I did not activate and will likely never use. T-Mobile paid my ETF. How does this work? I honestly don't know.
As for The OnePlus One itself, I am quite happy. It is a bigger phone than I'm used to, but not uncomfortably so. It's just about as thick as the Samsung Galaxy S3, but feels to weigh just a shade less. The 64GB "Sandstone Black" model that I purchased has an interestingly textured back cover. Everyone who has held the device has commented on it. It's not quite abrasive, but it's definitely not smooth. I've quickly gotten used to it. The 16GB "Silk White" model which I purchased for Jonah has no such texture.
So far, the battery has been nothing short of great: in my normal course of action, I end the day with more than 70% battery life remaining. The phone is snappy, the GPS is quick to lock, and the screen is nice. I'm not a smartphone aficionado, so I find the OnePlus One to be a nice step up from the Galaxy S3.
The version of CyanogenMod installed is 11.0-XNPH44S, which equates to Android 4.4.4. I'd like to get Android 5.0, codenamed "Lollipop", but I don't know how quickly OnePlus will offer that. The OnePlus is officially supported by CyanogenMod, so I may be able to get Lollipop on my own before the OnePlus distribution system provides an over-the-air update.
The one obvious drawback to the OnePlus One is that it is not a mainstream device, so accessories are not easily purchased. Cases and screen protectors are really only available from the OnePlus online store. Plan ahead if you get this phone, and order the case or screen protector at the same time.