Ephemeral Firefox as a Site-Specific Browser (3/3)

Site-Specific Ephemeral Firefox featured image showing a firewall between the facebook and firefox icons

This article is a part 3/3 of a series describing how to setup an Ephemeral Firefox session as a Site-Specific Browser. The ultimate goal is to be able to have a self-destructing browsing session that can only access a single company’s services, such as Google or Facebook.

After setting up the Site-Specific Ephemeral Firefox Browser, you can then blacklist services designated to your Site-Specific browser(s) (such as Google or Facebook) from your main browser. This significantly improves your ability to browse the internet without your activity being tracked by these companies — leaving your sensitive data vulnerable to being stolen by hackers.

. . . → Read More: Ephemeral Firefox as a Site-Specific Browser (3/3)

Ephemeral Firefox with Extensions (2/3)

icon of ephemeral firefox with icons of popular extensions below it

I recently posted about how to create a sandboxed firefox profile to compartmentalize (and shred) your firefox browsing history in an Ephemeral Firefox session. But so far I’ve only covered how to create a simple vanilla firefox profile. What if you want your Ephemeral Firefox to include a few basic extensions?

This post will cover how to add extensions to your Ephemeral Firefox profile.

. . . → Read More: Ephemeral Firefox with Extensions (2/3)

Ephemeral Firefox in Ubuntu (1/3)

ephemeral firefox

This post will describe how to create an Ephemeral Firefox session. The ultimate goal of an Ephemeral Firefox session is to unlink your browsing sessions day-to-day and reduce tracking via fingerprinting.

This technique can also be used to compartmentalize your internet activity by using the Ephemeral Firefox session as a Site Specific Browser. This can be especially useful for websites that are infamous for tracking users across the internet and selling the data they collect. For example, you can blacklist all facebook domains in your main browser and only use Ephemeral Firefox sessions that have been whitelisted exclusively for facebook domains–effectively compartmentalizing your facebook activity from the rest of your internet activity.

Another great use-case for an Ephemeral Firefox is for public access computers such as those at libraries, hotels, and printing shops.

. . . → Read More: Ephemeral Firefox in Ubuntu (1/3)

New Thumb Drive Encryption Procedure

In this article, I’ll describe a procedure for preparing a brand-new USB flash drive for use. First we’ll securely erase all the data on the drive, then we’ll encrypt the entire drive, and–finally–we’ll check the drive for bad blocks.

Ah, remember the good-ole days of spinning disks? When your OS could tell your hard *disk* to shred a specific sector? Like it or not, those days are gone in the land of USB flash volumes.

There’s a lot of great reads on the complications of securely erasing data on a USB thumb drive. Unfortunately, a lot of the techniques are not universal to all technologies or manufacturers. Consequently, my approach is more ignorant, straight-forward, and broad (at the risk of causing these cheap usb drives to fail sooner & the process taking longer):

First, I make sure never to write any unencrytped data to the disk Second, when I want to wipe the disk, I fill it entirely with random data

Below are the commands that I use to prepare a new usb drive for my use immediately after purchase. These commands are presented as a rough guide; they’re mostly idempotent, but you probably want to copy & paste them
. . . → Read More: New Thumb Drive Encryption Procedure

How to check the Public Key Algorithm used for a given gpg key (ie: RSA vs DSA)

Today I discovered how to validate the Public Key Algorithm that’s used for a given gpg key. Unfortunately, it’s extremely unintuitive & took quite a bit of digging to figure out how. So I’m leaving this here in hopes it helps someone in their future searches.

. . . → Read More: How to check the Public Key Algorithm used for a given gpg key (ie: RSA vs DSA)

HPKP Best Practices for Let’s Encrypt

This post describes how to generate a few backup public key hashes to add to your HTTP Public Key Pinning (HPKP) config that might save you from bricking your domain if Let’s Encrypt ever gets untrusted like StartCom did.

If you have a healthy distrust of the X.509 PKI trust model, then you’ve probably heard of HPKP (and probably also HSTS & CAA). Website certificate pinning was a trend first started by google, who hard-coded a pin of their certificates in their Chrome browser. Eventually, google helped build a more standardized pinning method under RFC 7469. And today, it’s supported by Chrome, Firefox, and Opera.

Pinning is a great TOFU improvement to https, but–if misconfigured–you could “brick” your domain–making it so that your client’s browsers will refuse to let them access your site for months or years (interestingly, this has also caused some security experts to think of how HPKP could be abused in ransom-ware). Therefore, it’s a good idea to follow a few HPKP Best Practices.

. . . → Read More: HPKP Best Practices for Let’s Encrypt

Tor->VPN in TAILS to bypass tor-blocking

This post will describe how to route outgoing traffic in a python script running on TAILS first through Tor, then through a SOCKS proxy created with an ssh tunnel. This is helpful when you want to use the anonymizing capabilities of tor, but you need to access a website that explicitly blocks tor exit nodes (common with sites running CloudFlare on default settings).

. . . → Read More: Tor->VPN in TAILS to bypass tor-blocking

pycurl through Tor without leaking DNS lookups

This article describes the correct way to use pycurl over Tor, such that both DNS lookup data and HTTP(S) traffic is sent through Tor’s SOCKS5 proxy.

If you google “pycurl tor”, one of the first results is a stackoverflow post that describes how to configure pycurl using the pycurl.PROXYTYPE_SOCKS5 setting. Indeed, even the tutorial To Russia With Love on the Tor Project’s Official Website describes how to pass pycurl through Tor using the pycurl.PROXYTYPE_SOCKS5 setting.

However, using pycurl.PROXYTYPE_SOCKS5 will leak DNS queries associated with your HTTP requests outside of the Tor network! Instead you should use pycurl.PROXYTYPE_SOCKS5_HOSTNAME.

The –socks5-hostname argument was added to libcurl v7.26.0. The pycurl.PROXYTYPE_SOCKS5_HOSTNAME argument wasn’t added to pycurl until pycurl v7.19.5.1, which (at the time of writing) was less than 2 months ago!

This article will describe how to install pycurl v7.19.5.1 onto the latest version of TAILS at the time of writing, which is TAILS v1.2.3.

. . . → Read More: pycurl through Tor without leaking DNS lookups

Browsing without being tracked via Fingerprinting

Your browser aggrigates a *lot* of data about your computer, and it won’t hesitate to provide all of this data to a nosy web site. In fact, if a website requests a large dataset of your computer’s configuration, concatinates it together, and passes it through a hash function, the resulting hash can be farily unique.

This procedure can be done (and is done) on seperate websites to track users and their activity across multiple websites. If the same procedure [get data, concatenate, hash()] produces the same hash value when done on 2 seperate websites, the website can be fairly certain that you’re the same user. This technique for tracking users is known as Browser Fingerprinting.

Just to get an idea of how effective this is, here’s an excerpt from the above-linked article:

[The EFF] found that, over their study of around 1 million visits to their study website, 83.6% of the browsers seen had a unique fingerprint; among those with Flash or Java enabled, 94.2%. This does not include cookies!

You can test the uniqueness of your browser’s “fingerprint” using this handy EFF tool.

There is a really great document descirbing techniques that could be used to prevent
. . . → Read More: Browsing without being tracked via Fingerprinting


With each passing day, it’s becoming more and more obvious that Internet users are transitioning to cloud-based storage. Between (1) My home workstation running Arch Linux, (2) my laptop dual-booting in Ubuntu Linux and Windows 7, (3) my netbook running eeebuntu, and (4), public-access PCs at my University, I need a way to open the latest version of our files from any geographic location on any OS.

A few years ago I built a multi-TB storage solution which hosted my personal, online Subversion repository. But power is expensive, so this box ended up getting turned off. In response, I fell into the bad habit of storing my source code merely as files on the cloud without version control.

Several years ago (assuming your file was small enough) this meant emailing an attachment. Or, more recently, uploading it to Google Docs. Then people started using DropBox. Finally, if you cared about the privacy of your data, you moved to Wuala.

But Wuala tends to corrupt my files as I’m editing them in gvim, so I started storing my files locally again–which rocked the boat and convinced me to finally get around to learning git. Git has always been on my to-try
. . . → Read More: Github