This page serves the raw LLM context file. You can access the raw text file directly at /llms-full.txt.

# Jorel's Blog — Complete Site Context
# Generated dynamically. All published posts and pages.
# Total articles: 8
# Last updated: 2026-07-05T17:57:11.795Z

---
# TITLE: About
## Type: Page

Hey, I'm Jorel.

I work as a CISO, which is a busy enough day job on its own. Outside of work, I do a lot of free mentoring, informal consulting, advisory work, and I sometimes post my thoughts on LinkedIn. But LinkedIn has its own set of issues, so I wanted a parallel home for my content where I have total control over the functionality.

This space is entirely free and I am holding firm on that. There are zero ads and zero tracking scripts. Since I'm not collecting a single piece of your data, you won't see an annoying cookie banner here. If you ever happen to spot a weird tracker hiding on this domain, let me know so I can kill it.

Eventually, the goal is to build out some open features so people can grab these notes however they prefer, whether you use an old-school RSS reader, just want a clean webpage, or want to pull raw markdown into an AI window.

The site itself isn't fully there yet, but I'm working on it. Bear with me while I attempt to get the plumbing sorted out.

The best way to get in touch is to connect with me on [LinkedIn](https://linkedin.com/in/jorelv) or email me at jorelv [at] gmail [dot] com.
---
# TITLE: Securing Entra Tier 0 Roles
## Date: 2026-03-17
## Excerpt: Phishing-resistant MFA for Entra ID admins is a great start, but it won’t stop attackers from downgrading flows, stealing session tokens, or registering rogue devices. Securing Tier 0 identity perimeters requires a hardened Conditional Access Policy (CAP) architecture. Here is how to close some of those gaps.

Phishing-Resistant MFA for your Entra ID admins is the right move. But if that is the _only_ control you configure, you are leaving multiple bypasses wide open.

Attackers do not need to break your FIDO2 key. They will just downgrade the authentication flow, steal a session token, or register their own MFA method to establish persistence.

Securing privileged identities requires a comprehensive Conditional Access Policy (CAP) architecture to close these gaps.

## Scoping the Tier 0 Perimeter

Before building these policies, you need to know exactly which accounts belong in this scope. I recommend using the [SpecterOps Tier Zero table ](https://specterops.github.io/TierZeroTable/)as your guide.

For all the policies below, the baseline scope is to target your **Tier 0 user groups** and apply them to **All Cloud Apps**.

## Core Conditional Access Policies

### 1. Enforce Phishing-Resistant MFA

- **Grant:** Require Authentication strength → Custom Authentication Strength (Phishing-resistant methods + Temporary Access Pass).
- **Architectural Note:** You must build a custom strength to allow TAPs for initial onboarding or recovery, as the built-in phishing-resistant strength does not include it.

### 2. Secure the Security Information Portal

Attackers will attempt an MFA downgrade attack to bypass your primary controls. If successful, their immediate next step is registering their own phishing-resistant MFA method to cement their access. This policy breaks that chain.

- **User Actions:** Register security information (instead of all cloud apps).
- **Grant:** Require Authentication strength → Custom Authentication Strength (Phishing-resistant methods + Temporary Access Pass).
- **Session:** Set **Sign-in frequency** to Every time.

> **Note:** Forcing "Every time" on the security registration portal triggers a fresh, mandatory MFA challenge even if an attacker attempts to access the portal using a hijacked session cookie.

### 3. Enforce Device Compliance & Block Unsupported Platforms

Privileged Access Workstations (PAWs) are the standard, but at a minimum, you must require a compliant device and explicitly block everything else. If you only target Windows/macOS for compliance, an attacker can bypass the check entirely by spoofing a Linux user agent. You need two distinct CAPs here:

**CAP A (Require Compliance & Entra-Joined)**

- **Conditions:** Device platforms → Include Windows and macOS.
- **Grant:** Require device to be marked as compliant **AND** Require Entra-Joined device.
- **Compliance Note:** Your Intune compliance policy should require an active EDR sensor running on the local machine.

C**ACAPP B (Block Unsupported**)

- **Conditions:** Device platforms → Include Any device, _Exclude_ Windows and macOS.
- **Grant:** Block access.

### 4. Block Vulnerable Authentication Flows

Phishing-resistant MFA means nothing if an attacker can bypass it using legacy or alternative protocols.

- **Conditions:** Authentication flows → Select Device code flow and Authentication transfer.
- **Grant:** Block access.

### 5. Session Controls to Mitigate Token Theft

While a properly tuned EDR should detect and kill the infostealers attempting to scrape session cookies, you need an identity-layer fallback for when the endpoint control fails.

- **Session:** Set **Sign-in frequency** to a short duration (e.g., 1-4 hours) and completely **disable persistent browser sessions**.
- **Note on Sign-in Frequency (SIF):** Since these are dedicated admin accounts, we do not care about breaking Outlook or Teams background sync. However, setting this to "Every time" against _All Cloud Apps_ will break Azure CLI, PowerShell scripts, and background portal telemetry. Use a short hard duration here, and reserve "Every time" strictly for high-risk targets like the Security Info portal above.

### 6. Enforce Token Protection

Token Protection cryptographically binds the session token to the specific device so it cannot be replayed on an attacker's machine.

- **Session:** Require token protection for sign-in sessions.
- **The Caveat:** This primarily protects native thick clients and specific Microsoft Edge configurations linked to the Primary Refresh Token (PRT). It leaves standard browser web sessions (like Chrome or Firefox) exposed. Because your admins operate heavily in web portals, aggressive Sign-in Frequency (the policy above) remains your primary defense for web sessions.

## Tenant Hardening & Administrative Controls

Beyond your CAPs, you must harden your core tenant configuration against social engineering and administrative bypasses:

### Protect the Architecture & Stop Helpdesk Phishing

Place your target admin groups inside a **Restricted Management Administrative Unit (AU)** and use **Role-assignable groups**. This prevents standard administrators or compromised helpdesk accounts from modifying your CAP configurations, changing group memberships, resetting passwords, changing MFA methods, or generating TAPs for Tier 0 accounts.

### Custom MFA Alerts

Microsoft does not have a native feature to send an email when a new MFA method is added. You should build a custom **Logic App** to monitor the audit logs and alert users/admins immediately when new methods are registered.

### Disable Self-Service Password Reset (SSPR)

We are not trusting passwords, so we do not need resets. Disable this at the user level and restrict built-in administrator password reset policies.

## Operational Governance

### Monitor for Configuration Drift

CAPs are only as good as they are on day one. Over time, exceptions are made, and policies drift from your intended secure state.

- **Tooling:** Use open-source frameworks like **Maester** or automated GitHub/GitLab scripts to continuously validate your tenant against your baseline.
- **Native Alternative:** Leverage Microsoft's new **Unified Tenant Configuration Management (UTCM)** APIs to capture snapshots and automatically monitor for configuration drift natively via Microsoft Graph.

### Restrict Device Enrollment

Limit who can join or register devices to Entra ID to prevent an attacker from enrolling a rogue virtual machine to bypass your device compliance rules.

### Configure Break-Glass Accounts

Exclude at least two highly monitored, cloud-only emergency access accounts from these CAPs to prevent tenant lockout during a Conditional Access misconfiguration. Secure them with physical **FIDO2 Security Keys**, which continue to function seamlessly even during a total Microsoft MFA (telephony/push) service outage.

### Strict Identity Separation

Strictly separate admin and user accounts. Keep admin accounts cloud-only and never sync them from on-premises directories.

### Just-In-Time Escalation

Use **Privileged Identity Management (PIM)** for just-in-time access, enforcing active justification and strict activation time limits.

_What else are you seeing get missed out in the wild? Let's talk in the comments below._

---
# TITLE: The False Security of Browser Password Managers
## Date: 2026-03-09
## Excerpt: Built-in browser password managers solve the basic password reuse problem, but they fail completely in the face of modern endpoint compromise and infostealer malware.

This headline reads like it was sponsored by Lumma, Redline, and Raccoon Stealer.

The author's intent is clearly good. Getting users to adopt built-in tools is vastly better than watching them reuse the same weak password across fifty sites. Moving the needle on basic hygiene matters.

But the practical outcome of this advice is a gift to commodity malware operators. Advising people to ditch dedicated password managers ignores how modern credential theft actually works. Browsers are the primary target for infostealers, and relying on them for credential storage introduces a fundamental architectural risk.

## Why Built-In Managers Fail the Endpoint Compromise Threat Model

Here is why built-in OS and browser managers are not a replacement for a dedicated vault:

• **The Execution Context Problem**: Browsers natively rely on the OS to handle encryption (like DPAPI on Windows). If a user executes an infostealer payload, that malware runs in the user's context. It simply asks the OS to decrypt the local SQLite database, and the OS complies.

• **The Failure of App-Bound Encryption**: Google recently tried to fix this in Chrome by introducing App-Bound Encryption, binding the decryption key to the Chrome application identity. It took infostealer developers less than two months to bypass it using COM hijacking and remote debugging exploitation.

• **The Independent Encryption Boundary**: Dedicated vaults maintain their own encryption boundary. The vault on disk is encrypted using a key derived from a master password. Is this foolproof? No. An active keylogger or memory scraper can still dump an unlocked vault from RAM. But the vast majority of commodity stealer logs are generated via smash-and-grab SQLite extraction. Moving credentials to an independent vault forces attackers to use active monitoring, drastically raising their required effort.

Built-in tools solve the password reuse problem, but they fail the endpoint compromise threat model. We need to stop telling the public that foundational security tools are obsolete just because OS vendors bundled a basic alternative.

---
# TITLE: The Entropy Illusion: LLMs and Passwords
## Date: 2026-03-03
## Excerpt: The Entropy Illusion: LLMs and Passwords

Because of how LLMs are engineered, raw randomness is actually against their core architecture. Here's why AI-generated passwords fail basic entropy tests, the "looks secure" trap of tokenization bias, and how you can use a sandbox workaround to force an LLM to delegate true, mathematically sound entropy.

The baseline rule: Use them to write the code, not the password.

The Register recently confirmed what most of us already knew: LLMs are terrible at generating secure passwords. Researchers found that major models consistently fail basic 16-character entropy tests.

Instead of rehashing how they fail, I ran an experiment to see if I could force one to succeed anyway.

The reality is you can use an LLM to get a mathematically secure passphrase. **You just have to stop asking it for the string directly.**

### Why LLMs Fail at Raw Randomness

We know that asking an LLM to simply output a random password fails due to its base architecture:

- **Tokenization bias:** Models do not generate characters. They pull from a token vocabulary based on what their training data suggests a "strong password" looks like.
- **Predictive optimization:** LLMs are prediction engines built to minimize chaos. Asking them for raw entropy is asking them to work against their core function.
- **Human expectation:** Models generate outputs that "look" secure to humans (like substituting vowels for numbers) but are highly predictable to an offline cracking rig running Hashcat.

**The "Looks Strong" Trap**

During recent research, a generated string like G7$kL9#mQ2&xP4!w was tested. While standard strength tools like zxcvbn estimate it would take "centuries" to crack based on simple length and character-class heuristics, its tokenized origin dramatically narrows the real search space for offline brute-forcing tools.

### Delegating the Entropy

To actually get a secure passphrase from an LLM, you have to force it to delegate the entropy. I gave a model a simple prompt: _write a script using the EFF Large Wordlist to generate a 4-word passphrase (mirroring the useapassphrase default)._ I didn't specify the language or the library.

The model chose Python and the OS-level secrets module (a true CSPRNG). Then, it pushed back. It pointed out that 4 words only yield \approx 51 bits of entropy and practically begged me to let it use 6 words to hit a mathematically secure 77.5-bit threshold. I let it run the 6-word version.

The result was mathematically sound because the OS provided the randomness, not the LLM's softmax distribution.

The script even generated consecutive duplicate words ("slushy slushy"). This is a classic Birthday Paradox artifact. While it doesn't definitively prove true randomness, it is solid evidence that the generator didn't fall into the human-bias trap of artificially preventing repetition. That "random-looking" bias actually weakens the keyspace.

### The Sandbox Precedent

We have already seen how AI providers solve this kind of architectural flaw. If you ask a modern LLM to do complex math, it doesn't try to predict the next token. It silently writes a Python script, executes it in a sandbox, and feeds the output back to you.

My prediction is that it is only a matter of time before models treat "give me a password" the exact same way. System prompts will detect the request and route it to a script exactly like this one, returning true OS-level entropy instead of a token hallucination.

But even when they do, the baseline rule remains: **you shouldn't trust an LLM to generate your secure passwords or secrets.** People will undoubtedly continue to ask for them anyway, but the right approach hasn't changed.

> **Use them to write the code (and human-validate it), not the password**

---
# TITLE: 'Silo' Author Hugh Howey Was Pro-Piracy, Predicted AI Collaboration in 2016, and Ended Up in Anthropic's Copyright Settlement
## Date: 2026-02-11
## Excerpt: Long before ChatGPT, Silo author Hugh Howey predicted writers would collaborate with AI as creative partners. He'd already built a career on similar bets: welcoming piracy over obscurity, pricing ebooks at $0.99 against industry norms. Now his work is part of Anthropic's $1.5 billion copyright settlement. A look at whether that's a reversal, or the same principle he's held all along. 

I’ve read Hugh Howey since before Wool had a Simon & Schuster logo on the spine. I watched him put a "Pro-Piracy" button on his own website while publishers were suing teenagers over Napster. I watched him price ebooks at $0.99 while the industry called it reckless. I watched him predict, in 2016, that writers would one day sit down with a writing program and co-author a book with it, and then watched that prediction land almost exactly on schedule.

So when Howey's books ended up part of a $1.5 billion copyright settlement with Anthropic, it's worth asking how that squares with a guy who has spent fifteen years telling creators to stop fighting technological disruption. On the surface those two things look like they pull in opposite directions. Worth actually working through rather than leaving unresolved.

I don't think they pull in opposite directions at all. I think the two ideas can live together comfortably once you look at what his principle actually was the whole time, starting with that piracy stance most people have never heard of.

## A Detail Most People Don't Know About Him

Most readers have never heard about the "Pro-Piracy" button Howey once put on his own website. It's an obscure footnote from early in his career, not something that made headlines, which is probably why it's easy to misread if it comes up at all. So it's worth being precise about what it actually meant, because the nuance matters for everything that follows.

Howey was never defending piracy in general. He was defending a reader downloading a free copy for personal use, not a bootlegger selling pirated files for profit. Those are not the same act wearing different clothes. One is a person who wasn't going to pay full price anyway, getting exposed to a book, maybe becoming a fan, maybe buying the next one. The other is someone building a commercial operation on the back of a stranger's unpaid labor.

Howey's actual bet was that the first kind of piracy was a rounding error next to obscurity, and that fighting it with DRM and lawsuits punished legitimate readers far more than it stopped anyone determined to steal. But he was never on record saying it's fine for someone to run a storefront selling his books without paying him. That's not a friction he ever asked to have removed. That's the exact thing the Anthropic settlement was about: a company building a commercial product on his and thousands of other authors' pirated work.

## Same Logic, Applied to Pricing

The $0.99 ebook fight fits the same shape. Howey's argument wasn't "books should be free." It was that publishers were protecting an artificial price floor that served their margins more than it served either readers or authors. He still got paid. Readers still paid. The friction he attacked was the markup, not the transaction. Nobody was extracting value from his work without compensating him. The disagreement was purely about how much friction should sit between a reader's interest and a completed sale.

## The Centaur Prediction, Reread

In 2016, Howey made the following prediction:

> One day, I will sit down with my writing program, give the barest of prompts, and the computer will spit out rough prose for me to revise... Or I will write, ask for a prompt, and get a suggestion in return. We will co-author the work. Neither of us could have written the final piece alone.

Notice what's not in that picture: a company selling access to a model that had silently ingested his backlist without permission or payment, then charging users a subscription to produce competing fiction. The Centaur was always framed as a personal tool a writer chooses to use, not a commercial product built on uncompensated raw material. He predicted the collaboration. He didn't predict, or endorse, the acquisition method.

## So What's the Actual Principle?

Line them up and a pattern holds across all three positions, cleanly, with no revision required.

- Personal, non-commercial use of someone's work is fine, even worth encouraging, because the harm is negligible and the goodwill is real.
- Commercial exploitation of someone's work without paying them is not fine, whether it's a bootlegger, a publisher protecting an inflated price floor at the reader's expense, or a company selling access to a model trained on unlicensed prose.

That's one rule, not two. The common thread is opposition to unpaid commercial extraction, wherever it shows up. A bootlegger selling pirated files, a publisher protecting an inflated price floor at the reader's expense, a company selling access to a model trained on unlicensed prose. Different eras, different technologies, same target. He just never got asked, until now, to weigh in on a version of it aimed at him.

Read this way, the settlement isn't Howey abandoning his principles under pressure from personal interest. It's the same rule he's applied since 2011, reaching a new category of actor he hadn't previously had reason to think about.

The settlement itself actually drew a version of this same line. The court ruled that training Claude on legally acquired books was fair use and transformative, but that Anthropic downloading pirated copies from shadow libraries like LibGen to get some of that training data was not fair use, which is what the $1.5 billion payout covers. The distinction the court landed on wasn't training versus output. It was legitimate acquisition versus piracy. That's not exactly Howey's line, and it's not exactly mine either, but it confirms this isn't an all-or-nothing debate. There are several defensible places to draw it, and reasonable people, including judges, land in different spots.

## Where I Actually Disagree With Him

Here's where I part ways, not on the principle, but on how it applies to model training specifically.

I think ingestion is fair use. Training a model on publicly available text is a transformative, non-expressive act, closer to an art student walking through a gallery to absorb style and technique than to a bootlegger photocopying a book to resell. The model isn't storing or redistributing a copy of Wool. It's extracting statistical patterns about how sentences work, the same way any reader does just by reading widely, except at a scale no individual reader could manage. Blocking that phase of machine learning doesn't just slow down a few companies. It breaks the basic mechanism by which the technology works at all.

Where I think copyright enforcement should actually bite is at the output. If a model reproduces a verbatim or substantially similar passage of a protected work, that's the violation, and it's the same violation whether a human or a machine produced it. The finish line is where the harm becomes concrete. Everything upstream of that is a process, not a product.

Howey's position, as best I can tell, draws the line earlier, treating the act of training itself as the commercial exploitation, regardless of what the model later outputs, because the company is selling access to something whose capability was built from unlicensed material. Under his read, the art student analogy breaks down the moment the student starts charging tuition based on what they learned in a gallery they never paid to enter.

I don't think that framing survives contact with how learning, human or machine, actually works. But I'll say this for him. It's not a contradiction of anything he's argued before. It's the same rule he's held since the Pro-Piracy button, aimed for the first time at a target he didn't see coming when he wrote it. The interesting question was never whether Howey changed his mind. It's whether training a model is closer to reading, or closer to reselling.

---
# TITLE: Claiming Your Digital Seats: Accounts To Occupy
## Date: 2026-02-04
## Excerpt: Freezing your credit is only half the battle. Your records at the IRS, SSA, and USPS already exist in databases, waiting to be claimed. If you don't register these accounts first, adversaries will. Here are the three critical digital 'seats' you must occupy immediately to secure your identity. 

The data exists. The login is up for grabs.

Freezing credit is foundational, but it’s purely defensive. It ignores the other side of the problem: **the accounts that are already open and waiting to be claimed. **

For critical services like the IRS, SSA, or USPS, your record is already in the database. The portal to access it is live. By creating the account, we are claiming access to an existing identity.

Think of these records as **empty seats at a table.**

If you don’t register for the portal, that seat sits empty. The first person to sit down (whether that is you or an adversary) controls the account. If you leave it vacant, you are waiting for someone else to walk in, sit down, and lock you out.

I view claiming these seats not as admin work, but as a **critical security upgrade**. You are replacing weak security (static data and blind trust) with active defenses (monitoring and passkeys).

## The Three Seats to Occupy Immediately

Here are the three seats I prioritize occupying immediately to secure your digital footprint:

### 1. USPS Informed Delivery

You usually don't know a letter was stolen because you didn't know it was coming in the first place. Informed Delivery fixes this by emailing you scans of your incoming envelopes every morning.

It gives you visibility. If the digital image shows a tax document or a replacement credit card that never physically arrives in your mailbox, you know immediately that something is wrong.

### 2. IRS.gov

This account controls access to your tax transcripts and filing history. Leaving it unclaimed invites tax refund fraud. Claiming it lets you lock the front door with passkeys, ensuring that even if someone has your SSN, they can't get in.

- **Identity Protection PIN (IP PIN)**: Once you are logged in, be sure to generate an IP PIN. This acts as a mandatory 6-digit "password" for your tax return, guaranteeing that any filing submitted without it gets rejected on the spot.

### 3. SSA.gov (Social Security)

Legacy SSA logins were officially retired in 2025. You now must use _ID.me_ or _Login.gov_. If you don't establish this link, an attacker can do it for you. Secure this account with passkeys.

## Defensive Freezes vs. Active Claims

Freezing credit stops new accounts from being created. Filling these empty seats secures the accounts that effectively **already exist**. Don't leave them vacant.

---
# TITLE: Starkiller: The Rise of Weaponized Remote Browsers in Phishing-as-a-Service
## Date: 2026-01-25
## Excerpt: Weaponized Remote Browsers like 'Starkiller' represent a dangerous evolution in Phishing-as-a-Service (PhaaS). By spinning up headless Chromium containers for each victim, they bypass traditional device recognition and legacy OTPs. Here is how they work and how to configure phishing-resistant defenses. 

We are seeing a new evolution in phishing architecture. For years, the foundational technology for MFA bypass has been the Go-based reverse proxy framework (like Evilginx or _Modlishka_). Those open-source tools eventually spawned a massive, competitive commercial ecosystem of Phishing-as-a-Service (PhaaS) platforms. Kits like EvilProxy, W3LL, and Tycoon commoditized AiTM (Adversary-in-the-Middle) attacks for the masses.

But recent intelligence on a new PhaaS platform called **"Starkiller"** (sold by a group calling itself **Jinkusu**) points to a heavier, highly automated addition to the adversary toolkit: **Weaponized Remote Browsers.**

## The Architecture

Most modern phishing kits abandoned static HTML templates years ago in favor of reverse proxies that rewrite traffic at the protocol level, forwarding raw HTTP requests and responses between victim and legitimate site. Starkiller is still architecturally an AiTM reverse proxy: it forwards victim inputs to the real site and returns real responses. It just implements that proxy at a different layer.

**Instead of parsing and rewriting HTTP traffic, it spins up a dedicated, headless Chromium instance inside a Docker container for every victim**, and that browser instance itself loads and executes the real site. The victim's inputs are relayed into this container; the container's rendered output is relayed back. Functionally it's the same AiTM position as Evilginx, but the implementation is a full browser engine rather than a traffic parser.

That distinction matters because of what it changes on the fingerprinting side. In protocol-rewriting proxies, the victim's actual browser still executes the target site's JavaScript, so client-side fingerprinting signals (canvas rendering, WebGL, installed fonts, User-Agent) still originate from the real device unless the operator specifically strips them. In Starkiller's model, the headless Chromium container executes that JavaScript itself. Every fingerprinting signal the IdP collects, not just network-layer ones like source IP, comes from the same attacker-controlled Docker image, consistently, across every victim. That's the real step-change from Evilginx-class tooling: it doesn't just relay credentials, it interposes a browser between the victim and every client-side signal the IdP might use for device recognition.

## Automated Delivery at Scale

Starkiller is built for scale and distributed like a SaaS product, automating Docker engine status, image builds, and container scaling entirely.

For delivery, it relies heavily on email. To hide the malicious destination, operators use a built-in URL Masker that abuses the classic `@` symbol basic-authentication syntax combined with URL shorteners. The kit also includes an email-harvesting capability that scrapes contact lists from compromised sessions to automatically build target lists for the next wave of internal phishing.

Two details worth tracking as the kit matures: recent versions (v6.2.4+) have added OTP and recovery-code capture along with bot/scanner fingerprinting to filter out automated analysis. This is an actively iterating platform, not a static tool. Marketing materials also advertise financial-fraud modules (credit card capture, crypto wallet seed theft, bank credentials) and fake browser-update payload templates, so the blast radius extends beyond corporate credential/session theft into direct financial fraud.

One more point worth stating explicitly for less technical audiences: because the proxy domain is a real, attacker-registered domain, it gets its own valid TLS certificate. "Check for the padlock" or "check the certificate" guidance does nothing here: the cert is legitimate for the phishing domain, just not for the brand being impersonated.

## The Hardware Key Reality

Marketing materials for these kits claim they can bypass hardware keys "when proxied." This is technically misleading. **You cannot proxy a Passkey or FIDO2 interaction over this setup** because Passkeys are cryptographically bound to the origin domain.

What they are actually exploiting is **Legacy OTP**. If your YubiKey is configured to spit out a text string (the `cccccc...` output), that is just keystrokes, and keystrokes can be relayed in real time. This tool destroys SMS, TOTP, and Legacy OTP, but it fails against proper FIDO2/WebAuthn.

## The Fixes

To defend against this next wave of phishing architecture, organizations must enforce technical controls rather than relying on human detection:

- **Enforce Passkeys**: This is the strongest architectural defense available. Because Passkeys rely on origin binding, they fundamentally break the AiTM model regardless of whether the proxy is protocol-based or browser-based. The attacker's container cannot trick your device into signing a request for a domain you aren't physically visiting. _Note: You must enforce Passkeys as the only method; leaving them optional leaves the door wide open._
- **Stop Accepting Legacy OTPs**: The flaw exists entirely within the IdP configuration. If your IdP still accepts the "Yubico OTP" text string (the `cccccc...` output) for authentication, you are phishable. If you configure your IdP to only accept FIDO2/WebAuthn, the door is locked.
- **Device Trust**: Since the browser is actually running inside the attacker's Docker container, it lacks your managed device certificate. Enforcing mTLS/Device Compliance at the IdP level acts as a major roadblock (though bypasses are eventually found here).
- **Training is Insufficient**: Between the URL masker hiding the true domain, a legitimately-issued certificate on that domain, and visual fidelity that's a perfect live match of the real site, we have to be realistic. Even well-trained experts can slip. We need technical controls that do not rely on human perception.

---
# TITLE: The Homograph Mirage: Why Hovering Over Links is Bad Security Advice
## Date: 2026-01-14
## Excerpt: Telling users to spot lookalike Unicode domains (IDN Homograph attacks) by hovering over links is outdated and ineffective advice. Modern browsers solved this years ago by displaying the raw Punycode. Here is why we should rely on browser engineering rather than visual eye tests.

This kind of "spot the difference" advice is making the rounds again.

It is well-intentioned, but it ignores almost a decade of browser engineering.

The screenshot warns about **IDN Homograph attacks**—where an attacker uses lookalike characters (like a Cyrillic "o") to spoof a domain like `google.com`.

The advice is to "stay sharp" and "hover over links."

Here is why that is bad advice:

### 1. The Human Parser is Defective

You cannot ask users to spot pixel-level differences in fonts. That is a failed security strategy. Human eyes are not compilers, and expecting them to catch micro-visual discrepancies on a mobile screen is unrealistic.

### 2. The Browser Already Solved This

You don't have to spot the difference. Browser vendors largely solved this issue years ago.

If you actually click that "fake" link in any modern browser (Chrome, Edge, Safari, Firefox), the browser detects the mixed-script character set. It sees you are an English-locale user trying to visit a domain mixing Latin and Cyrillic characters.

The browser immediately strips the disguise and renders the raw **Punycode** in the address bar.

So instead of `google.com`, the user sees:

```text
xn--gogle-6xd.com
```

## Where the Illusion Persists

The risk today is mostly in "unmanaged" rendering surfaces like **SMS**, **Slack**, or **social media link previews**. These apps prioritize typography over security policy, so the spoof looks real.

But once the user actually clicks, the browser usually kills the illusion immediately.

## Technical Defenses, Not Eye Tests

We need to stop telling users that security is a game of **"I Spy"** they have to win every single time. It is an engineering problem, and fortunately, the browser engineers are winning.

---
# TITLE: The Performance Cost of Telemetry: Why Your Smart TV is Lagging
## Date: 2026-01-04
## Excerpt: Privacy fatigue often leads to a passive acceptance of background tracking. But surveillance isn't free—it costs CPU cycles and RAM. On underpowered Smart TVs, default Automatic Content Recognition (ACR) settings actively degrade interface performance. Here is how to disable the telemetry scrape and reclaim a responsive UI. 

I often hear people express **"Privacy Nihilism"**—the idea that their data is already exposed, so why bother securing the rest? While I understand the fatigue, there is a tangible cost to this apathy beyond just abstract privacy: **Performance. **

Surveillance costs compute.

If your Smart TV feels sluggish or the user interface is lagging, it is likely a resource contention issue. These devices run on underpowered processors with limited RAM. When you leave default privacy settings enabled—specifically **Automatic Content Recognition (ACR)**—you are forcing that constrained hardware to actively sample pixels and upload fingerprints in the background.

You are effectively spending your CPU cycles on telemetry rather than the user interface.

## Reclaiming Your CPU Cycles

To reclaim your device's performance, prioritize these two actions immediately:

### 1. Stop the Scrape (Disable ACR)

Go to your TV's **Settings > Privacy** (often hidden under options like _"Viewing Data"_, _"Viewing Information Services"_, or _"Smart Interactivity"_) and disable ACR.

This stops the background service from taking screenshots, analyzing display frame buffers, and negotiating network handshakes while you watch.

### 2. Flush the Cache (Cold Boot)

TV operating systems (like Tizen, webOS, or Android TV) are notoriously bad at memory management. Over time, memory leaks pile up.

If the UI remains laggy after disabling telemetry, the system needs a reboot. Don't just press the remote's power button (which usually just puts the TV to sleep). **Pull the physical power cord for 60 seconds** to drain the capacitors and force a clean, cold boot.

## Lag is the Reality

Privacy is abstract, but menu lag is reality. Fix the settings to fix the lag.

---
# END OF DOCUMENT