You are currently viewing all posts tagged with privacy.

Identifying individuals by using a laser to record the vibrations of their heartbeat is a neat idea.

The Pentagon’s new Jetson laser sounds like a simple concept:

A new device, developed for the Pentagon after US Special Forces requested it, can identify people without seeing their face: instead it detects their unique cardiac signature with an infrared laser. While it works at 200 meters (219 yards), longer distances could be possible with a better laser. “I don’t want to say you could do it from space,” says Steward Remaly, of the Pentagon’s Combatting Terrorism Technical Support Office, “but longer ranges should be possible.”

Contact infrared sensors are often used to automatically record a patient’s pulse. They work by detecting the changes in reflection of infrared light caused by blood flow. By contrast, the new device, called Jetson, uses a technique known as laser vibrometry to detect the surface movement caused by the heartbeat. This works though typical clothing like a shirt and a jacket (though not thicker clothing such as a winter coat).

I wonder if they aim center mass, or if they can get a reading off the carotid. If it’s the former, it seems likely to be defeated by wearing plates, which is probably good life advice if the Pentagon is interested in you anyways.

The article also mentions that “[o]ne glaring limitation is the need for a database of cardiac signatures”, but I suspect they can just acquire that data from Apple, Strava, Fitbit, etc.

via Infowarrior

This post was published on . It was tagged with micro, 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.

Using Network Trust

Work continues on Spark, my Arch Linux provisioning system. As the project has progressed, it has created some useful tools that I’ve spun off into their own projects. One of those is nmtrust.

The idea is simple. As laptop users, we frequently connect our machines to a variety of networks. Some of those networks we trust, others we don’t. I trust my home and work networks because I administer both of them. I don’t trust networks at cafes, hotels or airports, but sometimes I still want to use them. There are certain services I want to run when connected to trusted networks: mail syncing, file syncing, online backups, instant messaging and the like. I don’t want to run these on untrusted networks, either out of concern over the potential leak of private information or simply to keep my network footprint small.

The solution is equally simple. I use NetworkManager to manage networks. NetworkManager creates a profile for every network connection. Every profile is assigned a UUID. I can decide which networks I want to trust, lookup their UUID with nmcli conn, and put those strings into a file somewhere. I keep them in /usr/local/etc/trusted_networks.

nmtrust is a small shell script which gets the UUIDs of all the active connections from NetworkManager and compares them to those in the trusted network file. It returns a different exit code depending on what it finds: 0 if all connections are trusted, 3 if one or more connections are untrusted, and 4 if there are no active connections.

This makes it extremely easy to write a script that executes nmtrust and takes certain action based on the exit code. For example, you may have a network backup script netbackup.sh that is executed every hour by cron. However, you only want the script to run when you are connected to a network that you trust.


# Execute nmtrust

# Execute backups if the current connection(s) are trusted.
if [ $? -eq 0 ]; then

On machines running systemd, most of the things that you want to start and stop based on the network are probably described by units. ttoggle is another small shell script which uses nmtrust to start and stop these units. The units that should only be run on trusted networks are placed into another file. I keep them in /usr/local/etc/trusted_units. ttoggle executes nmtrust and starts or stops everything in the trusted unit file based on the result.

For example, I have a timer mailsync.timer that periodically sends and receives my mail. I only want to run this on trusted networks, so I place it in the trusted unit file. If ttoggle is executed when I’m connected to a trusted network, it will start the timer. If it is run when I’m on an untrusted network or offline, it will stop the timer, ensuring my machine makes no connection to my IMAP or SMTP servers.

These scripts are easy to use, but they really should be automated so that nobody has to think about them. Fortunately, NetworkManager provides a dispatcher framework that we can hook into. When installed, the dispatcher will execute ttoggle whenever a connection is activated or deactivated.

The result of all of this is that trusted units are automatically started whenever all active network connections are trusted. Any other time, the trusted units are stopped. I can connect to shady public wifi without worrying about network services that may compromise my privacy running in the background. I can connect to my normal networks without needing to remember to start mail syncing, backups, etc.

All of this is baked in to Spark, but it’s really just two short shell scripts and a NetworkManager dispatcher. It provides a flexible framework to help preserve privacy that is fairly easy to use. If you use NetworkManager, try it out.

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