You are currently viewing all posts tagged with privacy.

Geoff Manaugh discusses the deception and misdirection of robot vision.

Starting with the recent Tesla crash caused by the car’s inability to discern the tractor against the bright sky, Geoff discusses how the spread of robots may force us to rebuild our environment — either to support their perceptual systems or hinder them. It’s an interesting idea to ponder, particularly within the context of the rise of drones. Readers of Daniel Suarez can sleep easier at night knowing that razorbacks can probably be defeated with a few mirrors and rubber.

One possible line of defense—among many, of course—would be to redesign your city, even down to the interior of your own home, such that machine vision is constantly confused there. You thus rebuild the world using light-absorbing fabrics and reflective ornament, installing projections and mirrors, screens and smoke. Or “stealth objects” and radar-baffling architectural geometries. A military robot wheeling its way into your home thus simply gets lost there, stuck in a labyrinth of perceptual convolution and reflection-implied rooms that don’t exist.

Cryptographic Identity

Despite its shortcomings, I think PGP is still one of the better ways to verify a person’s identity. Because of this — and because I use my PGP key daily1 — I make an effort to properly secure my private key. Verifying a PGP key is a fairly straightforward process for fellow PGP users, and my hope is that anyone who does verify my key can maintain a high confidence in its signature.

However, I also use other cryptographic channels to communicate — XMPP/OTR and Signal chief among them. I consider these keys more transient than PGP. The OTR keys on my computer are backed up because it takes no effort to do so, but I have no qualms about creating new ones if I feel like it. I don’t bother to port the same keys to other devices, like my phone. My Signal key is guaranteed to change anytime I rebuild or replace my phone. Given the nature of these keys and how I handle them, I don’t expect others to put the same amount of effort into verifying their fingerprints.

The solution to this is to maintain a simple text file, signed via PGP, containing the fingerprints of my other keys. With a copy of the file and a trusted copy of my public PGP key, anyone can verify my identity on other networks or communication channels. If a key is replaced, I simply add the new fingerprint to the file, sign it and distribute. Contacts download the file, check its signature, and thus easily trust the new fingerprint without additional rigmarole.

The first examples of this that I saw were from Yan and Tom Lowenthal. I thought it seemed like a great idea and began to maintain a file with a list of examples whenever I stumbled across then, with a note that I should do that someday2.

Today I decided to stop procrastinating on this and create my own identity file. It is located at pig-monkey.com/id.txt. The file, along with the rest of this website, is in git so that changes to it may be tracked over time.

Inspired by some of the examples I had collected, I added a couple pieces of related information to the file. The section on PGP key signing should provide others some context for what it means when they see my signature on a different key. Even if no one cares, I found it useful to enunciate the policy simply to clear up my own thinking about what the different certification levels should mean. Finally, the section on key management gives others a rough idea about how I manage my key, which should help them to maintain their confidence in it. If I verify that someone’s identity and fingerprint match their key, I will have high confidence in its signature initially. But if I know that the person keeps their secret key on their daily driver machine without any additional effort to protect it, my confidence in it will degrade over time. Less so if I know that they take great care and handling in their key’s protection.

A file like this should also provide a good mechanism for creating a transition and revocation statement for my PGP key, should the need arise. One hopes that it does not.


  1. Realistically, I use PGP multiple times per hour when I’m on my computer.
  2. Since I began my list, Keybase has become a thing. It addresses a similar problem, although seems to promote using services like Twitter as the root of trust. Assuming that you want to stubbornly stick with a PGP key as the root of trust, I don’t see the advantage of using Keybase for this problem, except that it offers a centralized lookup repository.

This post was published on . It was tagged with crypto, privacy.

Isolating Chrome Apps with Firejail

Despite its terse man page, Chromium provides a large number of command-line options. One of these is app-id, which tells Chromium to directly launch a specific Chrome App. Combined with the isolation provided by Firejail, this makes using Chrome Apps a much more enjoyable experience.

For instance, I use the Signal Desktop app. When I received the beta invite, I created a new directory to act as the home directory for the sandbox that would run the app.

$ mkdir -p ~/.chromium-apps/signal

I then launched a sandboxed browser using that directory and installed the app.

$ firejail --private=~/.chromium-apps/signal /usr/bin/chromium

After the app was installed, I added an alias to my zsh configuration to launch the app directly.

alias signal="firejail --private=~/.chromium-apps/signal /usr/bin/chromium --app-id=bikioccmkafdpakkkcpdbppfkghcmihk"

To launch the application I can now simply run signal, just as if it was a normal desktop application. I don’t have to worry about it accessing private information, or even care that it is actually running on Chromium underneath. I use this method daily for a number of different Chrome Apps, all in different isolated directories in ~/.chromium-apps. As someone who is not a normal Chromium user, it makes the prospect of running a Chrome App much more attractive.

This post was published on . It was tagged with linux, privacy.

I stopped worrying and embraced the security freeze.

A credit security freeze denies access to your credit file. I first learned about it last summer from Brian Krebs, but didn’t implement it until a couple months later. It took me about 45 minutes and $20 to activate the freeze with the five major credit bureaus. This goes a long way to reducing the threat of identify theft, with very little energy expenditure required. A proactive defense is superior to reactive monitoring services. If you need your credit pulled monthly or more frequently, constantly freezing and unfreezing your file would probably be an annoying inconvenience. For the rest of us, I’m not sure if there is any good reason not to enable the freeze.


I’ve previously mentioned the Firejail sandbox program. It’s an incredibly useful tool. I use it to jail pretty much all the things. Over the past six months, I’ve found that one of my primary use cases for Firejail is to create private, temporary sandboxes which can be destroyed upon closure. I wrote Firewarden, a simple wrapper script around Firejail, to reduce the keystrokes needed for this type of use.

Disposable Browsers

Prepend any program with firewarden and it will launch the program inside a private Firejail sandbox. I use Firewarden to launch disposable Chromium instances dozens of times per day. When the program passed to Firewarden is chromium or google-chrome, Firewarden will add the appropriate options to the browser to prevent the first run greeting, disable the default browser check, and prevent the WebRTC IP leak. The following two commands are equivalent:

$ firejail --private chromium --no-first-run --no-default-browser-check --enforce-webrtc-ip-permission-check
$ firewarden chromium

Firewarden also provides a few options to request a more restricted Firejail sandbox. For instance, you may want to open a URL in Chromium, but also use an isolated network namespace and create a new /dev directory (which has the effect of disabling access to webcams, speakers and microphones). The following two commands are equivalent:

$ firejail --private --net=enp0s25 --netfilter --private-dev chromium --no-first-run --no-default-browser-check --enforce-webrtc-ip-permission-check https://example.org
$ firewarden -d -i chromium https://example.org

In this example, Firewarden used NetworkManager to discover that enp0s25 was the first connected device, so it used that for the network namespace.

Local Files

Firewarden isn’t just useful for browsers. It can be used with any program, but my other major use case is safely viewing local files. File types like PDF and JPG can include malicious code and are a primary vector for malware. I use zathura as my PDF reader, which is a simple and lightweight viewer that doesn’t include anywhere near the number of potential vulnerabilities as something like Adobe Acrobat, but I still think it prudent to take extra precautions when viewing PDF files downloaded from the internet.

If Firewarden thinks the final argument is a local file, it will create a new directory in /tmp, copy the file into it, and launch the program in a sandbox using the new temporary directory as the user home directory1. Firewarden will also default to creating a new /dev directory when viewing local files, as well as disabling network access (thus preventing a malicious file from phoning home). When the program has closed, Firewarden removes the temporary directory and its contents

$ firewarden zathura notatrap.pdf

The above command is the equivalent of:

$ export now=`date --iso-8601=s`
$ mkdir -p /tmp/$USER/firewarden/$now
$ cp notatrap.pdf /tmp/$USER/firewarden/$now/
$ firejail --net=none --private-dev --private=/tmp/$USER/firewarden/$now zathura notatrap.pdf
$ rm -r /tmp/$USER/firewarden/$now

I use this functionality numerous times throughout the day. I also include Firewarden in my mailcap, which goes a long way to reducing the dangers of email attachments.

Firewarden doesn’t add any new functionality to Firejail, but it does make it easier to take advantage of some of the great features that Firejail provides. Check it out if you’re interested in reducing the keystrokes required to Jail All The Things™.


  1. This is similar to using Firejail’s old --private-home option, which was removed in 0.9.38. However, that option was limited to files in the user’s home directory. It couldn’t be easily used with a file from a USB drive mounted at /media/usb, for instance.

This post was published on . It was tagged with linux, privacy.