Featured Articles

Nightmare on Lemmy Street (A Fediverse GDPR Horror Story)
WordPress Multisite on the Darknet (Mercator .onion alias)
Hardening Guide for phpList
Continuous Documentation: Hosting Read the Docs on GitHub Pages (2/2)
Detecting (Malicious) Unicode in GitHub PRs
Crowdfunding on Crowd Supply (Review of my experience)
Why I was banned from GrapheneOS by Daniel Micay
Techlore Interview (BusKill, Interdiction, and OpSec)
WordPress Profiling with XHProf (Debugging & Optimizing Speed)
Trusted Boot (Anti-Evil-Maid, Heads, and PureBoot)
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)