Subscribe: Not Quite a Blog 2.0
Added By: Feedage Forager Feedage Grade B rated
Language: English
account  command line  domain  email  gpg  install  key  line  openssl  social media  source  system  text  tools  version 
Rate this Feed
Rate this feedRate this feedRate this feedRate this feedRate this feed
Rate this feed 1 starRate this feed 2 starRate this feed 3 starRate this feed 4 starRate this feed 5 star

Comments (0)

Feed Details and Statistics Feed Statistics
Preview: Not Quite a Blog 2.0

Not Quite a Blog

Not Quite a Blog... definitely mostly Joe!


Some Thoughts on Demanding Passwords at Borders


A simple thought experiment exposes how unimaginably dumb a proposal to demand traveler/visitor social media usernames and passwords is: imagine if a country demanded President Trump's Twitter password as a condition of his crossing their border. It's ludicrous... there are few things more invasive then demanding control of another's identity.

This is completely outrageous, I didn't believe it when a reporter brought it to my attention, it's such a boneheaded idea; it will significantly undermine the safety and security of all social media users. Social media and tech companies would be apoplectic. Asking people that cross the border for their social media identifiers is one thing, and it's plenty invasive enough (CDT and many others argue this threatens privacy and free speech.)

Asking for passwords and other credentials is beyond the pale, akin to asking for a traveler's most intimate thoughts as a condition of travel (or they can opt not to use these services, which is increasingly not an option, especially for business employees who may maintain social media accounts that are not personal accounts).

With that kind of access, they can not only see what you've publicly posted, but things you haven't posted yet, private messages, private lists, they can impersonate you, even do these things on accident. This kind of access is profoundly invasive. We increasingly use social media identities for so much more than just sharing our thoughts; using federated authentication ("log in with your Facebook account!"), people may use their social media account to log into a health care portal, a financial or tax prep account, and many other services.

Moreover, most major social media services offer non-password methods of logging in, for example "two-factor authentication" where they send you a text message that you have to enter in addition to a password to login. What if you don't have access to that particular phone while traveling? If you do, do they get to search your phone to?

This is absolutely ridiculous... There's not even a 1:1 mapping of people to accounts! Many of us have quite a few accounts on the same service... Do I have to disclose them all? Just one? Which one?

There is no way this can stand.

Getting a Let's Encrypt certificate without root on a cPanel domain


I'm a big fan of my friends and colleagues at Let's Encrypt, an effort to make it easier to encrypt the web by offering web encryption certificates for free, for ever. At first, free Let's Encrypt (LE) certificates were not so easy to obtain... you had to be essentially a coder and administer your own server to get it all to work. Not so, anymore! Now the number of ACME clients (the underlying protocol that Let's Encrypt uses) has exploded. So, while I am only a bit of a coder, I wanted to see if it could be possible for someone with minimal system administration skills to actually get an LE cert and install it. The answer is yes, it is relatively easy to do! My task: I wanted to see if a non-root (non-adminstrative) owner of a website using the cPanel hosting software could get an LE cert. To follow this, you need to be reasonably familiar with the command-line, but not much else. You'll need to be able to login to the command line of your domain's server. Then, you'll want to make sure both openssl and python are installed (likely yes): % which openssl /usr/bin/openssl % openssl version OpenSSL 1.0.1e-fips 11 Feb 2013 % which python /usr/bin/python % python --version Python 2.6.6 (Pay attention to that Python version as it throws a wrinkle into this later.) We'll be using the acme-tiny python script from Daniel Roesler. You can follow those instructions, but I'll repeat them here. You'll need a private account key to identify yourself with LE (this generates a 4096-bit RSA key pair, account.key, that contains both the private and public keys). You'll also want a keypair for your domain (domain.key): openssl genrsa 4096 > account.key openssl genrsa 4096 > domain.key Be very careful with these files as they contain the private keys to the kindgom! You can extract the public key from the key pair by: openssl rsa -in account.key -pubout > While you can generate the keys on another system (like your laptop), you'll need to copy them over to your server and then run the rest of these commands on that server. You'll now need to create a certificate signing request (CSR) that asks LE to sign your public key. #for a single domain openssl req -new -sha256 -key domain.key -subj "/" > domain.csr #for multiple domains (use this one if you want both and openssl req -new -sha256 \ -key domain.key \ -subj "/" \ -reqexts SAN \ -config <(cat /etc/ssl/openssl.cnf <(printf "[SAN]\,")) \ > domain.csr (sorry, this gets cut off so copy and paste it into a text editor before doing anything with it.) And note that the line that reads cat /etc/ssl/openssl.cnf is specific to Debian flavors of linux. You'll need to change to something like the following depending on the system you're running: #change "/etc/ssl/openssl.cnf" as needed: # Debian: /etc/ssl/openssl.cnf # RHEL and CentOS: /etc/pki/tls/openssl.cnf # Mac OSX: /System/Library/OpenSSL/openssl.cnf Now, you need to make a directory that your user account on the server can write to in a very specific place that ACME/LE expects it to be: mkdir -p /foo/www/.well-known/acme-challenge/ Where /foo/www/ is the path on your server to your root web directory. Here's where the magic happens. You'll now want to use acme-tiny to send the CSR under your LE account key to the LE to do the challenge (prove that you're on the domain that you claim): #run the script on your server python --account-key ./account.key \ --csr ./domain.csr \ --acme-dir /foo/www/.well-known/acme-challenge/ \ > ./signed.crt This will result in a file called signed.crt that is the LE-signed certificate for your domain! Note: if you are running Python earlier than 2.7 you don't have the argparse module. In that case, you'll want to add the directory you're in to the PYTHONPATH variable and then install argparse inside your account with: easy_install --install-dir=. argparse If you are running the nginx webserver, you'll [...]

Is it hard to install PGP on a Mac?


So what if you don't want the NSA to see a particular file or email? If they're really wiretapping the whole goddamn internet, how can you keep secrets? Well, you have to encrypt them. And the standard for strong encryption is PGP -- Pretty Good Privacy. PGP will lock up files and emails so that others cannot break into them. I've heard people say recently that PGP is very hard to install, understand, and use ("Guardian reporter delayed e-mailing NSA source because crypto is a pain"). PGP -- or the open source equivalent GnuPG (Gnu Privacy Guard) -- is an encryption program, essentially like a mathematical lockbox for data and files... you can use it to encrypt files and emails in such a way that no one can get access to that information without compromising your laptop or desktop. After hearing it was hard and having a bit of experience with it myself, I asked myself, "Just what does it take to install a working version of PGP from scratch and send email? How hard could it be?". I decided to try and see what the install process looks like installing from scratch. (Now, of course, I'm on a Mac and will want to install a mac-specific version of it and I'll want it to work with Mac email programs like or Mozilla Thunderbird. (Sorry, Windows and Linux folks!)) It turns out it's pretty damn hard, in general... that is, if you want to do it right, in my opinion. There are two options: a somewhat less difficult way and a hard way: The more difficult way -- I describe below -- has the added benefit of being likely maintained indefinitely and being built (compiled) directly from the canonical (standard) source code for GPG. The easier way uses -- what appears to be -- a very snazzy piece of software maintained by a small number of volunteers, GPG Tools. (I don't have anything against GPG Tools -- I use it myself for a number of things -- but I'm wary in crypto of using boutique tools not everyone else is using and relying on implementations that could disappear. I also prefer for this kind of security tool to build it from the source code that is being actively maintained and that everyone else is using.) With that: If you don't share my concerns with the uniqueness and dependence of GPG Tools, I very much recommend you simply install it and follow their getting started guide. GPG Tools is open source and easily uninstalled, and I bet even PGP/GPG vets will find something to love with it's keychain manager and Services integration... and it even installs non-destructively over existing MacPorts and Fink GPG installs (more about what those are next). If you go this route, you'll still want to, at least, read the material I highlight in step 6 below; even with working encryption software, you will still need to know a bit about what encryption is and how to properly use it. Be sure to install it from the official location (check the SSL lock!) and check the SHA1 signature of the file (something like: shasum GPGTools-2013.5.20.dmg from the command-line). Ok, with that... if you want your own built-from-source version of GPG that can also be used to encrypt or sign email), here's how. First, I'm sorry to say but you'll need to become familiar with the basics of the Mac command-line used in This may sound onerous but it will only pay dividends in the future as you'll probably want to tinker more. Here is a good place to start: "An Intro to Mac OS X's Command Line Interface". Why do you need this familiarity? Because the open source, freely and generally available version of PGP -- GPG -- is best available to your system as a working command-line program, instead of the alternative of a more traditional Mac-like package (the approach of GPG Tools, discussed above). You'll need to install Xcode and the command line tools from Apple (The Command Line Tools can be downloaded from inside Xcode's Preferences or in a separate package). These tools provide all the computer programming tools a Mac developer needs to turn human-readable source code int[...]

Sorry, China!


I have to apologize to China, although if you're Chinese proper, I doubt you'll see this apology unless you're on vacation somewhere else or using a proxy.

I've noticed a steady uptick in traffic to this site, notably this blog, over the past few months:

After some sleuthing, it seems I'm pushing 15-20 GB of traffic to China alone each month! With something like 564 million Chinese on the internet (42% penetration), I guess this shouldn't be surprising. And, yes, it was all legitimate HTTP/HTTPS traffic, mostly to this blog.

As I can't afford to pay for extra bandwith, my only option was to throttle traffic to China (e.g., using this very handy .htaccess method -- for Apache webservers -- and list of Chinese IP addresses).

That seems to have worked:

I feel bad that I have to use such a blunt tool as this blocking maneuver, but I'm not sure what else to do. Please let me know if, for some reason, this impacts you (I cannot imagine how it would).

Helping LA County Build a Voting System


This past week I was at the kick-off meeting of the LA County Voting System Assessment Project's (VSAP) Technical Advisory Committee. The VSAP is Registrar/Clerk Dean Logan's intense and groundbreaking effort to design, develop, procure and implement a publicly owned voting system. I am honored to be asked to serve on such an important body. LA County is the largest election jurisdiction in the US, with 5 million registered voters, 10 languages, 5,000 precincts and a very large physical area. The county currently uses the InkaVote Plus voting system (with Audio Ballot Booth for accessibility), which is essentially an overhaul of former punchcard equipment to use inked styluses for marking and to provide in-precint checks for the voter in case they make mistakes. Here is the InkaVote Plus system and the Microcomputer Tally System (MTS) that is used to rapidly count (>1,200 ballots per minute!) ballots after they're returned to the Registrar's Norwalk, CA headquarters: My fellow committee members include: Henry Balta (Senior Assoc. CIO, LA County) Mike Byrne (Professor of Psychology and Computer Science, Rice) Josh Franklin (IT Specialist, NIST) Diane Goldin (Policy Coordinator, AATAP) Joseph Lorenzo Hall (Senior Staff Technologist, CDT) Brian Hancock (Director, Testing and Certification, EAC) Jared Marcotte (Technology Manager, Pew) Noel Runyan (Principal, Personal Data Systems) Rich Sánchez (CIO, LA County) Pam Smith (President, VVF) Charles Stewart III, (Professor of Political Science, MIT) David Wagner (Professor of Computer Science, UC Berkeley) The mission of the TAC is to provide technical advice to LA County through a design and development process to meet a variety of goals and principles that LA County has determined its voting system must meet. While we'll have an official web page and other materials soon for public perusal, I was able to take a number of photos and videos during a tour of the tabulation and storage facilities that we had during the end of the day. Find them at this Flickr photo set. I'll leave you with the following video, that shows just how fast their card reader tabulation system, the MTS, can count ballots -- a blazing 600 ballot cards in 28 seconds! This is just one example of a metric that will be difficult to match in a new system! Original post blogged on b2evolution.[...]

Trolls of the long-lived variety


Some of you close to me will know that I spent a brief period of unpleasantness trying to do good work on Wikipedia when I was in graduate school. I haven't made serious substantive edits to Wikipedia since that time.

The "high-water mark" of that period was when I started to try and moderate some Wikipedia disputes as part of the mediation cabal. I've always been a diplomat and have a passion for helping folks come to a common understanding. One instance particularly stood out as unpleasant: it resulted in someone I can only term a "wacko" writing a 60-page letter to the Dean of my program, AnnaLee (Anno) Saxenian, about alleged misconduct on my part as a mediator. Anno, of course, paid zero heed to it as she's familiar with my integrity and diplomatic tendencies.

Fast forward to this weekend, I received a communication from the person who felt wronged, almost 7 years later (and wrote the 60-page letter to Anno). He had the gall to reinstate a demand for monetary compensation (I forget why).

Anyway, in the interest of not feeding trolls but holding them up, I give you Thomas Cool, likely still indefinitely banned from Wikipedia:

-------- Original Message --------
Subject: W.r.t. democracy
Date: Mon, 18 Feb 2013 09:51:24 +0100
From: Thomas Cool / Thomas Colignatus

Dear dr. Hall,

You may recall my person from an unhappy situation at wikipedia in 2006. Someone asked me what I thought about the current entry on Arrow's theorem, and this caused me to update my comments on that. It appears that wikipedia has been misleading its readers since 2006. That update of my comments is in English as a supplement to a Dutch text:

I think that it is fair to apply 4% interest over the seven years since 2006. The sum of $150 turns into $197. I use paypal at (still the same). My advice is that you also buy a copy of Mathematica and a license of my Economics Pack (a professional licence now is $99), so that you can start studying on the problem.

Allow me to congratulate you on completing your Ph.D. thesis. My hope is that you are better aware of scientific integrity now. Nevertheless, allow me to advise you to discuss the issue with your director Leslie Harris, just to be sure. We must hope that a Center for Democracy & Technology really understands what democracy is about.

Sincerely yours,

Thomas Cool / Thomas Colignatus Econometrician and teacher of mathematics Scheveningen, Holland

PM. The other relevant links:

Please note that I switched from to this different location, but otherwise the links are the same.

Thunderbird and .ics files from Exchange


Sigh. Outlook should die, die, die. Short version: if you use Thunderbird to read email and you regularly get meeting.ics files from people, install Show All Body Parts in order to open/save them. Longer version: Lately, I've had the following problem: Using Mozilla's Thunderbird email client (v17.0.2), when I receive a meeting reminder/calendar entry from a co-worker -- meeting.ics -- no matter what I do, I cannot seem to save the attached file. When I attempt to "open" it, Thunderbird responds with an error and says there's no file and when I "save" it, no file is saved. Nothing. Frustrating. Up until today, I had been able to reasonably cope with this by looking at the raw email message source ("View" -> "Message Source"), which includes the .ics file in text at the very end. It's not pretty; it looks something like: --------------030809050301030806060808 Content-Type: text/calendar; name="invite.ics" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="invite.ics" BEGIN:VCALENDAR PRODID:-//Google Inc//Google Calendar 70.9054//EN VERSION:2.0 CALSCALE:GREGORIAN METHOD:REQUEST BEGIN:VTIMEZONE TZID:America/Los_Angeles X-LIC-LOCATION:America/Los_Angeles ... Not ideal, but oh well. At least I can read it. However, today, I did that and saw this (!!!): --_000_C6E91EC3EACD3E44B2A8242C2663C396027136FD09exmb2phlpewpe_ Content-class: urn:content-classes:calendarmessage Content-Type: text/calendar; charset="utf-8"; method="REQUEST"; component="VEVENT"; name="meeting.ics" Content-Transfer-Encoding: base64 QkVHSU46VkNBTEVOREFSDQpNRVRIT0Q6UkVRVUVTVA0KUFJPRElEOk1pY3Jvc29mdCBFeGNoYW5n ZSBTZXJ2ZXIgMjAwNw0KVkVSU0lPTjoyLjANCkJFR0lOOlZUSU1FWk9ORQ0KVFpJRDpFYXN0ZXJu ... OMG. That's not readable. It's our old friend base64 encoding. Sigh. It's not hard to decode base64 and any good techie should be able to do it... but this is my email and why should I have to write a script or something just to read email!? So, I dug a bit deeper. It turns out this is a "feature" of MSFT's Exchange/Outlook product line. That is, the MIME type they use for this is multipart/alternative which means, "here are a few different versions of this email, pick whichever one you want, they are the same". This is useful if you want to send a plain text version of an email and also an HTML version of an email that looks prettier and includes clickable links and such. However, Outlook and Exchange include text/plain, text/html and text/calendar... and -- here's the kicker -- not all the stuff in the text/calendar version is included in the other two! And to make things totally ridiculous, Outlook transforms email into base64 encoding!!! So, you can end up exactly with the situation I had today: I had a calendar invite but no indication from the body of the email the date and time of the meeting, and when I viewed the message source, it was unreadable without decoding from base64. Turns out, the Thunderbird extension called Show All Body Parts will display all the alternative message formats when you ask it to ("View" -> "Message Body As" -> "All Body Parts"). Whew. BTW, this is a 3.5 year old bug: Bug 505024. Original post blogged on b2evolution.[...]

And, we're back...


Due to a php upgrade at my wonderful host Birdhouse, this blog has be inoperable for a few months... I've upgraded the b2evolution software underneath and will try to write about once a week. I've disabled comments as they're totally useless, don't read comments!

Note that my work, CDT, has its' own set of blogs I contribute to regularly.