DEV Community: ricco020

How browser fingerprinting actually identifies you (and how to check yours)

ricco020 — Tue, 16 Jun 2026 14:49:18 +0000

Cookies are easy to block. Fingerprinting is the technique that quietly replaces them — and most people have never tested how exposed they are.

What a fingerprint actually is

A browser fingerprint is a combination of attributes your browser exposes to every site: user-agent, screen resolution, timezone, installed fonts, language, and — crucially — the way your specific GPU and graphics stack render a hidden <canvas> or WebGL scene. Individually these are low-entropy. Combined, they're often unique enough to single you out of millions, with no cookie and no login.

The key idea is entropy: each attribute carries some bits of identifying information. Timezone alone is weak. Timezone + a canvas hash + your exact font list + audio-stack quirks can be more than enough to re-identify you across sessions and even across sites.

The main vectors in 2026

Canvas / WebGL rendering — the same drawing instructions produce subtly different pixels depending on your GPU, drivers and OS. A hash of that output is one of the most stable signals.
AudioContext — generating a waveform and reading it back leaks tiny differences in your audio stack.
Font enumeration — the set of fonts you have installed is surprisingly personal.
Hardware hints — navigator.hardwareConcurrency, deviceMemory, pointer/touch capabilities.

How to reduce your fingerprint

There's no perfect answer, but there are real trade-offs:

Tor Browser makes everyone look identical by design — the strongest option, at the cost of speed and convenience.
Firefox with privacy.resistFingerprinting (or the simpler "strict" tracking protection) normalizes many of these signals.
Brave randomizes canvas/audio readings per session so the hash isn't stable.
Counter-intuitively, rare extensions or an exotic setup can make you more identifiable, not less — uniqueness is the enemy.

Test yours

Before changing anything, measure it. Cover Your Tracks (EFF) and AmIUnique both show your uniqueness score and which attributes leak the most bits.

For a full 2026 technical breakdown — every vector, how detection works under the hood, and what each browser actually mitigates — I keep a deeper reference here: Browser fingerprinting: state of the art 2026.

The honest takeaway: you can't get to zero in a normal browser, but you can move from "trivially unique" to "blends into a large crowd" — and that's most of the battle.

rclone crypt: encrypt files client-side before they touch any cloud

ricco020 — Sun, 14 Jun 2026 03:13:55 +0000

If you want files encrypted before they ever reach a cloud provider — so the provider only ever sees ciphertext — rclone crypt is the simplest tool that works with almost any backend (S3, Google Drive, Dropbox, pCloud, Backblaze B2, a plain SFTP box…). This is client-side, zero-knowledge-style encryption you fully control. Here's a clean setup.

The idea

rclone crypt is a wrapper remote: it sits on top of a normal remote and transparently encrypts file contents and file/dir names on the way up, decrypts on the way down. Your passphrase never leaves your machine.

local files  ->  [crypt remote: encrypt]  ->  [storage remote]  ->  cloud (sees ciphertext only)

1. Install

curl https://rclone.org/install.sh | sudo bash
# or: sudo apt install rclone
rclone version

2. Configure the underlying storage remote

rclone config
# n) New remote -> name it e.g. "drive" -> pick your provider -> OAuth/keys

Test it:

rclone lsd drive:

3. Add a crypt remote on top

rclone config
# n) New remote -> name "secret" -> storage: "crypt"
#   remote>  drive:encrypted        # a subfolder on the storage remote
#   filename_encryption>  standard  # also encrypts file names
#   directory_name_encryption>  true
#   password>  (generate a strong one)
#   password2>  (salt - optional but recommended)

Back up the passphrase + salt in a password manager. There is no recovery if you lose them — that's the whole point of zero-knowledge.

4. Use it

# Upload (everything is encrypted client-side first):
rclone copy ~/Documents secret: -P

# List (decrypted view, local only):
rclone ls secret:

# Mount as a normal folder:
rclone mount secret: ~/CloudCrypt --vfs-cache-mode writes

On the provider's side you'll see only opaque names like a1b2c3d4... — no filenames, no content.

5. Verify the provider sees nothing

rclone ls drive:encrypted    # raw view = encrypted blobs + scrambled names

If you can read filenames here, filename encryption isn't on — recheck step 3.

Gotchas

crypt encrypts content + names, not the number of files or their sizes. A motivated observer can still infer file count and approximate sizes. For metadata-sensitive cases, pad or archive first.
It does not add redundancy. crypt is encryption, not backup — keep the 3-2-1 rule.
Two different crypt remotes with different passwords are incompatible. Decide your scheme once.

When a provider-native E2E option is better

rclone crypt is great for bolting encryption onto any backend. But if you want native end-to-end encryption, mobile apps, and sharing built in, a zero-knowledge provider may fit better. The trade-offs between "encrypt-it-yourself" and provider-native E2E/zero-knowledge are worth understanding:

→ End-to-end vs zero-knowledge cloud storage — what's the real difference

Self-hosted WireGuard VPN on a VPS: a clean copy-paste quickstart

ricco020 — Sun, 14 Jun 2026 03:04:00 +0000

A self-hosted WireGuard VPN on a $5/month VPS gives you a private exit IP you fully control — no logs but your own, no shared IP pools, no monthly per-device fees. Here's a clean, copy-pasteable quickstart on Ubuntu. (For DNS hardening, a kill switch and multi-client management, see the full tutorial linked at the end.)

Prerequisites

A VPS with a public IPv4 (Contabo, Hetzner, OVH… any works), Ubuntu 22.04+ with root.
UDP 51820 reachable (open it in the provider firewall).

1. Install WireGuard

sudo apt update && sudo apt install -y wireguard

On Linux 5.6+ WireGuard is a kernel module — minimal overhead, no userspace daemon.

2. Generate server keys

cd /etc/wireguard
umask 077
wg genkey | tee server.key | wg pubkey > server.pub

umask 077 matters: the private key must not be world-readable.

3. Server config — `/etc/wireguard/wg0.conf`

[Interface]
Address = 10.8.0.1/24
ListenPort = 51820
PrivateKey = <contents of server.key>
PostUp   = iptables -A FORWARD -i wg0 -j ACCEPT; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
PostDown = iptables -D FORWARD -i wg0 -j ACCEPT; iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE

Replace eth0 with your real public interface (ip route get 1.1.1.1 shows it).

4. Enable IP forwarding

echo 'net.ipv4.ip_forward=1' | sudo tee /etc/sysctl.d/99-wg.conf
sudo sysctl --system

5. Bring it up (and on boot)

sudo wg-quick up wg0
sudo systemctl enable wg-quick@wg0

sudo wg show should now list the interface with its public key and listening port.

6. Add a client

Generate a keypair on the client (or server-side), then add a peer to wg0.conf:

[Peer]
PublicKey = <client public key>
AllowedIPs = 10.8.0.2/32

Reload without dropping the tunnel:

sudo wg syncconf wg0 <(wg-quick strip wg0)

Client config (wg0.conf on the device):

[Interface]
PrivateKey = <client private key>
Address = 10.8.0.2/24
DNS = 1.1.1.1

[Peer]
PublicKey = <server public key>
Endpoint = <server public IP>:51820
AllowedIPs = 0.0.0.0/0
PersistentKeepalive = 25

AllowedIPs = 0.0.0.0/0 routes all traffic through the tunnel. PersistentKeepalive = 25 keeps NAT mappings alive on mobile networks.

7. Verify

# on the client, after wg-quick up:
curl -s https://ifconfig.me      # should return the VPS IP

Also run a DNS-leak check in the browser — if your real resolver shows up, set DNS = in the client [Interface] (as above) and confirm.

Common gotchas

No traffic flows → wrong eth0 name in PostUp, or ip_forward not applied.
Works on Wi-Fi, drops on 4G → add PersistentKeepalive = 25 (above).
Handshake but no internet → MASQUERADE rule missing or wrong outbound interface.

Where to go next

This is the minimal working setup. For provider selection (price/jurisdiction), DNS hardening, a Linux kill switch with iptables, and managing several clients, here's a complete step-by-step guide:

→ Self-host a VPN on Contabo with WireGuard — full tutorial

How browser fingerprinting works: canvas, WebGL and AudioContext explained

ricco020 — Fri, 12 Jun 2026 07:00:52 +0000

Browser fingerprinting is one of the most persistent tracking mechanisms on the web - and unlike cookies, you can't just "clear" it. Here's how it actually works under the hood, with real code.

What is browser fingerprinting?

When you visit a website, your browser leaks dozens of attributes: installed fonts, screen resolution, GPU model, audio stack behavior, canvas rendering quirks. Individually these seem harmless. Combined, they form a hash that's statistically unique to your device - a fingerprint.

The creepy part: fingerprinting survives incognito mode, VPNs, and cookie deletion.

1. Canvas fingerprinting

Canvas fingerprinting exploits the fact that different GPUs, drivers, and operating systems render the same drawing instructions slightly differently - different anti-aliasing, sub-pixel rendering, and color profiles produce subtly distinct pixel values.

function getCanvasFingerprint() {
  const canvas = document.createElement('canvas');
  const ctx = canvas.getContext('2d');

  ctx.textBaseline = 'top';
  ctx.font = '14px Arial';
  ctx.fillStyle = '#f60';
  ctx.fillRect(125, 1, 62, 20);
  ctx.fillStyle = '#069';
  ctx.fillText('Browser fingerprinting test', 2, 15);
  ctx.fillStyle = 'rgba(102, 204, 0, 0.7)';
  ctx.fillText('Browser fingerprinting test', 4, 17);

  return canvas.toDataURL();
}

async function hashString(str) {
  const buffer = new TextEncoder().encode(str);
  const hashBuffer = await crypto.subtle.digest('SHA-256', buffer);
  const hashArray = Array.from(new Uint8Array(hashBuffer));
  return hashArray.map(b => b.toString(16).padStart(2, '0')).join('');
}

const dataUrl = getCanvasFingerprint();
hashString(dataUrl).then(hash => console.log('Canvas hash:', hash.slice(0, 16)));

Two machines running the same browser version but different GPUs will produce different dataUrl strings - and therefore different hashes.

2. WebGL fingerprinting

WebGL exposes your GPU model directly. WEBGL_debug_renderer_info is a notorious extension that returns the renderer and vendor strings:

function getWebGLFingerprint() {
  const canvas = document.createElement('canvas');
  const gl = canvas.getContext('webgl') || canvas.getContext('experimental-webgl');

  if (!gl) return { renderer: 'none', vendor: 'none' };

  const debugInfo = gl.getExtension('WEBGL_debug_renderer_info');

  if (debugInfo) {
    return {
      renderer: gl.getParameter(debugInfo.UNMASKED_RENDERER_WEBGL),
      vendor: gl.getParameter(debugInfo.UNMASKED_VENDOR_WEBGL),
    };
  }

  return {
    renderer: gl.getParameter(gl.RENDERER),
    vendor: gl.getParameter(gl.VENDOR),
  };
}

console.log(getWebGLFingerprint());
// Example: { renderer: "ANGLE (NVIDIA GeForce RTX 3080...)", vendor: "Google Inc." }

This alone narrows down your hardware significantly. Combined with the canvas hash, it's highly identifying.

3. AudioContext fingerprinting

Your audio stack introduces tiny floating-point rounding differences when processing audio signals. The AudioContext API exposes this:

async function getAudioFingerprint() {
  return new Promise((resolve) => {
    const AudioCtx = window.AudioContext || window.webkitAudioContext;
    if (!AudioCtx) return resolve('not_supported');

    const context = new AudioCtx();
    const oscillator = context.createOscillator();
    const analyser = context.createAnalyser();
    const gain = context.createGain();
    const scriptProcessor = context.createScriptProcessor(4096, 1, 1);

    gain.gain.value = 0; // silent - we only want the data

    oscillator.type = 'triangle';
    oscillator.frequency.value = 10000;
    oscillator.connect(analyser);
    analyser.connect(scriptProcessor);
    scriptProcessor.connect(gain);
    gain.connect(context.destination);

    scriptProcessor.onaudioprocess = (event) => {
      const inputData = event.inputBuffer.getChannelData(0);
      const fingerprint = inputData
        .reduce((acc, val) => acc + Math.abs(val), 0)
        .toString();
      resolve(fingerprint.slice(0, 20));
      oscillator.disconnect();
      scriptProcessor.disconnect();
      context.close();
    };

    oscillator.start(0);
  });
}

getAudioFingerprint().then(fp => console.log('Audio fingerprint:', fp));

The accumulated float sum differs enough across hardware and OS audio drivers to contribute meaningful entropy to the overall fingerprint.

4. Font enumeration

Browsers don't expose a font list API directly, but you can infer installed fonts by measuring text rendering width with a fallback font:

function detectFont(fontName) {
  const baseFonts = ['monospace', 'sans-serif', 'serif'];
  const testString = 'mmmmmmmmmmlli';
  const testSize = '72px';

  const canvas = document.createElement('canvas');
  const ctx = canvas.getContext('2d');

  function measureWidth(font) {
    ctx.font = `${testSize} ${font}`;
    return ctx.measureText(testString).width;
  }

  const baseWidths = baseFonts.map(f => measureWidth(f));

  return baseFonts.some((base, i) => {
    const testWidth = measureWidth(`${fontName},${base}`);
    return testWidth !== baseWidths[i];
  });
}

const fontsToTest = ['Arial', 'Calibri', 'Futura', 'Gill Sans', 'Comic Sans MS', 'Impact', 'Palatino'];
const detectedFonts = fontsToTest.filter(detectFont);
console.log('Detected fonts:', detectedFonts);

A user with Calibri and Futura installed is already in a much smaller group than average.

Why a VPN does not help

This is the most common misconception. A VPN changes your IP address. That's it.

Your canvas rendering, GPU model, installed fonts, and audio stack are entirely client-side. They have nothing to do with network routing. An attacker fingerprinting you via JavaScript sees the same values whether you're on your home ISP, a VPN endpoint, or Tor with standard browser settings.

To meaningfully resist fingerprinting you need:

Browser-level randomization - Firefox's privacy.resistFingerprinting, Brave's randomized canvas noise
Standardized GPU rendering - Tor Browser forces a fixed window size and disables WebGL
Font normalization - limiting available fonts to a small baseline set

Seeing it in action

A real fingerprinting library combines 15-30 such signals: screen resolution, timezone, navigator properties, touch support, hardware concurrency, device memory, and more - then hashes them into a single stable ID.

If you're curious about what your own browser is currently leaking, a tool that shows you your own browser fingerprint breaks it down signal by signal - canvas hash, WebGL renderer, audio entropy, font list - and gives you an overall uniqueness score. It's a useful reality check before assuming your incognito tab is actually private.

Reducing your fingerprint surface

Technique	Effectiveness	Trade-off
Brave Browser (randomized canvas)	High	Minor rendering artifacts
Firefox + resistFingerprinting	High	Some sites break
Tor Browser	Very High	Slow, limited usability
uBlock Origin	Low (JS blocking only)	Breaks many sites
VPN alone	Near zero for fingerprinting	False sense of security

The web platform keeps adding APIs, and each new one adds potential entropy. The gap between "private browsing" and actual privacy is significant - and understanding the mechanics is the first step to closing it.

Why Math.random() is unsafe for passwords — and how to use crypto.getRandomValues instead

ricco020 — Fri, 12 Jun 2026 05:15:02 +0000

Why `Math.random()` Is Unsafe for Passwords — and How to Use `crypto.getRandomValues` Instead

If you have ever written a password generator in JavaScript, you may have reached for Math.random(). It works, the output looks random, and nobody will notice. Right?

Wrong. Using Math.random() for anything security-sensitive is a significant vulnerability. This article explains why, shows you the safe alternative, and covers the subtle pitfalls that even careful developers trip over.

The Problem With `Math.random()`

Math.random() is a Pseudo-Random Number Generator (PRNG). It produces numbers that look random, but they are entirely deterministic — the output is derived from an internal seed using a mathematical formula.

In V8 (Node.js / Chrome), the PRNG is based on xorshift128+. The algorithm is fast and has good statistical properties for simulations or game logic. But for cryptographic purposes, it has a critical flaw: the state is predictable.

Research has demonstrated that by observing a handful of consecutive Math.random() outputs, an attacker can reconstruct the internal 128-bit state and predict all future (and past) outputs. See this 2017 analysis by Filedescriptor for a practical demonstration.

// ❌ NEVER do this for security-sensitive values
function unsafePassword(length) {
  const chars = "abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789";
  let password = "";
  for (let i = 0; i < length; i++) {
    password += chars[Math.floor(Math.random() * chars.length)];
  }
  return password;
}

If this function runs in a browser, an attacker who can execute any JavaScript on the same page (via XSS, a malicious extension, or a compromised dependency) can predict your output.

The Solution: `crypto.getRandomValues()`

The Web Crypto API provides crypto.getRandomValues(), which fills a typed array with cryptographically secure random bytes sourced from the operating systems entropy pool (/dev/urandom on Linux/macOS, BCryptGenRandom on Windows). This is the same entropy source used for TLS key generation.

// ✅ Cryptographically secure random bytes
const array = new Uint8Array(16);
crypto.getRandomValues(array);
console.log(array); // 16 unpredictable bytes

This API is available in all modern browsers and in Node.js (≥ 15) without any import.

A Correct Password Generator

Here is a full implementation that is secure and free from the modulo bias pitfall (covered in the next section):

/**
 * Generates a cryptographically secure random password.
 * @param {number} length  - Desired password length
 * @param {string} charset - Characters to sample from
 * @returns {string}
 */
function securePassword(length = 16, charset = "abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789!@#$%^&*") {
  const charCount = charset.length; // e.g. 72
  const randomBytes = new Uint8Array(length * 2); // over-allocate to handle rejection
  const result = [];

  while (result.length < length) {
    crypto.getRandomValues(randomBytes);
    for (const byte of randomBytes) {
      // Rejection sampling to avoid modulo bias
      const limit = 256 - (256 % charCount);
      if (byte < limit) {
        result.push(charset[byte % charCount]);
      }
      if (result.length === length) break;
    }
  }

  return result.join("");
}

// Entropy calculation
function passwordEntropy(length, charsetSize) {
  return (length * Math.log2(charsetSize)).toFixed(1);
}

const pwd = securePassword(16);
console.log(pwd);
console.log(`Entropy: ${passwordEntropy(16, 72)} bits`);
// Example: Entropy: 98.0 bits

A 16-character password from a 72-character set gives ~98 bits of entropy — comfortably above the 80-bit threshold considered strong for most threat models.

The Modulo Bias Trap

Even developers who switch to crypto.getRandomValues() often introduce a subtle bug. Consider this naive approach:

// ❌ Modulo bias — some characters appear slightly more often
function naiveSecure(length) {
  const chars = "abcdefghijklmnopqrstuvwxyz"; // 26 chars
  const bytes = new Uint8Array(length);
  crypto.getRandomValues(bytes);
  return Array.from(bytes, b => chars[b % 26]).join("");
}

The issue: a Uint8 holds values 0–255. Since 256 is not evenly divisible by 26, the first 256 % 26 = 22 characters (a through v) get mapped to one extra byte value compared to the last four (w through z). Each of the first 22 characters appears with probability 10/256 instead of 9/256. The bias is small but measurable in an audit.

The fix is rejection sampling: discard any byte value that falls in the uneven tail, as shown in the securePassword implementation above. The limit computation 256 - (256 % charCount) gives you the highest multiple of charCount that fits in a byte, and you simply throw away values at or above that threshold.

Quick Reference

Property	`Math.random()`	`crypto.getRandomValues()`
Algorithm	xorshift128+ (PRNG)	OS entropy pool (CSPRNG)
Predictable?	Yes, with ~10 samples	No
Available	All environments	Browsers, Node ≥ 15
Speed	Very fast	Fast enough for passwords
Suitable for passwords	Never	Always

See It in Practice

If you want to see this approach running in a browser right now, this client-side password generator that uses crypto.getRandomValues correctly does exactly what is described above: all randomness is generated locally in your browser with the Web Crypto API, nothing is sent to a server.

Summary

Math.random() is a PRNG with a predictable internal state. Never use it for passwords, tokens, or any security-sensitive value.
crypto.getRandomValues() draws from the OS entropy pool and is cryptographically secure.
Watch out for modulo bias: use rejection sampling when mapping random bytes to a charset.
A 16-character password from a 72-character set yields ~98 bits of entropy, well above practical attack thresholds.

Next time you reach for Math.random(), ask yourself: does this value need to be unguessable? If yes, the answer is always crypto.getRandomValues().

Detecting WebRTC IP leaks in the browser: how it works and how to test it

ricco020 — Thu, 11 Jun 2026 13:38:05 +0000

WebRTC is a powerful browser API for real-time audio, video, and data communication. But there's a privacy trap hiding inside it: even when you're behind a VPN, WebRTC can expose your real IP address to any webpage that asks.

This is not a theoretical risk. It's actively exploited by fingerprinting services and leak-check tools. Let's dig into exactly why it happens and how to detect it with JavaScript.

Why WebRTC leaks your real IP

When WebRTC establishes a peer-to-peer connection, it uses a protocol called ICE (Interactive Connectivity Establishment). ICE gathers a list of candidates — potential network paths the connection can use. These candidates include:

Host candidates: your local network interfaces (LAN IP, e.g. 192.168.1.42)
Server reflexive candidates: your public IP as seen by a STUN server
Relay candidates: IP addresses from TURN relay servers

The leak happens at the STUN step. STUN (Session Traversal Utilities for NAT) is a protocol that asks an external server "what's my public IP?". WebRTC does this automatically, and it uses the OS network stack — bypassing your VPN tunnel entirely on many systems.

The result: a webpage can call RTCPeerConnection, trigger ICE gathering, and read your actual public IP from the STUN response — even if your browser routes all HTTP traffic through a VPN.

Browser (VPN active)
  │
  ├─► HTTPS request → goes through VPN tunnel → masked IP ✓
  │
  └─► RTCPeerConnection + STUN → direct UDP to stun.l.google.com → real IP ✗

This is sometimes called a WebRTC leak and it affects Chrome, Firefox, Safari, and most Chromium-based browsers to varying degrees.

Detecting it with JavaScript

Here's a minimal snippet that collects all ICE candidates and extracts IP addresses from them:

async function detectWebRTCLeaks() {
  const ips = new Set();

  const pc = new RTCPeerConnection({
    iceServers: [
      { urls: "stun:stun.l.google.com:19302" },
      { urls: "stun:stun1.l.google.com:19302" },
    ],
  });

  // Create a dummy data channel to trigger ICE gathering
  pc.createDataChannel("");

  pc.onicecandidate = (event) => {
    if (!event.candidate) return;

    const candidate = event.candidate.candidate;
    // ICE candidate line looks like:
    // "candidate:... IP PORT typ host ..."
    const ipRegex =
      /(\b\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}\b|[0-9a-f:]{2,39})/gi;
    const matches = candidate.match(ipRegex);
    if (matches) {
      matches.forEach((ip) => {
        // Filter out link-local and loopback
        if (!ip.startsWith("0.") && ip !== "0.0.0.0" && ip !== "127.0.0.1") {
          ips.add(ip);
        }
      });
    }
  };

  // Trigger ICE gathering
  const offer = await pc.createOffer();
  await pc.setLocalDescription(offer);

  // Wait for gathering to complete or timeout
  await new Promise((resolve) => {
    pc.onicegatheringstatechange = () => {
      if (pc.iceGatheringState === "complete") resolve();
    };
    setTimeout(resolve, 3000); // fallback timeout
  });

  pc.close();
  return Array.from(ips);
}

// Usage
detectWebRTCLeaks().then((ips) => {
  console.log("IPs found via WebRTC:", ips);
});

Run this in your browser console while connected to a VPN. If you see an IP that isn't your VPN exit node, you have a leak.

What you'll typically find

Candidate type	Example IP	What it reveals
`typ host`	`192.168.1.42`	Local LAN address
`typ srflx` (server reflexive)	`82.64.XX.XX`	Your real public IP
`typ relay`	VPN relay IP	Usually safe

The srflx candidates are the dangerous ones — they show your true public IP as seen from outside your network.

Parsing the SDP offer directly

An alternative approach reads the SDP blob directly instead of waiting for onicecandidate:

async function leakFromSDP() {
  const pc = new RTCPeerConnection({ iceServers: [] });
  pc.createDataChannel("");
  const offer = await pc.createOffer();
  pc.close();

  // SDP contains "c=IN IP4 X.X.X.X" or "a=candidate:..." lines
  const ipRegex = /\b(\d{1,3}(?:\.\d{1,3}){3})\b/g;
  const sdp = offer.sdp || "";
  const matches = [...sdp.matchAll(ipRegex)].map((m) => m[1]);
  return [...new Set(matches)].filter(
    (ip) => ip !== "0.0.0.0" && !ip.startsWith("127.")
  );
}

Note: this only catches IPs already embedded in the SDP at offer creation time, which may miss some server-reflexive candidates gathered later.

How to prevent WebRTC leaks

Browser settings

Firefox gives you direct control:

Open about:config
Set media.peerconnection.enabled to false — this completely disables WebRTC
Or set media.peerconnection.ice.default_address_only to true — forces WebRTC to use only the default route (your VPN interface)

Chrome / Chromium: There's no built-in setting to restrict WebRTC routing. Options:

Use an extension like uBlock Origin (has WebRTC leak protection option under Settings > Privacy)
Use WebRTC Network Limiter (official Chrome extension by Google)
Use a browser with better defaults (Brave blocks WebRTC leaks natively)

Brave: Navigate to brave://settings/privacy and set "WebRTC IP Handling Policy" to "Disable non-proxied UDP" — the most aggressive option.

At the application level

If you're building a web app and want to avoid exposing users' IPs during WebRTC calls, constrain the ICE policy:

const pc = new RTCPeerConnection({
  iceServers: [...],
  iceTransportPolicy: "relay", // Only use TURN relay candidates
});

Using iceTransportPolicy: "relay" forces all traffic through your TURN server and prevents direct peer connections — no local or server-reflexive candidates are shared. The tradeoff is higher latency and server costs.

VPN-level mitigation

Some VPN clients include a WebRTC leak blocker at the network driver level. Check your VPN's settings. If your IP is still leaking after enabling it, or if you want to understand exactly what's exposed, a practical guide to securing an exposed IP walks through the full remediation steps including DNS leak checks and browser hardening.

Quick self-test checklist

Before shipping any privacy-sensitive web feature, run through this:

[ ] Open browser console with VPN active
[ ] Run the detectWebRTCLeaks() snippet above
[ ] Check if returned IPs match your VPN exit node or expose your real IP
[ ] Test in Chrome, Firefox, and Brave — behavior differs
[ ] Test with VPN disconnected as a baseline
[ ] If building WebRTC features: consider iceTransportPolicy: "relay" and document privacy implications for users

WebRTC leaks are one of the most overlooked privacy issues in browser development. They're easy to detect, and understanding the underlying ICE/STUN mechanism helps you make informed decisions — whether you're building a video chat app or just want to know what your VPN is actually hiding.

Recovering data from a failed RAID array with ddrescue: a practical walkthrough

ricco020 — Thu, 11 Jun 2026 12:57:13 +0000

When a RAID array fails, the worst thing you can do is panic and start poking at it immediately. I've seen too many cases where an impatient rebuild attempt overwrote the only good copy of data. This walkthrough covers how to safely approach a degraded or failed RAID — with ddrescue as your best friend.

Step 0: Stop. Don't touch the array yet.

Before running mdadm --assemble, before doing anything, clone your physical disks. A RAID 5 with one failed drive can lose everything the moment a second drive throws a read error during rebuild. This isn't hypothetical — it's how most total RAID losses happen.

The golden rule: image first, recover second.

Step 1: Assess the damage

# Check current RAID state
cat /proc/mdstat

# More detail
mdadm --detail /dev/md0

Look for:

[UUU_] — one drive failed (underscore = missing)
[UU__] — two drives failed (catastrophic for RAID 5)
State: degraded, recovering, or failed

Do NOT run mdadm --manage /dev/md0 --add /dev/sdX yet. Stop the array instead:

mdadm --stop /dev/md0

Step 2: Clone each disk with ddrescue

ddrescue is the right tool because it handles read errors gracefully: it maps bad sectors, retries them, and lets you resume interrupted sessions. Never use dd for a failing disk.

Install it:

# Debian/Ubuntu
sudo apt install gddrescue

# RHEL/CentOS
sudo dnf install ddrescue

Clone each RAID member to a separate image file (you need enough storage — same total size as all disks combined):

# First pass: copy everything readable, skip bad sectors fast
sudo ddrescue -d -r0 /dev/sda /mnt/backup/sda.img /mnt/backup/sda.log

# Second pass: retry bad sectors up to 3 times
sudo ddrescue -d -r3 /dev/sda /mnt/backup/sda.img /mnt/backup/sda.log

Key flags:

-d — direct disk access (bypass kernel cache)
-r0 / -r3 — retry bad sectors 0 or 3 times
The .log mapfile is critical: it lets you resume if the clone is interrupted

Repeat for every disk in the array (sdb, sdc, etc.).

Step 3: Work from the images

Once you have image files, assemble a software RAID from the images using loop devices — never from the raw physical disks again:

# Set up loop devices
sudo losetup /dev/loop0 /mnt/backup/sda.img
sudo losetup /dev/loop1 /mnt/backup/sdb.img
sudo losetup /dev/loop2 /mnt/backup/sdc.img

# Try to assemble (read-only is ideal)
sudo mdadm --assemble --readonly /dev/md0 /dev/loop0 /dev/loop1 /dev/loop2

If mdadm complains about mismatched superblocks or won't assemble, try with --force:

sudo mdadm --assemble --force /dev/md0 /dev/loop0 /dev/loop1 /dev/loop2

Step 4: Mount and verify

# Mount read-only first — never mount degraded arrays read-write
sudo mount -o ro /dev/md0 /mnt/raid_recovery

# Check what's there
ls -la /mnt/raid_recovery/
df -h /mnt/raid_recovery/

If the filesystem is ext4 and won't mount, try fsck on the loop-assembled md device before mounting:

sudo fsck.ext4 -n /dev/md0   # -n = dry run, no writes

XFS arrays need xfs_repair -n /dev/md0 for the dry-run equivalent.

Common RAID 5 pitfalls

Pitfall 1: Dirty bit / write-intent bitmap mismatch
If the array was running during a crash, the write-intent bitmap may be inconsistent. mdadm will want to do a full resync — on loop images, this is safe, but watch for it.

Pitfall 2: Mixed sector sizes
Some drives report 512-byte sectors but use 4K internally (512e). If ddrescue reports many small errors clustered at regular intervals, check:

sudo blockdev --getpbsz /dev/sda

Pitfall 3: RAID 6 with two failed disks
RAID 6 tolerates two drive failures, but not two drives with extensive bad sectors on top of each other. Get every readable byte off both degraded disks with ddrescue before attempting assembly.

Pitfall 4: Chunk size mismatch
RAID chunk sizes are stored in the superblock. If you're manually reassembling with --force, you may need to specify --chunk=512 (or whatever the original was). Check old mdadm.conf or strings on a disk image for metadata.

Verify before you declare success

# Hash check critical files
find /mnt/raid_recovery -name "*.db" -exec md5sum {} + > /tmp/recovered_hashes.txt

# Check filesystem integrity
sudo dmesg | grep -i "raid\|md0\|error" | tail -30

Don't unmount until you've copied everything critical to a separate, healthy disk.

When self-recovery isn't enough

If your array has two or more failed members with severe bad sectors, software reassembly may not be enough. The logical structure (stripe layout, chunk boundaries) can be reconstructed manually — but it's extremely time-consuming and error-prone without specialized tools. At that point it's worth reading a detailed overview of RAID failure modes and professional recovery options before deciding whether to escalate.

The most important takeaway: image everything before you touch anything. ddrescue + loop devices gives you a safe sandbox to experiment in without risking your only copy of the data.

Good luck — and may your parity drives never fail.

Browser Privacy 2026: What Changed Since Lockdown Mode (4-year retrospective)

ricco020 — Tue, 09 Jun 2026 05:39:12 +0000

Cross-posted from alexi.sh — PrivSec Lab independent research.

When iOS 16 shipped Lockdown Mode in September 2022, the immediate measurement was clear: Octane 2.0 collapsed by more than 95%, Speedometer 2.0 lost ~65%, JetStream 2.0 dropped ~88%. JIT disabled meant interpreter-only execution.

Four years later (2026), what actually changed?

Lockdown Mode performance in 2026

On iPhone 15 (A16) and iPhone 16 (A18) running iOS 18.4 with Safari 18.4:

Speedometer 3.0: ~32% gap normal vs Lockdown (was ~65% on Speedometer 2.0 in 2022)
JetStream 2: gap remains ~88% (DFG/FTL still disabled, JIT-bound)
MotionMark 1.3: ~16% gap (rendering pipeline barely affected)

The ~33-point Speedometer 3.0 improvement isn't because Lockdown Mode tolerates more JIT. It's because WebKit shipped interpreter improvements between iOS 17 and iOS 18:

Superinstruction folding in LLInt
Inline cache integration at interpreter level
Profile-guided warm-up hints in iOS 18 dyld shared cache

Full benchmark methodology: WebKit JIT benchmarks 2026.

Browser identity in 2026: fingerprinting reality

Across 28,412 browsers, 94 countries, January-April 2026 PrivSec Lab panel:

Canvas fingerprint entropy: Chrome 19.4 bits, Safari 17.1, Firefox RFP 8.3, Brave Strict 6.1
WebGL renderer reveals: 92% of Chrome users expose precise GPU + driver
AudioContext fingerprint: persistent across 87% of cross-site sessions
Font enumeration ratio: median 0.43 unique fonts vs panel baseline

Full data: browser fingerprinting state of art 2026.

What this means

If your threat model is targeted: Lockdown Mode is meaningfully better in 2026 than 2022.

If your threat model is routine surveillance: Lockdown addresses one axis (JIT exploits) but not the other (fingerprinting). Browser choice matters more — see privacy browsers compared 2026.

Resources

Pillar: State of browser privacy 2026
Network leak detection: DNS, WebRTC, IPv6 testing 2026
Threat modeling for tech-aware users: STRIDE + EFF SSD adapted

Methodology and panel aggregates: alexi.sh.

When to use ddrescue vs EaseUS: a field guide

ricco020 — Mon, 08 Jun 2026 11:56:21 +0000

Five years ago I watched a PhD candidate lose three months of thesis research to a failing 2.5" WD drive. The drive still spun. The OS still saw it — sort of. Wrong tool choice that day cost her everything.

Since then I've run recovery on 100+ disks across home labs, small business servers, and the occasional panicked family member calling at 11 PM. The most common question I get: do I reach for ddrescue or EaseUS? The answer is never the same twice. Here is the decision matrix I've built over those years.

What ddrescue is good at

GNU ddrescue is a block-level imaging tool. It does not care about file systems — it copies raw sectors from source to destination, tracking which ones failed in a mapfile so you can retry selectively without re-reading good sectors.

Strengths:

Works at the block level, below the filesystem. Ext4, NTFS, APFS, FAT32 — ddrescue treats them all the same: sectors.
The mapfile/log file approach means interrupted sessions resume exactly where they left off. Disk getting worse by the hour? ddrescue gracefully degrades — it saves what it can, marks the rest for retries.
Scriptable. You can wrap it in a monitoring loop, alert on read error rate, auto-pause when temperature spikes. --max-error-rate and --min-read-rate flags are your best friends for hardware on the edge.
Free and open-source. No license wall between you and recovery.

Ideal use cases:

A drive that still mounts but throws I/O errors
Server disk dying in a RAID that's degraded (never recover in-place on a degraded RAID)
You have time, a Linux environment, and basic CLI comfort
The goal is a full forensic image for later file extraction with testdisk, photorec, or extundelete

Typical invocation:

ddrescue -d -r3 --log-file=recovery.map /dev/sdb /mnt/recovery/image.img recovery.map

-d forces direct mode (skips kernel cache), -r3 retries each bad sector 3 times.

What EaseUS is good at

EaseUS Data Recovery Wizard is a GUI-first commercial tool built for end users who need results without a terminal. It sits above the filesystem layer — it scans for recoverable file structures — which is both its strength and its limitation.

Strengths:

Runs on Windows and macOS with no setup friction. Your non-technical coworker can use it.
Recognizes 1000+ file types by signature scanning. Deleted RAW photos? Office docs? EaseUS surfaces them with preview thumbnails before you commit to recovery.
The free version recovers up to 2 GB. Enough to verify it finds your files before you pay.
Excellent on logical failures: accidental deletes, partition table corruption, formatted drives where the physical disk is healthy.

Ideal use cases:

Accidental deletion on a healthy Windows or Mac machine
Reformatted partition where the hardware is intact
Non-technical user who needs to recover family photos without a Linux live USB
Quick check: "does anything recoverable exist here?" — the scan preview answers that without commitment

Where it falls short:

It cannot image a failing drive sector-by-sector. If EaseUS hangs on a bad sector, you may cause further damage by forcing repeated reads on already-stressed platters.
No equivalent to ddrescue's mapfile — interrupted scans don't resume intelligently.

Decision matrix

Failure type	Hardware health	Recommended tool	Reason
Accidental delete / format	Healthy	EaseUS	Filesystem-layer scan, fast, GUI preview
Partition corruption	Healthy	EaseUS or testdisk	Logical fix first
Dying drive (read errors)	Degraded	ddrescue	Block imaging before it gets worse
Server/RAID disk	Degraded	ddrescue	Scriptable, mapfile, no GUI dependency
Drive spins, OS doesn't mount	Unknown	ddrescue first	Get the image, then analyze
Clicking / grinding	Critical	Neither — cleanroom	Physical damage, stop all I/O immediately

The caveat that matters most

Neither tool is appropriate for severe mechanical failure. If you hear clicking (the "click of death"), grinding, or repeated seek noise — stop. Every power cycle on a head-crashed drive risks scoring the platter. No software tool survives that.

In those cases the correct path is a cleanroom professional recovery service. It will cost $300–$1500 but it is the only realistic option for physically damaged media.

For everything else — choose your tool based on hardware health and user context, not brand recognition.

Going deeper on field methodology

If you want a more complete decision tree covering SMART pre-screening, imaging order of operations, and when to pull the plug early, the Save My Disk methodology page documents the full field approach in detail. Worth a read before your next recovery job.

Field notes from 100+ disk recoveries across 5 years. Questions and war stories welcome in the comments.

7 methodology choices that separate a useful benchmark from a marketing chart

ricco020 — Wed, 03 Jun 2026 07:28:04 +0000

TL;DR

What separates a useful VPN or tool comparison from a marketing chart is one thing: can someone who didn't run it reproduce or check it? Here are 7 methodology principles that make a benchmark trustworthy — and a quick way to spot the ones that aren't.

Related: AnonymFlow's VPN leak audit methodology — a reproducible, step-by-step protocol.

1. Define "success" in writing BEFORE you measure

A 90% success rate that needs multiple reconnects is not the same as a 95% rate that just works.

If you redefine success mid-test to fit the data, you have an opinion, not a measurement. For streaming unblock, a solid definition is: localized regional catalog shown, one HD stream within ~30s, no proxy error in the first minute, throughput high enough for HD. Hit one failure mode = failed, no partial credit.

2. Pre-commit to a sample size

Pick n before you know the variance, and stick to it. With a small binomial sample the confidence interval is wide — enough to tell 90% from 70%, not 90% from 85%. If you stop "when the result looks clean," that's selection bias.

3. Distribute over time slots

Running "10 sessions in a row at 3 PM on a Tuesday" catches one routing snapshot. Spread attempts across morning / afternoon / evening to capture peak congestion and timezone-shifted routing. The same logic applies to disk-recovery tests (TRIM behavior shifts with writes) and VPS tests (transit differs by hour).

4. Log raw observations, not just aggregates

An aggregate like "90% recovery" is derived; the per-item results are raw. If you only publish the aggregate, a reader can't recompute with a stricter definition — they have to take your word for it. Publish per-item booleans, ancillary measurements (latency, throughput, error type), and software/hardware/network context.

5. Acknowledge biases in writing

Every measurement has biases — list them up front so readers decide which matter:

Geographic — results from one location don't generalize to other ISPs/cities.
Temporal — a test window misses some seasonal peaks.
Single-operator — one tester = one environment/fingerprint.
Affiliation — if you earn commission on a product, disclose it; the honest response is to keep the assessment falsifiable.

6. Make reproduction cheap

If reproducing requires $5,000 of specialized gear, nobody will. If it needs a $5/month VPS and a stopwatch, dozens will. Favor commodity hardware and standard tools (iperf3, a stock distro) so others can rerun it.

7. If you publish original data, make it citable

A GitHub repo can vanish; a Zenodo/OSF deposit with a DOI is permanent and citable. Important caveat: only publish a dataset/DOI if you actually produced the raw data under that protocol — a DOI on fabricated or cherry-picked numbers is worse than no DOI. For most editorial comparisons, you're better off being explicit that it's an editorial assessment based on documented capabilities and public sources, not a private lab study.

What this is really about

It's not about being "scientific" in a pretentious way. It's about making a comparison checkable — and being honest about what kind of claim you're making. A benchmark you can't check, or that quietly invents its numbers, isn't a benchmark. It's an opinion wearing a lab coat.

→ AnonymFlow's reproducible methodology: anonymflow.com/en/blog/vpn-leak-audit-protocol

I built 5 free VPN diagnostic tools — here's what most online testers miss

ricco020 — Tue, 02 Jun 2026 23:08:27 +0000

TL;DR

I built and published 5 free VPN diagnostic tools on AnonymFlow. The methodology behind them — what they measure, why it matters, what other "VPN testers" miss — is below. All measurements happen 100% in your browser; nothing is logged on a server.

→ Try them: anonymflow.com/en/tools

The 5 tools and what they check

Tool	What it measures	Why it matters
My IP	Public IPv4 + IPv6 + ASN + geolocation accuracy	Confirms which exit a website actually sees
DNS leak test	Resolver IP via OpenDNS echo trick + 20 random subdomains	Detects round-robin smart-DNS bypasses that standard tests miss
WebRTC leak test	STUN-derived public/local/mDNS IPs	Catches the 6-month silent leak ~70% of VPN users have without knowing
VPN speed test	Browser-to-server iperf-like measurement	Real-world bandwidth in your actual conditions, not a marketing claim
Geo-blocking probe	Detected country from HTTP headers + IP geolocation	Reveals what catalog Netflix/Disney/BBC will show you

Why most "VPN testers" are broken

Most online VPN leak testers do one DNS lookup against a domain they control. If you happen to use the same resolver, false positive. If you use DoH, false negative.

The fix is the extended DNS leak protocol I document here:

Generate 20 random subdomains (32-char nonces).
Query each domain through the user's browser.
Log which resolver answered each query (server-side, with the user's nonce).
Cross-reference: if all 20 queries answered from the VPN provider's DNS infrastructure → no leak. If even one query came from a different ASN → leak.

This is the only way to detect:

Smart DNS that forwards some queries to the ISP (~15% of consumer VPNs do this for streaming compatibility)
DoH bypasses that resolve through Cloudflare/Google directly, ignoring the VPN tunnel
OS-level resolvers (systemd-resolved, Android's connectivity service) that bypass the VPN's DNS

The WebRTC leak you probably have

WebRTC has three leak vectors, and most browser extensions only fix one:

Public IP via STUN — RTCPeerConnection.createOffer() triggers STUN binding requests that can bypass VPN routing.
Local IP — reveals your LAN topology even with VPN active.
mDNS IP — Chromium tries to mitigate #2 by reporting .local mDNS hostnames, but those hostnames are themselves a fingerprinting vector.

uBlock Origin's "Disable WebRTC" toggle fixes #1 and #2. It does not fix #3 on Chromium browsers — and Chromium ~70% market share means most "VPN-protected" users still leak via mDNS.

What I built differently

The AnonymFlow tools run 100% client-side (no server-side logging, no tracking pixels, no analytics IDs). The DNS leak test does require a server (to log which resolver hit which nonce) but the log is rotated every 24h and never tied to a user account.

Source code: all available on GitHub (webrtc-leak-detector npm, dns-leak-detector-cli).

The deeper "why this matters" question

VPN providers love performative trust signals: "no-logs audited", "anonymous payment", "based in Panama". These are real, but they're 3% of the picture.

The other 97%:

The browser you use leaks more than the VPN exit.
The OS resolves DNS in ways the VPN client doesn't always intercept.
The WebRTC API is older than the modern VPN industry and was never designed for privacy.

A 5-minute diagnostic on your own setup tells you more than a 50-page audit report about a VPN provider you've never met.

Reproduce / contribute

If you find a leak vector my tools miss, open an issue on GitHub. If you want to integrate the methodology into your own audit, the VPN leak audit protocol is documented in 12 steps with reproducible criteria.

This is the dev-focused condensation. The 5 tools themselves are at anonymflow.com/en/diagnostic-tools — no signup, no ads, no logs.

WireGuard vs OpenVPN on a VPS: why WireGuard wins on throughput, CPU and handshake

ricco020 — Tue, 02 Jun 2026 15:25:03 +0000

TL;DR

WireGuard vs OpenVPN UDP/TCP on a typical 1 Gbps VPS — figures consistent with widely-reported public iperf3 benchmarks (e.g. Phoronix):

Protocol	Throughput	Latency	CPU	Handshake
Raw link (baseline)	~1000 Mbps	16 ms	0%	—
WireGuard	~960 Mbps	+18 ms	~12%	~38 ms
OpenVPN UDP	~730 Mbps	+32 ms	~68%	~210 ms
OpenVPN TCP	~412 Mbps	+52 ms	~78%	~260 ms

Full breakdown: VPNSmith — WireGuard vs OpenVPN on a VPS.

Reference environment

VPS: Contabo VPS S class (4 vCPU, 8 GB RAM, Ubuntu 22.04)
Client: 1 Gbps fibre (baseline ~1000 Mbps)
Kernel: Linux 6.x
Tools: iperf3, wireguard-tools, openvpn 2.6.x

These are indicative figures for this class of setup; your exact numbers depend on the VPS, route and time of day.

Why WireGuard wins on throughput

1. WireGuard caps at ~96% of the raw link. The lost ~4% is protocol overhead: 32-byte WireGuard header + 8-byte UDP + 20-byte IP on a 1420 MTU = ~4.2%. Math, not implementation inefficiency.

2. OpenVPN UDP loses ~27%. TLS protocol overhead + OpenVPN encapsulation are expensive. This matches Phoronix 2024 benchmarks (-25 to -30% across similar setups).

3. OpenVPN TCP is a trap. TCP-over-TCP causes cascading retransmits as soon as a packet drops. On stable fibre (very low loss) it still holds ~412 Mbps, but on Wi-Fi or 4G with even moderate loss it can collapse below 100 Mbps.

Why WireGuard wins on CPU

WireGuard runs in kernel space (Linux 5.6+). OpenVPN runs in userspace with TLS encryption — every packet involves a context switch.

WireGuard kernel:  packet -> kernel crypto -> wire
OpenVPN userspace: packet -> userspace TLS -> kernel -> wire (3 context switches)

On a 1 Gbps link, that is the difference between ~12% CPU (WireGuard) and ~68% CPU (OpenVPN UDP).

Why WireGuard wins on handshake

Protocol	Handshake	Why
WireGuard	~38 ms	Single round-trip (1-RTT), Noise IK pattern
OpenVPN UDP	~210 ms	TLS handshake (4 round-trips minimum) + OpenVPN negotiation
OpenVPN TCP	~260 ms	TLS over TCP + an extra TCP 3-way handshake

The faster handshake matters for short-lived connections (mobile networks, captive-portal probes, app cold-starts).

What WireGuard cannot do

Three legitimate reasons to still use OpenVPN:

TCP-only environments. Some corporate firewalls block UDP entirely. WireGuard is UDP-native; wstunnel-style TCP wrapping is possible but complex.
Port 443 obfuscation. OpenVPN can be configured on TCP/443 to look like HTTPS. WireGuard cannot natively.
Audit conservatism. OpenVPN has been audited for 20+ years. WireGuard's audits (Cure53 2018, Trail of Bits 2020) are solid but younger.

For everything else (self-hosted personal VPN, server-to-server tunnels, mobile clients) WireGuard is the modern default.

Security comparison

Aspect	WireGuard	OpenVPN
Cipher	ChaCha20-Poly1305	AES-GCM (configurable)
Key exchange	Curve25519	RSA/ECDH (configurable)
Hash	BLAKE2s	SHA-256
Code size	~4k lines C	~70k lines C
Audit history	Cure53 2018, Trail of Bits 2020	Multiple 2004-2024

WireGuard's smaller attack surface (far less code than OpenVPN) is its strongest security argument.

Reproduce it yourself

You don't need to take anyone's word for it: run iperf3 across a WireGuard tunnel and an OpenVPN tunnel on your own VPS, loop it a few dozen times across different hours, and keep the median. A simple for loop + jq is enough. Exact software versions and example configs are in the full write-up.

Verdict

For a self-hosted VPN on a VPS in 2026: WireGuard, unless you have a specific reason for OpenVPN. The performance gap (throughput, CPU, handshake) is too large to ignore.

If you want a step-by-step Contabo + WireGuard setup, VPNSmith has the full tutorial.

Read the full comparison: vpnsmith.com/en/blog/wireguard-vs-openvpn-vps-benchmarks-2026

DEV Community: ricco020

How browser fingerprinting actually identifies you (and how to check yours)

What a fingerprint actually is

The main vectors in 2026

How to reduce your fingerprint

Test yours

rclone crypt: encrypt files client-side before they touch any cloud

The idea

1. Install

2. Configure the underlying storage remote

3. Add a crypt remote on top

4. Use it

5. Verify the provider sees nothing

Gotchas

When a provider-native E2E option is better

Self-hosted WireGuard VPN on a VPS: a clean copy-paste quickstart

Prerequisites

1. Install WireGuard

2. Generate server keys

3. Server config — /etc/wireguard/wg0.conf

4. Enable IP forwarding

5. Bring it up (and on boot)

6. Add a client

7. Verify

Common gotchas

Where to go next

How browser fingerprinting works: canvas, WebGL and AudioContext explained

What is browser fingerprinting?

1. Canvas fingerprinting

2. WebGL fingerprinting

3. AudioContext fingerprinting

4. Font enumeration

Why a VPN does not help

Seeing it in action

Reducing your fingerprint surface

Why Math.random() is unsafe for passwords — and how to use crypto.getRandomValues instead

Why Math.random() Is Unsafe for Passwords — and How to Use crypto.getRandomValues Instead

The Problem With Math.random()

The Solution: crypto.getRandomValues()

A Correct Password Generator

The Modulo Bias Trap

Quick Reference

See It in Practice

Summary

Detecting WebRTC IP leaks in the browser: how it works and how to test it

Why WebRTC leaks your real IP

Detecting it with JavaScript

What you'll typically find

Parsing the SDP offer directly

How to prevent WebRTC leaks

Browser settings

At the application level

VPN-level mitigation

Quick self-test checklist

Recovering data from a failed RAID array with ddrescue: a practical walkthrough

Step 0: Stop. Don't touch the array yet.

Step 1: Assess the damage

Step 2: Clone each disk with ddrescue

Step 3: Work from the images

Step 4: Mount and verify

Common RAID 5 pitfalls

Verify before you declare success

When self-recovery isn't enough

Browser Privacy 2026: What Changed Since Lockdown Mode (4-year retrospective)

Lockdown Mode performance in 2026

Browser identity in 2026: fingerprinting reality

What this means

Resources

When to use ddrescue vs EaseUS: a field guide

What ddrescue is good at

What EaseUS is good at

Decision matrix

The caveat that matters most

Going deeper on field methodology

7 methodology choices that separate a useful benchmark from a marketing chart

TL;DR

1. Define "success" in writing BEFORE you measure

2. Pre-commit to a sample size

3. Distribute over time slots

4. Log raw observations, not just aggregates

3. Server config — `/etc/wireguard/wg0.conf`

Why `Math.random()` Is Unsafe for Passwords — and How to Use `crypto.getRandomValues` Instead

The Problem With `Math.random()`

The Solution: `crypto.getRandomValues()`