Featured Articles

WordPress Multisite on the Darknet (Mercator .onion alias)
Why I was banned from GrapheneOS by Daniel Micay
Continuous Documentation: Hosting Read the Docs on GitHub Pages (2/2)
Nightmare on Lemmy Street (A Fediverse GDPR Horror Story)
Techlore Interview (BusKill, Interdiction, and OpSec)
WordPress Profiling with XHProf (Debugging & Optimizing Speed)
Detecting (Malicious) Unicode in GitHub PRs
Crowdfunding on Crowd Supply (Review of my experience)
Introducing BusKill: A Kill Cord for your Laptop
Hardening Guide for phpList
previous arrow
next arrow

Persistent, Sandboxed, Single-Site Browser (firejail and proxychains)

Persistent, Sandboxed, Single-Site, Browser

Or how to avoid getting locked-out of another Google Account

This guide will describe how to setup a persistent browser (for Evil Corp) that’s isolated in a sandbox (with firejail) and forced to use a SOCKS5 proxy to retain a static IP address (using proxychains)

Have you ever been locked out of your own account, and then got an email for your service provider annoyingly letting you know that they’ve “blocked a login attempt — for your protection?“

There’s countless reports of frustrated users who have permanently lost access to their own gmail accounts because of Google’s faulty “fraud protection” systems that locked the account owner out of their own account, due to false-positives.

Problem

Especially the past 10 years, large corporations have been using machine learning anomaly detection systems on their login pages. Unfortunately, sometimes this is (ab)used to have priority over credential authentication challenges.

Even if you enter your username, password, and 2FA credentials correctly on the very first login attempt, you may get locked out of your own account because you “look different”

Even if you enter your username, password, and 2FA credentials correctly on the very first login attempt, you may get locked
. . . → Read More: Persistent, Sandboxed, Single-Site Browser (firejail and proxychains)

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.

Part 1/3: Ephemeral Firefox in Ubuntu Part 2/3: Ephemeral Firefox with Extensions Part 3/3: Ephemeral Firefox as a Site-Specific Browser

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.

Michael Altfield

Hi, I’m Michael Altfield. I write articles about opsec, privacy, and devops ➡

About Michael


. . . → 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.

Part 1/3: Ephemeral Firefox in Ubuntu Part 2/3: Ephemeral Firefox with Extensions Part 3/3: Ephemeral Firefox as a Site-Specific Browser Michael Altfield

Hi, I’m Michael Altfield. I write articles about opsec, privacy, and devops ➡

About Michael


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

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