DEV Community: Spicy

Your Baby Monitor's Biggest Security Flaw Isn't Hackers. It's the Company That Built It.

Spicy — Thu, 25 Jun 2026 16:50:56 +0000

In May 2026, a French ethical hacker named Sammy Azdoufal bought a baby monitor off Amazon and spent a few hours looking at its network traffic. What he found: 1.1 million cameras across 300+ brand names, all running on the same shared platform, accessible to anyone with a free account. No password cracking. No exploit chain. He clicked a URL and got the image.

The vulnerability wasn't a clever attack. It was negligence — hardcoded credentials, an MQTT broker with no per-device access controls, and motion-alert images sitting on an Alibaba OSS bucket with no authentication required.

This is the actual baby monitor security problem. Not a stranger breaking in through your Wi-Fi. The architecture itself.

The White-Label Problem

Most budget smart cameras on Amazon are the same product under different names.

Meari Technology (Hangzhou, China) supplies hardware, software, and cloud infrastructure to 300+ brands. When you buy a monitor you've never heard of — or even some you have — there's a real chance it shares a backend platform with hundreds of other products. The box doesn't disclose which cloud it connects to. The app is often interchangeable across brands.

A flaw at the platform level means millions of devices are exposed simultaneously, regardless of brand name.

Rapid7 tested nine popular baby monitors and gave eight of them an "F" for security. Higher prices didn't correlate with better security — more features meant more attack surface.

What "Encrypted" Actually Means Here

Many monitors market end-to-end encryption. Most don't implement it correctly.

Real E2E encryption: only your device and your app can decrypt the stream — not the manufacturer's servers.

What most Wi-Fi monitors actually do: encrypt the leg from your camera to their servers, and the leg from their servers to your app. The manufacturer sees plaintext at the server level.

The Meari MQTT broker (CVE-2026-33356) let any authenticated platform account subscribe to camera activity across all devices on a regional broker. Azdoufal observed 2,000+ device messages within minutes from a single broker endpoint.

What Actually Reduces Risk

Network segmentation — most underused, highest impact. Put your baby monitor on a guest Wi-Fi VLAN, isolated from your main devices. A compromised monitor can't pivot to your laptop or NAS. Takes 5 minutes on most home routers.

Firmware updates over passwords — a strong password won't protect you if the backend has an unpatched CVE. Enable auto-updates or check monthly. This matters more than password complexity on a vulnerable platform.

Brand selection criteria that actually signal security:

Published vulnerability disclosure program or bug bounty
Documented patch history (not just "we take security seriously")
Privacy policy that specifies data collected during idle operation — not just when you're actively viewing

What doesn't move the needle as much:

Strong passwords alone on a platform-level vulnerability
"No cloud" marketing that still phones home for firmware and analytics
Price as a proxy for security

The Regulatory Gap

The FCC's US Cyber Trust Mark — a voluntary IoT security labeling program — is still in development. "Good cybersecurity is invisible to consumers. They can't tell what products are risky," Stacey Higginbotham of Consumer Reports said following the Meari disclosure.

Until mandatory baseline security requirements exist for IoT devices sold in the US, the research burden falls on buyers. Consumer Reports now runs security and privacy evaluations on baby monitors specifically — worth checking before purchase.

Practical Checklist

[ ] Monitor is on a dedicated guest/IoT VLAN
[ ] Firmware auto-updates enabled (or manual check set monthly)
[ ] Default credentials changed immediately on setup
[ ] Brand has published vulnerability disclosure program
[ ] Privacy policy reviewed for third-party data sharing
[ ] App permissions audited (disable anything not needed)

The Meari disclosure made the problem concrete at a scale that's hard to ignore. 1.1 million cameras. Five critical CVEs. Footage of children's bedrooms accessible to anyone with a free account and a few minutes.

That's not a hacking story. It's a product design story.

Full breakdown: https://lucas8.com/baby-monitor-privacy-risks

Two-Factor Auth Isn't the Shield You Think It Is.

Spicy — Mon, 22 Jun 2026 13:58:28 +0000

You enabled two-factor authentication. Good call. But here's what most security guides skip: the biggest account takeovers of the past three years didn't require attackers to crack your 2FA code at all. They found ways to make you hand it over — or made the authentication step irrelevant entirely.

MFA fatigue attacks are now one of the most documented techniques in real breaches, and they work precisely because 2FA gave everyone a false sense of being done.

Why 2FA Still Gets Beaten in 2026

Traditional 2FA was designed to stop credential stuffing — someone stealing your password and trying to log in. For that specific threat, it works brilliantly. Microsoft's data shows MFA blocks over 99% of automated credential attacks.

The problem is the threat didn't stay still. Attackers noticed 2FA made the password less valuable, so they shifted focus: steal the session, exhaust the user, or reroute the auth flow entirely. These aren't exotic techniques. They show up in the Verizon DBIR every year, and the companies hit aren't careless ones.

The Three Techniques Hackers Use to Walk Past MFA

1. MFA Fatigue (Push Bombing)

An attacker who has your username and password triggers your push notification repeatedly — sometimes dozens of times overnight. Most people eventually tap "Approve" to make it stop. That single tap hands over a valid session token.

This exact method took down Uber in 2022. The attacker bought leaked credentials, bombed the contractor's phone with push requests, then sent a WhatsApp message posing as Uber IT saying "approve once and it'll stop." The contractor did. Game over.

Mitigation: Enable number matching on push apps. You type a two-digit code shown on your screen into the push prompt — blind approvals stop working immediately. Microsoft Authenticator and Duo both support this and Microsoft enabled it by default across Entra ID in 2023.

2. Adversary-in-the-Middle (AiTM) Attacks

An attacker sets up a proxy that looks identical to a real login page. When you log in through it:

The proxy relays your credentials to the real site
The real site sends back a 2FA challenge — the proxy relays that too
You enter your code — the proxy captures your authenticated session cookie
The attacker replays that cookie from a clean browser, no further auth required

You → [Fake Proxy] → Real Site
             ↓
      Session Cookie stolen
             ↓
Attacker → [Replays Cookie] → Logged In

The session cookie is the key. Your 2FA was used — legitimately — to create a session the attacker now owns. The Verizon 2025 DBIR flags stolen session tokens as a growing proportion of breach vectors for exactly this reason.

Mitigation: Only passkeys and hardware security keys are immune to this. They use cryptographic proofs tied to the exact origin domain — a proxy gets a different challenge and the login fails silently.

3. SIM Swapping

An attacker calls your carrier posing as you — armed with info from data brokers or social media — and convinces a rep to transfer your number to a SIM they control. From that point, every SMS code sent to your phone goes to them instead.

No malware. Nothing on your device. The FTC has received thousands of SIM swap reports annually since 2021.

Mitigation: Move off SMS 2FA entirely for anything financial or high-value. Authenticator apps (Google Authenticator, Aegis, Authy) generate codes locally on your device — a SIM swap can't intercept them.

The 2FA Method Comparison

Method	Stops Credential Stuffing	Stops Push Bombing	Stops AiTM	Stops SIM Swap
SMS OTP	✅	✅	❌	❌
Authenticator App (TOTP)	✅	✅	❌	✅
Push (standard)	✅	❌	❌	✅
Push + Number Matching	✅	✅	❌	✅
Hardware Key / Passkey	✅	✅	✅	✅

What "Phishing-Resistant" Actually Means

Phishing-resistant MFA uses public-key cryptography where your device proves it's physically present at the real domain. There's no code to intercept, no push to trick you into approving, no SMS to redirect.

Both hardware security keys (YubiKey etc.) and passkeys qualify. FIDO Alliance reports 5 billion active passkeys worldwide as of 2026, and 68% of organizations surveyed are actively deploying them for employee sign-in. Google, Apple, and Microsoft have all made passkeys the default for new accounts.

The Practical Upgrade Path

You don't need to switch everything at once:

This week: Remove SMS 2FA from any financial account. Switch to an authenticator app — takes ~30 seconds per account in settings.

This month: Enable number matching on any push-based MFA app. Check your organization's Entra ID or Okta settings to confirm it's on.

When ready: Add a hardware key ($25–55 for a basic YubiKey) for email, password manager, and any admin access. Set up passkeys on Google, Apple, and GitHub — each takes under three minutes.

The goal isn't to scare you off 2FA — it's to make sure what you're running matches the current threat, not the threat from 2019. Getting off SMS and onto an authenticator app this week already moves you out of the most exploited tier.

Full breakdown with real breach examples: https://lucas8.com/mfa-fatigue-attack-two-factor-bypass

Browser Fingerprinting in Practice — The Signals, the Math, and What Actually Defeats It

Spicy — Thu, 18 Jun 2026 16:38:31 +0000

Most privacy advice still centers on cookies — clear them, block them, use incognito. Meanwhile, fingerprinting has become the dominant tracking method precisely because it doesn't touch cookies at all. Here's what's actually happening at the API level, and what countermeasures hold up.

The Core Signals (And the Code Behind Them)

Canvas fingerprinting exploits subtle rendering differences between GPU/driver combinations:

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

  // Draw text with specific font, size, and emoji — 
  // rendering varies by OS font rasterizer and GPU
  ctx.textBaseline = 'top';
  ctx.font = '14px Arial';
  ctx.fillStyle = '#f60';
  ctx.fillRect(125, 1, 62, 20);
  ctx.fillStyle = '#069';
  ctx.fillText('Cwm fjordbank glyphs vext quiz 🎮', 2, 15);
  ctx.fillStyle = 'rgba(102, 204, 0, 0.7)';
  ctx.fillText('Cwm fjordbank glyphs vext quiz 🎮', 4, 17);

  // Hash the resulting pixel data
  return canvas.toDataURL();
}

// Hash the output for compact comparison
async function hashFingerprint(dataUrl) {
  const encoder = new TextEncoder();
  const data = encoder.encode(dataUrl);
  const hashBuffer = await crypto.subtle.digest('SHA-256', data);
  return Array.from(new Uint8Array(hashBuffer))
    .map(b => b.toString(16).padStart(2, '0')).join('');
}

The same code produces different pixel-level output across GPU vendors (NVIDIA vs AMD vs Apple Silicon), driver versions, and even font hinting settings — none of which the user can see, but all of which produce a consistent hash per device.

WebGL fingerprinting goes deeper into hardware identification:

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

  const debugInfo = gl.getExtension('WEBGL_debug_renderer_info');
  return {
    vendor: gl.getParameter(debugInfo.UNMASKED_VENDOR_WEBGL),
    renderer: gl.getParameter(debugInfo.UNMASKED_RENDERER_WEBGL),
    // e.g. "ANGLE (NVIDIA, NVIDIA GeForce RTX 4070 Direct3D11..."
    extensions: gl.getSupportedExtensions(),
    maxTextureSize: gl.getParameter(gl.MAX_TEXTURE_SIZE),
  };
}

This often reveals your exact GPU model, which on its own significantly narrows the population of matching devices.

AudioContext fingerprinting uses hardware-dependent audio processing variance:

async function getAudioFingerprint() {
  const audioCtx = new (window.AudioContext || window.webkitAudioContext)();
  const oscillator = audioCtx.createOscillator();
  const analyser = audioCtx.createAnalyser();
  const gainNode = audioCtx.createGain();

  gainNode.gain.value = 0; // silent — user hears nothing
  oscillator.type = 'triangle';
  oscillator.connect(analyser);
  analyser.connect(gainNode);
  gainNode.connect(audioCtx.destination);
  oscillator.start(0);

  const buffer = new Float32Array(analyser.frequencyBinCount);
  analyser.getFloatFrequencyData(buffer);
  oscillator.stop();

  return buffer.slice(0, 30).join(','); // sample of frequency data
}

Font enumeration via measurement comparison (no direct font list API exists, so it's inferred):

function detectFonts(testFonts) {
  const baseFonts = ['monospace', 'sans-serif', 'serif'];
  const testString = 'mmmmmmmmmmlli';
  const testSize = '72px';
  const span = document.createElement('span');
  span.style.fontSize = testSize;
  span.innerHTML = testString;
  document.body.appendChild(span);

  const baseWidths = {};
  baseFonts.forEach(font => {
    span.style.fontFamily = font;
    baseWidths[font] = span.offsetWidth;
  });

  const detected = testFonts.filter(font => {
    return baseFonts.some(base => {
      span.style.fontFamily = `'${font}', ${base}`;
      return span.offsetWidth !== baseWidths[base];
    });
  });

  document.body.removeChild(span);
  return detected;
}

Composite Scoring — How These Combine

A single signal rarely identifies anyone uniquely. The entropy comes from combining them:

import math

def calculate_entropy(signal_distribution: dict) -> float:
    """
    Shannon entropy in bits — higher = more identifying
    e.g. if 1 in 1000 users share your exact value, 
    that signal contributes ~10 bits of entropy
    """
    total = sum(signal_distribution.values())
    entropy = 0
    for count in signal_distribution.values():
        p = count / total
        entropy -= p * math.log2(p)
    return entropy

# Example combined fingerprint entropy
signals = {
    'screen_resolution': 4.2,      # bits
    'canvas_hash': 8.1,
    'webgl_renderer': 6.7,
    'font_list': 5.9,
    'timezone': 2.1,
    'audio_fingerprint': 5.3,
}

total_entropy = sum(signals.values())  # ~32.3 bits
# 2^32.3 ≈ 5.3 billion possible combinations
# Global population ~8 billion — this fingerprint 
# alone approaches unique identification

This is why the EFF Panopticlick research consistently found most tested browsers had fingerprints unique among hundreds of thousands of samples — the combinatorial entropy adds up fast even when no individual signal is rare.

What Actually Reduces Entropy (Tested)

Firefox privacy.resistFingerprinting standardizes the highest-entropy signals:
Testing before/after on the same machine with amiunique.org:

Signal	Default Firefox	resistFingerprinting
Canvas	Unique hash	Blocked/randomized
Timezone	Local (e.g. PST)	UTC
Screen resolution	Exact (e.g. 1512x982)	Rounded (1500x950)
Fonts detected	40+ system fonts	~12 bundled fonts
WebGL renderer	Full GPU string	Generic string

The tradeoff: sites relying on accurate viewport dimensions for layout can render incorrectly, and some canvas-dependent web apps (image editors, games) break entirely.

Brave's fingerprinting protection takes a different approach — randomizing per-session rather than blocking:
Tor Browser standardizes nearly everything to a single shared profile across all users, which is the only approach that achieves near-zero fingerprint uniqueness — at the cost of significant performance and compatibility overhead.

Detection-Side: If You're Building Anti-Fraud Systems

For legitimate use cases (fraud detection, not tracking users for ads), fingerprinting libraries like FingerprintJS provide production-ready implementations:

import FingerprintJS from '@fingerprintjs/fingerprintjs';

const fpPromise = FingerprintJS.load();

(async () => {
  const fp = await fpPromise;
  const result = await fp.get();
  console.log(result.visitorId); // stable identifier
  console.log(result.confidence.score); // 0-1 reliability
})();

Worth noting: privacy-focused browsers and extensions specifically target known fingerprinting libraries, so production fraud detection systems increasingly see degraded signal quality from privacy-conscious users — which itself becomes a (weaker) signal.

Practical Takeaway

Cookie-based privacy controls (clearing cookies, incognito mode, cookie blockers) have zero effect on any of the above. If you're building privacy-respecting infrastructure or just hardening your own setup, the signals that matter are canvas, WebGL, audio context, and font enumeration — and the only consistently effective countermeasures are resistFingerprinting-style signal normalization or full standardization (Tor).

Consumer-level explanation without the code: lucas8.com/incognito-mode-browser-fingerprinting

Data Brokers: What They Collect, How the Industry Works, and How to Opt Out at Scale

Spicy — Sun, 14 Jun 2026 15:16:43 +0000

Most developers know abstractly that data brokers exist. Fewer have actually looked up their own profile and seen what's there — their home address, every previous address, relatives' names and addresses, income estimate, vehicle history, court records, and consumer interest categories.

Here's how the data pipeline actually works, what a profile contains at the data level, and how to approach opt-outs at scale rather than one form at a time.

How Data Broker Pipelines Work

Data brokers aggregate from three primary source categories:

Public records — property records, voter registration, court filings, professional licenses, business registrations, marriage/divorce records, death records. These are legally public in the US and most other countries. Brokers ingest them continuously via bulk data agreements with county, state, and federal agencies.

Commercial data — purchase history from retailers (via loyalty programs and direct sales), subscription records, warranty registrations, financial transaction metadata (purchased from banks and credit card processors), insurance records, telecommunications data.

Third-party data — scraped from social media and public web, purchased from other data brokers (the industry extensively resells to itself), purchased from app developers who include data-sharing SDKs.

The aggregation logic:

# Simplified version of identity resolution logic
# (what brokers call "entity resolution" or "data matching")

def resolve_identity(records: list[dict]) -> PersonProfile:
    """
    Match records across sources using probabilistic 
    identity resolution — name + address + DOB + phone
    combinations weighted by confidence score
    """
    clusters = []

    for record in records:
        matched = False
        for cluster in clusters:
            if identity_match_score(record, cluster) > THRESHOLD:
                cluster.merge(record)
                matched = True
                break
        if not matched:
            clusters.append(PersonCluster(record))

    return [cluster.to_profile() for cluster in clusters]

def identity_match_score(record, cluster) -> float:
    score = 0.0
    if fuzzy_name_match(record.name, cluster.names): score += 0.4
    if record.address in cluster.addresses: score += 0.3
    if record.dob == cluster.dob: score += 0.2
    if record.phone in cluster.phones: score += 0.1
    return score

This is why a data broker profile contains people you've lived with — shared address history creates a probabilistic link that their systems treat as a relationship signal.

What's Actually in a Profile (Data Schema)

A typical commercial data broker profile at the API level:

{
  "person": {
    "names": ["Jane Smith", "Jane A. Smith", "Jane Adams"],
    "dob_range": {"min": "1985-01-01", "max": "1985-12-31"},
    "phones": ["+15551234567", "+15559876543"],
    "emails": ["jane@gmail.com", "jane.smith@oldwork.com"]
  },
  "locations": [
    {
      "address": "123 Main St, Austin TX 78701",
      "type": "current",
      "confidence": 0.94,
      "date_range": {"from": "2021-03", "to": "present"}
    },
    {
      "address": "456 Oak Ave, Denver CO 80203", 
      "type": "previous",
      "confidence": 0.87,
      "date_range": {"from": "2018-06", "to": "2021-02"}
    }
  ],
  "associates": [
    {
      "name": "Robert Smith",
      "relationship": "relative",
      "confidence": 0.76,
      "shared_addresses": ["123 Main St, Austin TX 78701"]
    }
  ],
  "financials": {
    "income_estimate": {"min": 75000, "max": 100000},
    "net_worth_estimate": {"min": 50000, "max": 150000},
    "homeowner": true,
    "property_value": 385000
  },
  "records": {
    "criminal": [],
    "civil": [],
    "bankruptcies": [],
    "liens": []
  },
  "consumer_segments": [
    "health_conscious_shopper",
    "frequent_traveler", 
    "suburban_homeowner",
    "political_donor_democrat"
  ]
}

The consumer_segments field is the advertising product — these interest/demographic categories are what marketers buy. The address and associate data is what stalkers, scammers, and PI firms buy.

The Opt-Out Landscape

There are approximately 4,000 data brokers. Manually opting out of each one is not realistic. The practical approach is tiered:

Tier 1 — High-traffic consumer-facing sites (manual opt-out, highest priority)

Site	Opt-Out URL	Method	TTL
Spokeo	spokeo.com/optout	Email form	~3-6 months
WhitePages	whitepages.com/suppression_requests	Web form	~3-6 months
BeenVerified	beenverified.com/opt-out	Web form	~3-6 months
MyLife	mylife.com	Phone call required	~3-6 months
Radaris	radaris.com/page/privacy	Email form	~3-6 months
Intelius	intelius.com/optout	Web form	~3-6 months

TTL = time before listing typically reappears from re-aggregation.

Tier 2 — Automated opt-out via paid services

Services like DeleteMe, Incogni, and Privacy Bee submit opt-outs across 100–750 brokers and resubmit on a schedule. Worth the cost if you're doing this for yourself or building it into a product for users.

Tier 3 — Enterprise data brokers (requires legal process)

Acxiom, LexisNexis, CoreLogic, Equifax (non-credit), TransUnion Marketing — these serve enterprise customers and have different opt-out mechanisms. Acxiom has an opt-out at aboutthedata.com. LexisNexis requires a written request with ID verification. California CCPA requests get the fastest response for these sources.

Automating Opt-Out Submissions

For the manual tier, the process is repetitive and automatable for the sites that use web forms rather than email or phone:

// Playwright automation for form-based opt-outs
// (Shown for educational purposes — 
//  check each site's ToS before automating)

const { chromium } = require('playwright');

async function submitOptOut(site, profileUrl, email) {
  const browser = await chromium.launch({ headless: false });
  const page = await browser.newPage();

  switch(site) {
    case 'spokeo':
      await page.goto('https://www.spokeo.com/optout');
      await page.fill('#email', email);
      await page.fill('#profile_url', profileUrl);
      await page.click('[type="submit"]');
      break;

    case 'radaris':
      await page.goto('https://radaris.com/page/privacy');
      await page.fill('input[name="email"]', email);
      await page.fill('input[name="url"]', profileUrl);
      await page.click('.submit-btn');
      break;
  }

  await browser.close();
}

// Rate limit to avoid triggering bot detection
async function batchOptOut(profiles) {
  for (const profile of profiles) {
    await submitOptOut(profile.site, profile.url, profile.email);
    await new Promise(r => setTimeout(r, 2000 + Math.random() * 3000));
  }
}

The main friction points: CAPTCHA on some forms, email confirmation required on most, and a few sites require the user to find their own profile URL first (can't just submit a name).

CCPA as a Lever

For California residents (and US residents targeting California-based brokers), the CCPA gives individuals the right to:

Know what data is collected about them
Request deletion
Opt out of sale

Submitting a CCPA deletion request often gets faster and more thorough responses than the standard opt-out form, even from brokers that theoretically don't have to respond. Use the Global Privacy Control (GPC) signal in your browser header — it's legally recognized in California and several other states:

// GPC header — supported by Firefox and Brave natively
// Can be set programmatically:
navigator.globalPrivacyControl // true if GPC enabled

// For server-side requests:
headers['Sec-GPC'] = '1'

The Realistic Picture

Manual opt-outs from the top 10-15 consumer-facing sites takes about 2-3 hours and provides meaningful short-term privacy improvement, particularly for address exposure. The data comes back in 3-6 months.

The deeper problem is that the legal architecture in the US makes this a whack-a-mole exercise until federal privacy legislation passes. For users who need durable protection — domestic violence survivors, public figures, journalists — the paid services plus CCPA requests plus synthetic identity strategies (PO boxes, registered agents for property) are the more serious toolkit.

Consumer-facing explanation of the same topic, including the exact opt-out steps for each major site: lucas8.com/data-broker-opt-out-guide

How AI Phishing Emails Are Built (And the One Pattern That Always Gives Them Away)

Spicy — Sun, 14 Jun 2026 14:24:56 +0000

Most phishing detection advice is now actively harmful. Teaching users to look for typos and generic greetings made sense when phishing was a spray-and-pray operation running on bad grammar. That era is over.

Here's how modern AI phishing is actually constructed, what signals remain reliable, and how to implement detection logic that accounts for the current threat model.

How an AI Spear Phishing Email Gets Built

The workflow an attacker follows in 2026 is largely automated:

Step 1: Target reconnaissance

# Typical OSINT data sources for a targeted attack
sources = {
    "linkedin": "job title, manager name, team structure, tenure",
    "company_website": "email format (first.last@company.com), press releases",
    "social_media": "recent posts, projects mentioned, travel",
    "data_broker": "personal email, phone, home address",
    "previous_breaches": "password patterns, security question answers"
}

All of this is publicly available or purchasable. A targeted attack on a finance manager will include their correct name, their CFO's actual name, and may reference a real business event pulled from a press release.

Step 2: Prompt engineering for the attack

The attacker doesn't write the email. They prompt a model:
The output is indistinguishable from a real internal email.

Step 3: Infrastructure

Lookalike domains are registered with realistic names (company-billing.com, companyfinance.io), SSL certificates acquired (free via Let's Encrypt — the padlock means nothing), and emails sent through legitimate SMTP infrastructure to pass basic spam filters.

What Traditional Detection Gets Wrong

The signals security training still teaches:

Signal	Why It Fails Now
Typos / bad grammar	LLMs produce perfect prose
Generic greeting	OSINT provides correct names trivially
Unknown sender	Lookalike domains pass visual inspection
Suspicious links	Links go to legitimate sites that redirect
Urgency alone	Legitimate emails also have urgency

None of these are reliable discriminators in 2026.

What Still Works: Authentication Layer Checks

SPF, DKIM, DMARC — these operate at the email infrastructure level and can't be faked without compromising the legitimate domain.

# Check authentication results for a received email
# Look for these headers in the raw message

# SPF: did the email originate from an authorized server?
Received-SPF: pass (google.com: domain of cfo@company.com designates 
  198.51.100.1 as permitted sender)

# DKIM: was the email cryptographically signed by the domain?
DKIM-Signature: v=1; a=rsa-sha256; d=company.com; s=selector1;

# DMARC: does the domain's policy require both to pass?
Authentication-Results: mx.google.com;
  dkim=pass header.d=company.com;
  spf=pass smtp.mailfrom=company.com;
  dmarc=pass (p=REJECT)

A legitimate internal email from your CFO should pass all three. Any failure is a hard signal — not a soft one. Most attackers can't pass DMARC on the domain they're spoofing without compromising it directly.

Programmatic header parsing:

// Parse authentication results from email headers
function parseAuthResults(headers) {
  const authHeader = headers['authentication-results'] || '';

  return {
    spf: authHeader.match(/spf=(pass|fail|softfail|neutral)/)?.[1] || 'missing',
    dkim: authHeader.match(/dkim=(pass|fail|none)/)?.[1] || 'missing',
    dmarc: authHeader.match(/dmarc=(pass|fail|none)/)?.[1] || 'missing',
  };
}

function isAuthenticationSuspicious(authResults) {
  const { spf, dkim, dmarc } = authResults;
  // Any failure on a supposedly internal or financial email = flag
  return spf !== 'pass' || dkim !== 'pass' || dmarc !== 'pass';
}

The Signal That Doesn't Depend on Content

Authentication checks require access to headers. The signal that works at the human layer — and that AI cannot defeat — is the request pattern.

Legitimate organizations have consistent behavioral signatures:

const PHISHING_REQUEST_PATTERNS = [
  'wire transfer outside normal approval chain',
  'request for credentials or MFA codes via email',
  'urgency to bypass standard process',
  'confidentiality instruction (do not tell X)',
  'new payment method or vendor not in system',
  'action requested on behalf of unavailable approver',
];

// The key insight: legitimate urgent requests
// arrive through established channels with context.
// Phishing creates the urgency in the email itself.

This pattern holds regardless of how the email is written. AI can generate perfect prose but cannot change the fact that a real CFO initiating a real wire transfer uses the company's actual payment system, not a direct email to a finance manager with a new bank account.

Building a Detection Heuristic

For teams building email security tooling or internal automation:

def phishing_risk_score(email):
    score = 0

    # Authentication failures (high weight)
    if email.spf != 'pass': score += 40
    if email.dkim != 'pass': score += 30
    if email.dmarc != 'pass': score += 30

    # Domain analysis
    if is_lookalike_domain(email.sender_domain): score += 50
    if email.reply_to != email.from_address: score += 25

    # Request pattern signals (content analysis)
    content = email.body.lower()
    if any(phrase in content for phrase in [
        'wire transfer', 'bank account', 'routing number'
    ]): score += 20
    if any(phrase in content for phrase in [
        'urgent', 'immediately', 'today only', 'close of business'
    ]): score += 10
    if any(phrase in content for phrase in [
        'keep this confidential', "don't mention", 'just between us'
    ]): score += 30

    # High score = route to additional verification, not auto-block
    return score

def is_lookalike_domain(domain, legitimate_domains):
    from jellyfish import jaro_winkler_similarity
    return any(
        jaro_winkler_similarity(domain, legit) > 0.85 
        and domain != legit
        for legit in legitimate_domains
    )

The key design decision: high-risk emails should trigger an out-of-band verification requirement, not an auto-block. Auto-blocking has false positive costs; requiring phone verification for flagged financial requests has almost none.

The Defense That Defeats All Variants

Out-of-band verification: any email requesting financial action, credential changes, or process exceptions gets verified via phone call to a number already on record.

This rule is architecturally sound because it breaks the attack at the social engineering layer regardless of how convincing the email is. It doesn't matter how good the AI gets at writing emails — it can't intercept a phone call the target initiates to a known number.

The consumer version of this — what non-technical users should watch for — is at lucas8.com/how-to-spot-ai-phishing-email

What a VPN Actually Does (And Why Most Devs Use It Wrong)

Spicy — Thu, 11 Jun 2026 17:02:35 +0000

Every developer I know has a VPN. Most of them have it running while they're logged into Google, sending data through Chrome, and using apps that do their own certificate pinning — which means the VPN is protecting approximately nothing meaningful in that moment.

This isn't a knock on VPNs. It's a scoping problem. Here's what the tool actually covers, what leaks around it, and how to test it properly.

What's Actually Happening at the Network Layer

A VPN operates at Layer 3 (Network) of the OSI model. It creates an encrypted tunnel — typically using WireGuard, OpenVPN, or IKEv2/IPSec — between your device and a VPN server. All IP traffic gets routed through that tunnel.

Protocol comparison:

Protocol	Speed	Security	Port	Notes
WireGuard	⭐⭐⭐ Fast	⭐⭐⭐ Strong	UDP 51820	Modern, audited, ~4000 lines of code
OpenVPN	⭐⭐ Medium	⭐⭐⭐ Strong	TCP 443 / UDP 1194	Battle-tested, ~100k lines
IKEv2/IPSec	⭐⭐⭐ Fast	⭐⭐ Good	UDP 500/4500	Native on mobile, good reconnect
L2TP/IPSec	⭐ Slow	⭐ Weak	UDP 1701	Avoid — potentially compromised

WireGuard is the correct choice in 2026 unless you have a specific reason not to use it. Smaller codebase = smaller attack surface. Most audited VPN providers now use it by default.

What Leaks Around the Tunnel

The VPN handles IP routing. It doesn't handle everything else.

DNS leaks are the most common issue. If your system's DNS resolver isn't explicitly routed through the tunnel, your DNS queries go directly to your ISP — revealing every domain you visit even with the VPN active.

Test this from the terminal:

# Check your current DNS resolver
cat /etc/resolv.conf

# Test for DNS leak (run while VPN is active)
# Should show your VPN provider's DNS, not your ISP's
nslookup whoami.akamai.net

# More thorough test
dig +short myip.opendns.com @resolver1.opendns.com

Most reputable VPN clients handle DNS routing automatically, but worth verifying — especially on Linux where DNS management is fragmented across systemd-resolved, dnsmasq, and NetworkManager depending on your distro.

WebRTC leaks expose your real IP through browser APIs even when a VPN is active. This is a browser-layer problem, not a network-layer problem.

// WebRTC leak test — run in browser console while on VPN
// If this returns your real IP, you have a WebRTC leak
const pc = new RTCPeerConnection({
  iceServers: [{ urls: 'stun:stun.l.google.com:19302' }]
});
pc.createDataChannel('');
pc.createOffer().then(offer => pc.setLocalDescription(offer));
pc.onicecandidate = (e) => {
  if (e.candidate) {
    const ip = e.candidate.candidate.match(/(\d+\.\d+\.\d+\.\d+)/);
    if (ip) console.log('IP exposed via WebRTC:', ip[1]);
  }
};

Fix: Firefox has media.peerconnection.enabled in about:config. Chrome requires an extension or a VPN client with WebRTC leak protection built in.

Application-layer tracking doesn't touch the network layer at all. If you're authenticated in your browser, that session follows you. Cookies, localStorage, IndexedDB — none of this is affected by routing your IP through Amsterdam.

The Kill Switch and Why It Matters

A kill switch blocks all traffic if the VPN connection drops. Without it, your traffic briefly reverts to your real IP when the tunnel reconnects. This is the correct default for any privacy-sensitive setup.

On Linux with ufw:

# Block all traffic by default
sudo ufw default deny outgoing
sudo ufw default deny incoming

# Allow only traffic through VPN interface (tun0 for OpenVPN, wg0 for WireGuard)
sudo ufw allow out on tun0
sudo ufw allow out on wg0

# Allow LAN traffic if needed
sudo ufw allow out on eth0 to 192.168.0.0/16
sudo ufw allow out on eth0 to 10.0.0.0/8

sudo ufw enable

WireGuard users can use PostUp/PreDown hooks in the config for a more integrated approach:

[Interface]
PrivateKey = <your_private_key>
Address = 10.x.x.x/32
DNS = 1.1.1.1

PostUp = iptables -I OUTPUT ! -o wg0 -m mark ! --mark $(wg show wg0 fwmark) -j REJECT
PreDown = iptables -D OUTPUT ! -o wg0 -m mark ! --mark $(wg show wg0 fwmark) -j REJECT

Split Tunneling: Route Only What You Need

Split tunneling lets you route specific traffic through the VPN while everything else goes directly. Useful when you need VPN for specific services but don't want to tunnel your local development traffic or internal network requests.

Most GUI clients support this natively. For WireGuard directly:

[Peer]
PublicKey = <server_public_key>
Endpoint = <server_ip>:51820

# Route only specific subnets through VPN instead of all traffic
AllowedIPs = 10.0.0.0/8, 172.16.0.0/12

# vs. route everything:
# AllowedIPs = 0.0.0.0/0, ::/0

What a VPN Actually Buys You (Honest Summary)

✅ Your ISP can't see which domains you visit
✅ Traffic encrypted against public WiFi eavesdropping
✅ Your IP hidden from destination servers
✅ DNS queries protected (if configured correctly)
❌ No protection against cookie/session tracking
❌ No protection against browser fingerprinting
❌ No protection while authenticated in any app or service
❌ No protection from the VPN provider themselves

The tool solves a specific set of network-layer problems. For application-layer privacy, you need application-layer solutions — content blocking, session isolation, fingerprint-resistant browsers.

If you're setting up a VPN for a team or personal setup and want the technical layer done properly: WireGuard, verified DNS routing, kill switch enabled, and DNS leak tested before you trust it. Everything else is marketing.

Consumer version — what this means for people who don't want to touch iptables: lucas8.com/what-vpn-actually-protects

Passkeys Under the Hood: What's Actually Happening When You Use Face ID to Log In

Spicy — Thu, 11 Jun 2026 11:57:02 +0000

Every developer I know understands that passwords are broken. What fewer people have actually dug into is why passkeys fix this at the protocol level — and how surprisingly simple the WebAuthn API is to implement.

Here's the full picture: what's happening cryptographically, how the browser API works, and a quick comparison of the libraries worth using in production.

The Core Problem With Passwords (The Actual Technical One)

Passwords fail not because users pick weak ones. They fail because of how the authentication model works:

User creates a password
Server stores a hash of it
User sends the password on every login
Server hashes it and compares

Step 3 is the problem. The credential gets transmitted. That transmission can be intercepted (phishing), the hash can be cracked (breach), or the same credential works on other sites (credential stuffing). Every "password best practice" is mitigation, not a fix.

Passkeys change the model entirely.

How Passkeys Actually Work

Passkeys use asymmetric cryptography (FIDO2/WebAuthn). Here's the flow:

Registration:

Server sends a random challenge
Device generates a public/private key pair
Private key stays on device (in Secure Enclave / TPM)
Public key + signed challenge sent to server
Server stores public key only

Authentication:

Server sends a new random challenge
User approves with biometric/PIN
Device signs the challenge with private key
Server verifies signature using stored public key
Done — private key never leaves the device

The private key is never transmitted. Ever. The server never stores anything that can be used to impersonate the user. A phishing page that captures the signed challenge gets nothing reusable — challenges are single-use nonces.

The WebAuthn API in Practice

The browser API maps directly to that flow. Registration looks like this:

// Registration
const credential = await navigator.credentials.create({
  publicKey: {
    challenge: serverChallenge, // Uint8Array from your server
    rp: { name: "Your App", id: "yourapp.com" },
    user: {
      id: userId,           // Uint8Array, not a username
      name: "user@email.com",
      displayName: "User Name"
    },
    pubKeyCredParams: [
      { alg: -7, type: "public-key" },   // ES256 (preferred)
      { alg: -257, type: "public-key" }  // RS256 (fallback)
    ],
    authenticatorSelection: {
      residentKey: "required",        // Enables passkey sync
      userVerification: "required"    // Requires biometric/PIN
    },
    timeout: 60000,
    attestation: "none"
  }
});

// Send credential.response to your server for verification

Authentication is simpler:

// Authentication
const assertion = await navigator.credentials.get({
  publicKey: {
    challenge: serverChallenge,
    rpId: "yourapp.com",
    userVerification: "required",
    timeout: 60000
  }
});

// Send assertion.response to your server for verification

The server-side verification is where most devs reach for a library — parsing and verifying the CBOR-encoded attestation objects by hand is painful.

Library Comparison

Library	Language	Passkey Support	Notes
SimpleWebAuthn	Node.js	✅ Full	Best DX, actively maintained
py_webauthn	Python	✅ Full	Duo Labs, solid
webauthn4j	Java	✅ Full	Spring integration available
go-webauthn	Go	✅ Full	Clean API
Hanko	Hosted	✅ Managed	Drop-in if you don't want to own the flow
Passage by 1Password	Hosted	✅ Managed	Generous free tier

For most teams: SimpleWebAuthn for Node, py_webauthn for Python. If you want to skip the implementation entirely and just own the UX, Hanko's self-hostable version is genuinely good.

The Two Things That Catch People Out

1. residentKey: "required" is what makes it a passkey

Without this, you're implementing a regular FIDO2 security key flow — the credential isn't stored on the device and won't sync to iCloud/Google. If you want the "tap Face ID to log in" experience, residentKey: "required" and userVerification: "required" are both mandatory.

2. Cross-device auth uses CTAP2 + BLE proximity

When a user authenticates on a desktop with their phone, the desktop and phone establish a BLE proximity check to prevent remote attacks, then the phone signs the challenge and sends the signature back via a relay server. The private key never leaves the phone. Worth understanding before you field questions about "is it safe to use my phone to log into someone else's computer."

What I'd Actually Implement First

If you're adding passkeys to an existing app: don't rip out passwords. Add passkeys as an additional auth method first. Let users opt in. The fallback matters — not every user has a device that supports passkeys smoothly yet, and some enterprise environments block biometric auth entirely.

The happy path is excellent. The failure modes are what you need to design for. Test especially: browser without platform authenticator support, iOS 15 (passkey sync requires iOS 16+), and password manager conflicts when users have both a passkey and a saved password for the same domain.

The consumer version of this — what passkeys mean for regular users who don't care about WebAuthn — is over at lucas8.com/passkeys-vs-passwords-security.

Your Smart Home Is Collecting Data You Never Agreed To — Here's How to Audit It

Spicy — Thu, 04 Jun 2026 15:49:40 +0000

Most developers I know have locked-down laptops — password managers, 2FA everywhere, encrypted drives. Then they go home and have a robot vacuum with a cloud-synced floor plan of their apartment, a smart TV that screenshots their screen every few minutes, and a doorbell camera on default settings.

The home network is the gap. Here's a device-by-device audit you can run in 30 minutes, with the specific settings to change on each platform.

The Problem: Smart Home Defaults Are Set for Data Collection, Not Privacy

Every smart home device ships with a companion app and a terms of service most people skip. The defaults in those apps are almost universally set to maximize data collection — because that data has value to manufacturers, advertisers, and in some cases, third-party brokers.

A few concrete examples before we get into the audit:

Smart TVs use ACR (Automatic Content Recognition) to take screenshots of whatever is on screen — including HDMI input from game consoles or set-top boxes — and send them to the manufacturer for ad targeting.
iRobot Roomba (now owned by Amazon) floor maps can be accessed within the Amazon ecosystem. In 2022, images captured during cleaning were found to have been used in AI training datasets.
Amazon Ring previously allowed law enforcement to request footage directly from Amazon servers, bypassing homeowners. This practice ended after a 2023 FTC settlement that resulted in a $5.8 million fine.

None of this is hidden — it's in the privacy policies. But defaults being what they are, most users never change them.

Device-by-Device Audit Checklist

Smart TV — Disable ACR

ACR is the big one. Here's where to find it by brand:

Brand	Path
Samsung	Settings → Support → Terms & Privacy → Viewing Information Services → Off
LG	Settings → All Settings → General → About This TV → User Agreements → disable "Personalized Advertising"
Vizio	Settings → System → Reset & Admin → Viewing Data → Off
Sony (Google TV)	Settings → Privacy → Ads → Opt out of Ads Personalization

While you're in there: disable the microphone if you don't use voice commands. It's usually under Settings → General → Voice or Smart Features.

Robot Vacuum — Delete Maps, Review Sharing

Open the companion app (iRobot Home, Roborock, Ecovacs Home, etc.)
Navigate to Privacy or Account Settings
Delete saved maps
Opt out of data sharing / analytics
Check if your model supports local-only map processing — some Roborock models do

If you're using a Roomba and have it linked to Alexa, be aware that map data flows into the Amazon ecosystem. You can limit this by removing the Alexa skill and keeping accounts unlinked.

Doorbell / Security Cameras — Review Cloud Storage and Law Enforcement Policy

The two things to check:

Cloud storage scope: Most cameras upload continuously. Review whether you're on a plan that stores footage on the company's servers indefinitely, and whether you can switch to local storage (NAS, SD card) for sensitive areas.

Law enforcement policy: Ring, Nest, Arlo, and most major brands publish transparency reports. Look up your brand's policy on government data requests. Since the Ring FTC settlement, consent is nominally required — but warrant-based access still applies.

Facial recognition: If your camera offered this as a feature (Google Nest Aware had it; Ring has offered versions of it), check if it's enabled and consider disabling it.

Home Network — Isolate Your IoT Devices

This is the most impactful single change you can make from a security standpoint.

Most consumer routers support a guest network. Put all your smart home devices on it. This means:

A compromised IoT device can't pivot to your laptops or NAS
Cross-device data correlation between your phone and your vacuum is broken at the network layer
You can monitor IoT traffic separately

If you want more visibility, Fing (free tier) gives you a device inventory and flags unusual traffic patterns without requiring router-level config changes.

Phone App Permissions — Revoke What Isn't Needed

Smart home apps accumulate permissions over time. Audit them:

iOS: Settings → Privacy & Security → review Microphone, Camera, Location, Contacts

Android: Settings → Privacy → Permission Manager → review by permission type

General rule: a smart bulb app has no legitimate reason to access your microphone. A robot vacuum app doesn't need your contacts. Location access should be "While Using" at most, not "Always."

The Longer-Term Fix: Matter Protocol

The industry is slowly moving toward Matter — an open smart home standard backed by Apple, Google, Amazon, and Samsung. The key privacy advantage: Matter-compatible devices can operate locally on your home network without cloud dependency for basic functions.

Local processing means less data leaving your network by default. It's not a complete privacy solution, but it's a meaningful architectural improvement over the current cloud-first model.

When you're next replacing a device, filtering for Matter compatibility is worth adding to your checklist.

Summary Table

Device	Time	Key Action
Smart TV	5 min	Disable ACR, turn off microphone
Robot Vacuum	5 min	Delete maps, review data sharing
Cameras	10 min	Review cloud storage, disable facial recognition
Home Network	5 min	Move IoT to guest network
Phone Apps	5 min	Revoke microphone, location, contacts

The defaults on every one of these devices were chosen by the manufacturer. Spending 30 minutes changing them is the most direct form of control you have over what your home network is actually doing.

Full version with more detail on each step: lucas8.com/smart-home-privacy-audit-guide

The 7 Moves Identity Thieves Pray You Never Make

Spicy — Thu, 04 Jun 2026 15:46:42 +0000

Every 4.9 seconds, someone in the US becomes an identity theft victim. Over 1.1 million FTC reports in 2024. $12.5 billion in losses. And the uncomfortable truth? Most of it wasn't sophisticated hacking. It was reused passwords, unfrozen credit, and forgotten accounts.

Here's what actually works in 2026 — and why most people still aren't doing it.

Move 1: Freeze Your Credit at All Three Bureaus

This is the highest-ROI security action most people never take. A credit freeze blocks any new lender from accessing your file — no access, no fraudulent new accounts.

It's free by federal law. Takes ~10 minutes per bureau. Zero impact on your credit score.

The critical detail most guides skip: you must freeze all three separately. A freeze at Equifax does nothing at Experian or TransUnion.

Bureau	URL	Phone
Equifax	equifax.com/credit-freeze	1-888-298-0045
Experian	experian.com/help/credit-freeze	1-888-397-3742
TransUnion	transunion.com/credit-freeze	1-800-916-8800

When you need to apply for credit, lift temporarily at the relevant bureau, then re-freeze. If you have kids: freeze their SSNs too — children's numbers are prime targets because they have zero monitoring.

Move 2: Run a Breach Check Right Now

Go to haveibeenpwned.com and enter every email address you use, including old ones. It searches hundreds of confirmed breach dumps and tells you exactly which services exposed your account.

If any match: assume every password you used on that site is compromised. Hashed passwords aren't safe — most common hash formats have been cracked at scale by now.

For ongoing coverage, Google Password Manager's built-in Password Checkup automatically flags saved credentials that appear in new breach data. Free, no setup required beyond using Chrome or Google's password manager.

Move 3: Stop Reusing Passwords

Credential stuffing is fully industrialized in 2026. Attackers buy breach data in bulk, run automated tools against hundreds of sites simultaneously, and your reused YourName2019! password is already in a combolist somewhere.

In 2025 alone, over 1.8 billion login credentials were stolen from infected devices (Recorded Future). Infostealer malware families like Lumma and RedLine scrape browser password vaults silently — your saved passwords in Chrome are a high-value target.

The fix is mechanical: use a password manager with unique, randomly generated passwords for every site.

Free + open source: Bitwarden
Paid, well-regarded: 1Password, Dashlane

You remember one master password. The manager handles the rest.

Move 4: Enable 2FA — Especially on Email

A strong unique password stops most attacks. 2FA stops almost everything else.

Enable it everywhere that matters, in this priority order:

Email first — whoever controls your inbox can reset access to everything else
Banking and financial accounts
SSA.gov (create a My Social Security account, enable 2FA, block fraudulent benefit claims)
Apple ID / Google Account
Anything storing payment data

Authenticator apps > SMS. SMS 2FA can be bypassed via SIM-swap attacks — a thief convinces your carrier to transfer your number to their device. App-based codes (Google Authenticator, Authy, Microsoft Authenticator) don't have this vulnerability.

Move 5: Shrink Your Attack Surface

Two categories to trim:

Old accounts: Every forgotten account is a potential breach vector. Use justdeleteme.xyz to find deletion instructions for hundreds of services. If you can't delete, at least change the password to something unique.

Data brokers: These companies aggregate your address, phone number, relatives, and enough detail to answer your security questions — then sell it to anyone who pays. Automated opt-out tools (DeleteMe, Kanary) handle the removal process since there are hundreds of brokers and each has its own opt-out flow.

Smaller digital footprint = harder to build a targeting profile against you.

Move 6: Know the Attack Vectors

Understanding how the attack actually happens makes prevention concrete rather than abstract.

Phishing remains the dominant entry point — a convincing email, text, or call impersonating your bank, the IRS, or a delivery service. AI-generated voice cloning has made phone-based phishing significantly more convincing in 2026: callers now sound exactly like your bank's fraud team.

Data breaches are largely outside your control at the company level. The ITRC recorded 3,322 data compromises in 2025 — a 79% five-year jump — generating 140 million victim notices in Q1 2026 alone. Your mitigation: unique passwords ensure one breach doesn't cascade into twenty.

Social engineering via public profiles: Your dog's name in your Instagram bio, your employer on LinkedIn, your birthday on Facebook — that's often enough to answer security questions and trigger a password reset.

Mail theft: Old-fashioned, but still real. Switch everything to paperless statements.

Move 7: Know the Early Warning Signs

Thieves often sit on stolen data for months before using it — waiting for breach-related fraud alerts to expire. These are the signals to watch:

Unexpected hard inquiries on your credit report
Collection notices for accounts you never opened
Tax return rejection (someone filed using your SSN already)
Health insurer denial for treatment you never received
Password reset emails or login notifications you didn't request

Free monitoring tools:

AnnualCreditReport.com — one free report per bureau per year (stagger them for year-round coverage)
IdentityTheft.gov — FTC's recovery plan generator if you're already a victim

The Honest Summary

Move	Time to Set Up	Cost	Impact
Credit freeze (all 3)	~30 min	Free	Blocks new fraudulent accounts
Breach check (HIBP)	5 min	Free	Surfaces compromised credentials
Password manager	1–2 hours	Free–$3/mo	Stops credential stuffing
2FA on email + banking	20 min	Free	Stops most account takeovers
Delete old accounts	1 hour	Free	Reduces breach surface
Paperless statements	10 min	Free	Eliminates mail theft vector
Credit monitoring	Ongoing	Free	Early detection

None of these require technical expertise. The hardest part is starting. The credit freeze takes about 30 minutes across all three bureaus — do that first, today, before anything else.

Original post: lucas8.com/identity-theft-prevention-moves

Fitness Tracker Privacy in 2026: Fitbit vs Garmin vs Apple Watch vs Oura (What the Data Actually Shows)

Spicy — Wed, 03 Jun 2026 16:13:03 +0000

You wear your fitness tracker 24/7. It knows your resting heart rate, your sleep cycles, your GPS routes, your stress levels, and — depending on the model — your blood oxygen, menstrual cycle, and ECG readings.

Here's the question most people never think to ask: who else has access to that data?

The answer depends almost entirely on which brand you're wearing. And the gap between the best and worst performers is significant.

The HIPAA Gap (Most People Get This Wrong)

Before anything else: your fitness tracker data is almost certainly not covered by HIPAA.

HIPAA applies to covered entities — hospitals, health insurers, healthcare clearinghouses, and their direct business associates. Consumer wearable companies (Fitbit, Garmin, Apple, Whoop, Oura) are none of these.

Your smartwatch heart rate data has fewer legal protections than a doctor's handwritten note. The only frameworks that partially apply are state laws — California's CCPA, Illinois' BIPA — and even those have significant gaps.

What you're left with: each company's own privacy policy. Let's go through them.

Fitbit (Now Google Health): ⚠️ Caution

As of May 2026, all Fitbit accounts have migrated to Google accounts. Your health data is now governed by Google's privacy policy.

What the data says:

Fitbit collects 23 data types per Apple's App Store privacy labels — the most of any tracker in this comparison
Google has committed that Fitbit health data won't be used for Google Ads
The privacy policy still permits sharing aggregated/de-identified data for "research and commercial purposes"
Analytics SDKs from Meta and Google are embedded in the app, transmitting usage data

The re-identification problem: A 2024 Imperial College London study found that supposedly anonymous fitness datasets could be re-identified with 87% accuracy using just three data points: age range, zip code, and activity pattern. "De-identified" isn't as safe as it sounds.

In 2026: Whoop faces a class-action lawsuit in California for data-sharing practices with advertising partners — a signal of where regulatory pressure is heading across the industry.

Smart Home Devices Are Collecting More Than You Think — Here's What to Do

Spicy — Sun, 31 May 2026 08:42:21 +0000

The Problem Nobody Reads the Privacy Policy For

93% of American households now own at least one smart home device. According to the 2026 Copeland Smart Home Data Privacy Study, 57% of those owners are worried about how their data is being used — and 55% have little to no idea what their smart thermostat actually sends back to the manufacturer.

That gap between adoption and understanding is where the real risk lives.

This post covers what the major device categories actually collect, what happens to that data downstream, and the specific settings worth changing today. No tinfoil hats. Just the defaults that are set against your interests.

What Gets Collected, by Device Type

Smart Speakers (Echo, Google Nest, HomePod)

All three platforms use continuous wake-word detection, which means audio is always being processed locally. The problem is accidental activations: researchers at Northwestern University and Imperial College London documented Google Home Mini triggering ~0.95 times per hour during passive TV playback. Each trigger sends audio to the cloud.

Both Amazon and Google have acknowledged using human contractors to review voice samples. This isn't theoretical — it's documented and settled. The recordings persist unless you actively delete them.

What's downstream: Voice data is used to train speech models. This matters more than it used to — a voice clip as short as three seconds is sufficient for modern voice synthesis tools to generate a convincing clone. See the implications in this related piece on AI voice cloning fraud.

Smart TVs

Virtually every major smart TV manufacturer ships with Automatic Content Recognition (ACR) enabled by default. ACR takes periodic screenshots of what's on screen — regardless of input source — and reports it back to the manufacturer.

The data profile includes: what you watch, when you watch, how long, and on what input. This is sold to advertising networks and, in some documented cases, to insurance companies running behavioral risk models.

Manufacturer	ACR Setting Name	Location
Samsung	Viewing Information Services	Settings → Support → Terms & Policy
LG	LivePlus	Settings → All Settings → General
Vizio	Smart Interactivity	Menu → System
Roku (all brands)	Limit Ad Tracking	Settings → Privacy

Disabling ACR has zero effect on streaming functionality.

Smart Thermostats

Thermostat data is behavioral at the most granular level: wake time, departure time, return time, sleep time — every day. The 2026 Copeland study found concern about data privacy among thermostat owners grew from 26% in 2022 to 37% in 2026. The Nest thermostat also uses your phone's GPS by default to determine home/away status, which means Google maintains a continuous location record tied to your home presence patterns.

The Network Risk Nobody Talks About

Individual device privacy settings matter. But the larger threat is architectural.

Bitdefender's 2025 threat intelligence data found that connected homes averaged 29 daily attack attempts — a 3× increase year-over-year. The attack vector is almost always the same: a device with default credentials, unpatched firmware, or a known CVE that the manufacturer never fixed.

A compromised smart bulb isn't dangerous because someone controls your lights. It's a lateral movement opportunity into the same network segment where your laptop, phone, and financial sessions live.

The fix: network segmentation.

Most consumer routers support a guest network. The correct configuration is simple:

Stop Wasting 32% of Your Cloud Budget: A FinOps Playbook for DevOps Engineers

Spicy — Sat, 30 May 2026 15:37:09 +0000

You're in a sprint planning meeting and someone drops the monthly cloud bill on the table. It's up again. Nobody knows exactly why. The DevOps lead says it's probably the new microservices rollout. Finance says it's been climbing for six months. Everyone nods and moves on.

This is a story playing out in thousands of engineering orgs right now. According to the FinOps Foundation's State of FinOps 2026 survey — which aggregated data from 1,200+ organizations running over $69 billion in cloud spend — teams without a structured optimization practice waste 32 to 40 percent of their cloud budget every month.

For a $500K/year cloud budget, that's $160K to $200K disappearing into idle instances, orphaned volumes, and on-demand pricing on workloads that have been running predictably for years.

Here's the 5-tactic playbook to fix it.

Tactic 1 — Rightsize Before Anything Else

Pull 30 days of CPU and memory utilization data. Any instance averaging below 20% CPU with 40%+ memory headroom is a rightsizing candidate.

AWS CLI quickstart:

# Find all EC2 instances and their current types
aws ec2 describe-instances \
  --query "Reservations[*].Instances[*].[InstanceId,InstanceType,State.Name]" \
  --output table

# Then check CPU utilization via CloudWatch for each ID
aws cloudwatch get-metric-statistics \
  --namespace AWS/EC2 \
  --metric-name CPUUtilization \
  --dimensions Name=InstanceId,Value=<INSTANCE_ID> \
  --start-time 2026-05-01T00:00:00Z \
  --end-time 2026-05-29T00:00:00Z \
  --period 86400 \
  --statistics Average

AWS Cost Explorer's rightsizing recommendations do this automatically with a single click. GCP Active Assist and Azure Advisor are equivalent. Rightsizing typically delivers 15–25% compute savings.

For Kubernetes, use OpenCost — it's free, CNCF-sandbox, and gives you per-pod cost visibility that native cloud consoles miss entirely.

Tactic 2 — Stop Running Steady-State Workloads at On-Demand Prices

Reserved Instances and Savings Plans deliver 40–72% savings vs on-demand for the same compute. If a service has been running continuously for 3+ months, you should not be paying on-demand for it.

Comparison: AWS commitment options

Type	Savings vs On-Demand	Flexibility	Best For
1-Year Reserved Instance	~40%	Low (instance-locked)	Known, stable workloads
3-Year Reserved Instance	~62–72%	Very low	Long-term steady state
Compute Savings Plan (1yr)	~40%	High (any family/region)	Evolving architectures
Spot Instances	60–90%	Very high (interruptible)	Batch, CI/CD jobs

Start with Compute Savings Plans unless you know exactly which instance types you'll need for the next 3 years — you almost certainly don't.

Tactic 3 — Schedule Non-Prod Environments to Stop at Night

Your dev/staging/test environments do not need to run at 2 AM on Saturday. Scheduling them to stop outside business hours reduces those environment costs by 65–70%.

For AWS, the Instance Scheduler is the native option. For Kubernetes, combine HPA with scheduled scale-to-zero on non-production namespaces. Add a Slack /wakeup staging command via a simple Lambda so engineers can spin up on demand without leaving things running permanently.

FinOps Foundation benchmark: Teams that implement environment scheduling see 10–20% reduction in total cloud spend. It's the easiest win with the least technical risk.

Tactic 4 — Audit Storage and Snapshots

Storage waste is invisible until you look for it. Three areas consistently surface quick wins:

Unattached EBS volumes:

aws ec2 describe-volumes \
  --filters Name=status,Values=available \
  --query "Volumes[*].[VolumeId,Size,CreateTime]" \
  --output table

Any volume in available state isn't attached to anything. Delete or snapshot-and-delete.

Snapshot retention: Set a maximum 30-day retention policy for non-critical snapshots. Older snapshots should move to cheaper tiers. Most teams find they're keeping hundreds of snapshots that serve no real disaster recovery purpose.

S3 lifecycle policies: Data not accessed in 90 days → Infrequent Access. Data older than 180 days → Glacier. This alone can cut S3 costs 30–40% for data-heavy workloads.

Tactic 5 — Tag Everything, Then Enforce It

Without cost allocation tags, nobody owns the bill. The minimal effective tag set: team, app, env (prod/staging/dev), cost-center.

Enforce tagging at provisioning with AWS Service Control Policies:

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Deny",
    "Action": ["ec2:RunInstances", "rds:CreateDBInstance"],
    "Resource": "*",
    "Condition": {
      "Null": {
        "aws:RequestedRegion": "false",
        "aws:ResourceTag/team": "true",
        "aws:ResourceTag/env": "true"
      }
    }
  }]
}

Once tagging is clean, a cost-per-team dashboard changes behavior faster than any top-down mandate.

Tool Comparison: Native vs Third-Party

Tool	Best For	Cost	Multi-Cloud?
AWS Cost Explorer	AWS-native rightsizing, reservations	Free (+ $0.01/API call)	No
GCP Active Assist	GCP idle resource detection	Free	No
OpenCost	Kubernetes cost allocation	Free (open source)	Yes
CloudHealth (Broadcom)	Large enterprise multi-cloud	Paid	Yes
CAST AI	Kubernetes rightsizing + automation	Freemium	Yes
Kubecost	Kubernetes cost + CNCF-compatible	Freemium	Yes

The Results You Can Expect

Tactic	Effort	Typical Savings	Time to Results
Rightsizing	Medium	15–25% compute	2–4 weeks
Reservations / Savings Plans	Low	40–72% on committed spend	Immediate
Environment scheduling	Low	10–20% total spend	1 billing cycle
Storage cleanup	Low	5–15% total spend	1 billing cycle
Tagging governance	High (setup)	Enables all others	30–60 days

FinOps Foundation data shows that mature programs reduce total cloud waste to 15–20% — roughly half the 32–40% baseline. You won't eliminate waste entirely, but getting from 35% to 18% on a $1M budget is $170K back in engineering budget per year.

If you want the full guide with deeper dives on commitment strategy and FinOps culture, the original post is on lucas8.com.