Pasindu Pramodya

TanStack npm Supply Chain Attack: What Happened and What Engineers Should Do

Wed, 13 May 2026 00:00:00 GMT

Cover image source: lexica.art

A coordinated supply chain attack published malicious versions of over 170 npm packages and 2 PyPI packages on May 11–12, 2026, hitting organizations including TanStack, Mistral AI, UiPath, and OpenSearch. The campaign, tracked as "mini-shai-hulud" by StepSecurity and Socket Security is one of the largest registry poisoning events observed in 2026 and the first to span both npm and PyPI in a single operation.

What Happened

SafeDep's malware detection pipeline flagged a burst of suspicious npm package publications on the night of May 11, 2026. Unlike previous supply chain attacks that targeted a single high-value package, this campaign went after entire organizational scopes. Every package under @tanstack, @squawk, @uipath, @tallyui, and other namespaces was published with malicious versions in a single coordinated push.

The same actor then expanded to PyPI on May 12, 2026, publishing malicious versions of the official Mistral AI Python SDK (mistralai==2.4.6) and the Guardrails AI validation framework (guardrails-ai==0.10.1). PyPI quarantined both projects. No legitimate v2.4.6 tag exists in the mistralai/client-python repository - the attacker created a version that never existed in the upstream source.

TanStack published a postmortem explaining the initial compromise path, a chained GitHub Actions attack using the pull_request_target "Pwn Request" pattern, GitHub Actions cache poisoning across the fork-to-base trust boundary, and runtime memory extraction of an OIDC token from the GitHub Actions runner process. The malicious publishes were authenticated through the project's OIDC trusted-publisher binding after attacker-controlled code ran during the workflow's test/cleanup phase and posted directly to the npm registry. TanStack stated that no npm tokens were stolen and that the npm publish workflow itself was not compromised.

Timeline

May 11, 2026 (nighttime UTC): SafeDep detects suspicious npm package publications across multiple scopes. Socket flags 84 compromised TanStack npm package artifacts.
May 12, 2026 (~03:05 UTC): Campaign expands to PyPI. mistralai==2.4.6 and guardrails-ai==0.10.1 published. Cloudflare marks git-tanstack[.]com as a suspected phishing site.
May 12, 2026: npm removes malicious tarballs. TanStack deprecates affected versions, purges GitHub Actions cache entries, and merges hardening changes to the affected workflow.
Patched versions published across affected packages (see below).

How the Attack Worked

The GitHub Actions Compromise Chain

TanStack's postmortem attributes the initial access to a combination of three GitHub Actions misconfiguration patterns:

pull_request_target - This workflow trigger makes the base repository's workflow code available to pull request authors. When combined with cache poisoning, it allows an attacker controlling a fork to influence trusted pipeline behavior.
GitHub Actions cache poisoning - Attackers injected malicious content into the shared workflow cache, which was later loaded by the base repository's CI pipeline.
OIDC token memory extraction - After attacker controlled code ran in the workflow, it extracted the GitHub Actions runner's OIDC token from process memory. That token was used to authenticate publishes directly to the npm registry via the project's OIDC trusted-publisher binding, bypassing the need for a static npm token entirely.

This is a significant escalation from traditional npm token theft. The attacker did not steal a stored npm API token, they stole a dynamically issued OIDC token that the CI system itself used to prove its identity to the registry.

The Malicious Payload

The npm packages received an added router_init.js file - a ~2.3 MB heavily obfuscated file using javascript-obfuscator patterns (string-array rotation, hex-encoded identifier lookups, control-flow flattening inside while(!![]){} state machines, dead-code injection). This is distinct from normal minifier output from Terser, esbuild, or swc.

The file spawns a daemonized process that:

Reads and exfiltrates GITHUB_* environment variables (GitHub Actions secrets, tokens, actor identity)
Probes http://169.254.169.254/latest/meta-data/iam/security-credentials/ (AWS metadata service)
Probes http://127.0.0.1:8200 (HashiCorp Vault)
Downloads a platform-specific Bun runtime from hxxps://github[.]com/oven-sh/bun/releases/download/bun-v1.3.13/
Downloads the main payload from hxxps://git-tanstack[.]com/transformers.pyz
Communicates with hxxp://filev2[.]getsession[.]org/file/ as the command-and-control server

The package.json was also modified to include:

"optionalDependencies": {
  "@tanstack/setup": "github:tanstack/router#79ac49eedf774dd4b0cfa308722bc463cfe5885c"
}

That commit (79ac49eedf774dd4b0cfa308722bc463cfe5885c) is a root commit with no parent history that introduces only a package.json and bundled tanstack_runner.js payload. The prepare lifecycle hook runs bun run tanstack_runner.js && exit 1, executing arbitrary code during installation of the git-based dependency. Even before the package is fully installed in a project.

PyPI Payload Difference

The PyPI packages use a different delivery mechanism. On import, a Python dropper downloads transformers.pyz from hxxps://git-tanstack[.]com/transformers.pyz and executes it with python3. This is the same attacker-controlled domain used in the npm campaign, confirming the same infrastructure.

Who Is Affected

The attack hit over 170 npm packages across multiple organizations. The major affected packages include:

Package	Downloads	Risk
`@tanstack/react-router`	3M+ weekly	CI credential theft
`@tanstack/vue-router`	Widely used	CI credential theft
`@opensearch-project/opensearch`	1.3M weekly	CI credential theft
`@uipath/robot`	Enterprise RPA	Credential theft
`@mistralai/mistralai` (npm)	SDK consumers	Credential theft
`mistralai` (PyPI)	Python SDK	Credential theft
`guardrails-ai` (PyPI)	ML validation	Credential theft

Patched versions have been published for all affected packages. TanStack's security advisory lists specific affected and patched versions per package.

What Engineers Should Do Now

1. Identify affected installations

Check your dependency tree for router_init.js files. Socket published the following SHA-256 for detection:

ab4fcadaec49c03278063dd269ea5eef82d24f2124a8e15d7b90f2fa8601266c

Run:

find . -name "router_init.js" -exec shasum -a 256 {} \;

2. Rotate all exposed secrets

If you installed any affected @tanstack/* version between May 11–12, 2026, rotate the following immediately in priority order:

GitHub PATs and OIDC federation grants - especially any trusts used for npm publishing
npm tokens - all active publishing tokens, even if TanStack claims none were stolen directly
AWS credentials - static keys and instance role tokens (the payload probes the EC2 metadata service)
Vault tokens - the payload probes localhost:8200
SSH keys - if any were present in the CI environment

3. Revoke GitHub Actions OIDC trust

The attack extracted OIDC tokens from GitHub Actions runner memory. If your organization uses OIDC trusted publishers for npm or other registry publishing, review and rotate those federation grants.

4. Pin and audit dependencies

Audit package.json for unexpected optionalDependencies referencing git URLs, especially GitHub commits that aren't part of your normal dependency graph
Audit your lockfile for newly added transitive dependencies you didn't expect
Consider pinning @tanstack/* to specific versions rather than semver ranges during this period

5. Review CI logs

Check your GitHub Actions logs for any unusual behavior between May 11–12: unexpected network calls, spawning of unfamiliar processes, or access to secrets outside normal workflow steps.

6. Enable supply chain protections

The pnpm 11 release (May 4, 2026) introduced defaults specifically aimed at the conditions this attack exploited:

Minimum Release Age (24h default): Newly published package versions are not resolved until they are at least one day old, reducing exposure during the highest-risk window immediately after publication
Block Exotic Subdeps (on by default): Prevents transitive dependencies from resolving from git repositories or direct tarball URLs, narrowing one path attackers use to hide unexpected code

If you use pnpm, upgrading to v11 and keeping the defaults on significantly reduces the risk of fast-moving supply chain attacks succeeding silently.

For npm and Yarn users, similar protections exist via Socket's AI Scanner and SafeDep's Package Manager Guard.

What Is Still Unknown

Initial access vector - TanStack's postmortem describes the GitHub Actions exploitation chain but has not yet published the full root-cause analysis of how the attacker first compromised the voicproducoes GitHub account (the account used for the malicious commit)
Number of affected organizations - neither npm nor TanStack have published estimates of how many projects consumed the malicious versions
Exploitation status - I found no confirmed public evidence of active exploitation of stolen credentials as of May 13, 2026, but the credential-stealing payload was live in the registry for hours before removal, and the blast radius of OIDC token theft can extend beyond the immediate publisher
Full scope beyond npm/PyPI - StepSecurity's tracking suggests the campaign also hit Packagist (PHP), though details are still emerging

References

SafeDep: Mass Supply Chain Attack Hits TanStack, Mistral AI npm and PyPI Packages — Primary detection source, full technical analysis including PyPI expansion
Socket Security: TanStack npm Packages Compromised in Ongoing Mini Shai-Hulud Supply-Chain Attack — Payload analysis, IoC details, recommended actions
GitHub Security Advisory: Malware in 42 @tanstack/* packages exfiltrates cloud credentials, GitHub tokens, and SSH keys (GHSA-g7cv-rxg3-hmpx) — Official advisory with affected/patched versions
Socket Security: pnpm 11 Adds Supply Chain Protection Defaults — Context on how package managers are hardening against these attacks

Why Sekiro: Shadows Die Twice Has the Best Combat System in Modern Gaming

Mon, 27 Apr 2026 00:00:00 GMT

Cover image source: alphacoders.com

:::note Sekiro: Shadows Die Twice revolutionized action game combat by replacing traditional health focused systems with a posture-based mechanic that emphasizes aggression, precision, and rhythm over dodging and stamina management. Its combat system transforms every encounter into a high-stakes sword duel where mastery comes from player skill rather than character stats, creating some of the most memorable and emotionally resonant boss fights in gaming history. :::

The Moment Sekiro Clicks

The first time I heard steel ring against steel atop Ashina Castle, I didn’t feel triumph.I felt panic. Genichiro Ashina stood before me, sword lowered, eyes locked, and every instinct screamed to back away, to create space, to think. But in Sekiro, backing away is often the worst thing you can do. I blocked his thrust, felt the shudder in my arms, and realized too late that I’d been thinking in Dark Souls terms: shield up, wait for an opening, punish. Sekiro doesn’t work that way.

As his combo came, a horizontal slash followed by a thrust,I tried to deflect, but my timing was off. The slash connected, breaking my posture. Before I could recover, the thrust pierced my guard. Death blinked red on the screen. I sighed, muttered “Hesitation is defeat” and tried again.

This moment, Dying not because I was weak, but because I was thinking wrong.This where Sekiro begins to teach. The game frustrates players initially because it demands a complete inversion of what many action games have trained us to do. For years, we’ve been taught that safety lies in distance, that blocking creates opportunity, that the best defense is a patient wait. Sekiro says: get close, stay aggressive, and let your deflection be your shield.

What makes this shift so profound is how it transforms combat from a statistical exercise into a rhythmic conversation. Health bars matter, yes, but they’re secondary to the yellow posture bar that pulses above each enemy’s head. Every blocked attack chips away at your own posture.Every successful deflection builds theirs. Victory isn’t about whittling down health through attrition.It’s about breaking their posture through perfectly timed aggression, leaving them open for a deathblow that ends the fight in a single, satisfying strike.

The phrase “Hesitation is defeat” isn’t just a meme. It’s a combat principle etched into every encounter. When you hesitate, you lose the initiative, you let the enemy dictate the pace, and you give them chances to break your posture. When you act, when you lean into the fight, trust your timing, and press forward, you take control. Sekiro doesn’t reward brute force or overleveling. It rewards the player who learns to read the flow of combat, to anticipate rather than react, and to find courage in the split second between an attack’s start and its impact.

:::important[Opinion] The genius of Sekiro’s combat lies in how it makes mastery feel personal. There are no hidden stat checks, no gear walls to grind past. When you finally defeat Genichiro or any boss, It’s not because your numbers were high enough. It’s because you were good enough. :::

Why Sekiro Feels Different From Other Action Games

What immediately strikes players transitioning to Sekiro from other action games, even other FromSoftware titles is how fundamentally different the combat feels. It’s not just that the moves are different, the entire philosophy underlying combat has shifted. Sekiro doesn’t merely tweak familiar systems. It replaces core assumptions with a new rhythm that rewards aggression, precision, and split-second timing over statistical optimization or defensive patience.

Consider the evolution from Dark Souls to Sekiro. In Dark Souls, combat often feels like a deliberate, methodical exchange, raise shield, block an attack, look for an opening in the enemy’s animation, punish with a well timed strike. The shield is your constant companion, a safety net that allows for reactive play. Mistakes are often recoverable, you can back up, reset, and try again. Build variety lets players compensate for mechanical shortcomings with high vitality, heavy armor, or powerful magic.

Sekiro removes that safety net. There is no shield to hide behind. Blocking with your sword still incurs posture damage, meaning that pure defense is a losing strategy over time. The game doesn’t just encourage aggression.It requires it. Where Dark Souls might let you win through attrition or overleveling, Sekiro demands that you improve your mechanical skill. There are no hidden stat checks to grind past. When you finally overcome a difficult encounter, it’s because you’ve gotten better, not because your numbers are higher.

This shift manifests in several concrete ways. First, the combat pace is fundamentally faster and more immediate. Enemies attack with less telegraphing and more combo variety than in most Soulsborne games, forcing players to stay engaged rather than falling back into defensive postures. Second, the removal of traditional RPG build variety means that character progression takes a backseat to player progression. You don’t equip heavier armor to take more hits, you learn to take fewer hits through better deflection timing. Third, Sekiro’s combat emphasizes rhythm over reaction. Successful play feels less like reacting to individual stimuli and more like falling into a flow state where anticipation and execution blend together.

:::tip The removal of build variety isn’t a limitation.It’s a design choice that focuses player improvement squarely on mechanical skill. In Sekiro, there’s no “I’ll just grind a few more levels” escape hatch. When you hit a wall, the game is honestly telling you, your timing needs work, your aggression is mistimed, your pattern recognition is lagging. This honesty is what makes victories feel so earned.

When you finally beat a boss like Sword Saint Isshin, it’s not because you found the right talisman or upgraded your weapon enough. It’s because you learned to read his attacks, to deflect with perfect timing, and to maintain the aggression needed to break his posture. The victory belongs to you, not your character sheet. :::

:::important Sekiro’s combat pace deserves special mention. Unlike the bursty, stamina-managed combat of Nioh or the hit-trading of Dark Souls, Sekiro creates what players often describe as a “rhythm game with swords.” The constant back-and-forth of deflection and counter-deflection, the ebb and flow of posture bars rising and falling, creates a musical quality to combat. Mastery comes not just from learning individual patterns but from internalizing the rhythm of each encounter, knowing when to press, when to yield for a split second, and when to unleash a combo that will shatter the enemy’s posture. :::

The Core Combat Loop: Posture, Deflection, and Pressure

At the heart of Sekiro’s combat lies a deceptively simple relationship between two vital statistics, health and posture. Health represents your survivability, the raw amount of damage you can take before dying. Posture, however, represents your balance and readiness, the staggered state that leaves you open to a deathblow. Most players enter Sekiro focusing on health bars, only to learn that posture is the true currency of combat.

Imagine each exchange as a tug-of-war over posture. When you attack an enemy, you deal two types of damage simultaneously. A small amount to their health bar (red) and a larger amount to their posture bar (yellow). When you successfully deflect an attack, you take minimal posture damage yourself while dealing significant posture damage to the attacker. The goal isn’t to whittle down health through attrition.It’s to break the enemy’s posture through perfectly timed aggression, leaving them vulnerable to a deathblow that often ends the fight in one decisive strike.

This creates a fascinating dynamic where aggression and defense are intertwined. Backing away after blocking an attack might feel safe, but it does little to advance the posture tug-of-war in your favor. Instead, Sekiro rewards players who stay close, who pressure after a deflection, and who understand that the best defense often involves committing to an offensive rhythm.

Consider a duel with Genichiro Ashina, the game’s early gateway boss. His sword attacks come in predictable yet threatening combinations, a horizontal sweep followed by a quick thrust. A novice player might block the sweep, then try to create distance before the thrust arrives. Only to find that blocking still builds posture, and the retreat gives Genichiro space to reset his offense. A player who has internalized Sekiro’s loop, however, will deflect the sweep (building Genichiro’s posture while barely affecting their own), immediately follow with an attack of their own to increase pressure, and be ready to deflect or Mikiri Counter the thrust. Each successful deflection shifts the posture balance further in their favor until, suddenly, Genichiro’s posture bar flashes red, he’s broken and a deathblow ends the duel.

Or take the fight against Sword Saint Isshin, where the pressure is relentless and the windows for action are razor thin. Isshin’s assaults rarely pause, forcing players into a constant cycle of deflect, counter, deflect, counter. Here, mastery isn’t just about individual timing, it’s about maintaining the flow. A single mistimed deflection can lead to a posture break and massive damage, but a player who stays aggressive, who uses Mikiri Counter against thrusts, and who mixes in prosthetics like the loaded axe for burst posture damage, can gradually wear down even Isshin’s formidable posture.

The “rhythm game with swords” sensation comes from this constant interplay. Successful Sekiro combat feels less like reacting to isolated stimuli and more like participating in a call-and-response, enemy attacks (the call) met with deflections and counters (the response) that shift the balance of power. Visual and auditory feedback reinforces this rhythm, the metallic clang of a perfect parry, the shower of sparks, the red kanji (隻狼) danger symbols that flash when an attack is about to break your guard, and the clear, readable animations that telegraph intent without unfairly hiding it.

:::tip Posture is more interesting than a traditional stamina bar because it creates a bidirectional flow. In stamina based systems, you spend a resource to act and recover it when resting. In Sekiro’s posture system, both you and your opponent are constantly gaining and losing posture through the same actions. Deflections build enemy posture but also yours, attacks reduce your posture gain while increasing theirs. This creates a dynamic tension where every exchange shifts the balance, and victory comes from managing that flow rather than depleting a resource. :::

Combat Tools That Expand the System

While Sekiro’s core loop of posture and deflection is elegant in its simplicity, the game layers additional systems that expand tactical depth without overwhelming the player. These tools, the prosthetic arm, combat arts, and situational techniques, are designed to complement, not replace, the fundamental skills of timing and aggression.

The prosthetic arm is Sekiro’s most iconic addition, offering a variety of tools that attach to Wolf’s left arm. Each prosthetic serves a specific situational purpose, encouraging players to experiment and adapt rather than rely on a single “best” tool. The Loaded Axe, for example, trades slower execution for massive posture damage, making it ideal for breaking stubborn defenses or punishing whiffed attacks. The Umbrella provides defensive utility, blocking projectiles and reducing posture damage from certain attacks while active. Firecrackers stun enemies, creating openings for follow-up combos or desperate escapes. Shuriken offer ranged interruption, useful for getting close to enemies or disrupting casts. The Loaded Spear provides thrust properties and can pierce defenses. Each tool consumes Spirit Emblems, a limited resource that forces thoughtful deployment rather than constant use.

Combat arts are active abilities that modify Wolf’s swordplay, often trading spirit emblems for powerful effects. Mortal Draw is a swift, high-posture-damage strike from a sheathed position, perfect for punishing openings or breaking guards. Ichimonji is a multi-hit combo that builds posture rapidly while providing some defensive coverage during its execution. Spirit Slash projects a ranged slash that can interrupt enemies or chip posture from a distance. These arts aren’t direct upgrades, they’re situational tools that shine in specific contexts. A player might equip Mortal Draw for boss fights where breaking posture is difficult, while favoring Ichimonji against faster opponents.

Beyond prosthetics and arts, Sekiro includes techniques that expand the core loop. The Mikiri Counter, arguably the most important technique in the game, allows Wolf to stop thrust attacks, avoiding damage while dealing massive posture damage to the attacker. Jump counters let Wolf evade low sweeps and retaliate with a downward strike. Situational awareness like using environmental hazards or recognizing enemy tells further separates novice play from mastery.

What’s remarkable is how these tools add depth without complicating the core loop. A new player can complete the game using almost exclusively deflection and basic attacks, while veterans might devise intricate prosthetic combos or time combat arts to maximize posture damage. The systems are optional layers, not mandatory complexity.

:::warning The temptation to “tool spam” is real, especially early on. New players often reach for prosthetics at the first sign of trouble, only to find themselves out of Spirit Emblems during a critical moment. Mastery comes from knowing when a tool is truly needed and when better deflection and aggression would suffice. :::

Bosses as Combat Exams

Sekiro’s boss encounters are not mere obstacles, they are deliberate lessons in combat mastery, each designed to teach, test, and refine specific aspects of the player’s skill. Unlike games where bosses might feel like damage sponges with flashy attacks, Sekiro’s bosses are conversational partners in a dance of aggression and deflection. Each encounter a structured exam that becomes satisfying precisely because it feels fair and instructive.

Take Genichiro Ashina, the game’s first major boss and a rite of passage for every Sekiro player. Genichiro teaches the foundational loop. His attacks are telegraphed enough to learn, yet threatening enough to punish hesitation. His horizontal sweep and thrust forces players to choose between deflecting and creating distance,a choice Sekiro consistently makes wrong for newcomers. Losing to Genichiro repeatedly teaches that backing away often not lower your posture while yielding initiative. Victory comes not from overleveling or exploiting patterns, but from internalising the rhythm, deflect the sweep, stay aggressive, be ready for the thrust, and watch his posture bar flash red as he breaks. A moment that feels earned because it’s the direct result of improved timing and aggression.

Guardian Ape adds chaos and environmental awareness. His sweeping grabs and terrifying screams create panic, but beneath the madness lies a pattern. His attacks leave openings for Combat arts or visceral finishers. The fight teaches players to manage fear, to look for tells in his animations, and to use the arena’s pillars strategically. Defeating him feels less like button mashing and more like solving a puzzle under pressure. A satisfaction rooted in clarity emerging from confusion.

Owl (Father) represents a test of everything learned so far. His mix of swordplay, thrusts, and unblockable sweeps forces players to blend Mikiri Counter, jump counters, and posture management. Owl punishes complacency. His attacks shift rhythm frequently, demanding constant adaptation.

Finally, Sword Saint Isshin is the ultimate examination. His relentless, fair pressure combines every lesson, rapid thrusts requiring Mikiri Counter, sweeping attacks demanding deflection, and combos that test stamina and focus. Isshin doesn’t rely on gimmicks or cheap tricks. He wins through superior offense that the player must learn to withstand and overcome. Beating him feels like a personal milestone, the culmination of hours spent refining timing, aggression, and mental fortitude. Community reactions often describe Isshin fights as emotional releases, where victory isn’t just relief but affirmation of growth.

:::note Community consensus often points to Sword Saint Isshin as the fight that best encapsulates Sekiro’s combat philosophy. Unlike bosses that rely on phases, gimmicks, or environmental hazards, Isshin wins through pure offensive mastery that the player must learn to match. His victory screen feels less like overcoming a cheap trick and more like standing taller after a genuine test of skill. :::

Why Sekiro’s Combat Creates Stronger Emotional Payoff

The victories in Sekiro linger in memory far longer than those in many other games, not just because they’re hard, but because they feel profoundly personal. When you finally topple Sword Saint Isshin or survive Guardian Ape’s frenzied assault, the triumph isn’t abstract, it’s a direct measurement of your growth as a player.

This emotional resonance stems from Sekiro’s unwavering focus on earned mastery. There are no shortcuts, no overleveling to trivialise a boss, no legendary weapon that bends combat to your will, no stat distribution that lets you brute-force through skill checks. Every victory demands that you internalise the game’s rhythm, sharpen your reflexes, and learn to read intent in the flicker of an enemy’s blade. When you succeed, it’s because you have changed, not your character sheet.

Sekiro helps you enter a flow state. This is the kind of deep focus where the challenge feels hard but fair. You stop thinking too much about yourself and become fully locked into the fight.

The combat is perfect for this. Your goal is clear. Break the enemy’s posture and land the deathblow. The feedback is instant. You hear the clash of swords. You see sparks. You watch the posture bar rise. The game keeps pushing you as you get better. It does not just make enemies stronger. It gives you faster enemies, tighter timing, and less room for mistakes.

Sekiro also builds mechanical confidence. This is the calm feeling that you can handle what the game puts in front of you.

At first, some fights feel impossible. Later, those same fights feel normal. This does not happen because your stats became much higher. It happens because you changed. You see attacks more clearly. You notice patterns. You understand rhythm. You start spotting openings.

That is when mastery begins. You are no longer just reacting. You are predicting.

This transformation mirrors broader truths about skill acquisition in any domain. Progress isn’t linear, plateaus precede breakthroughs, and the most rewarding victories come after sustained, focused effort. Sekiro makes this process visible and immediate, turning every boss corridor into a laboratory for personal growth.

Community & Culture

Sekiro has built a strong community around its combat. Players share jokes, phrases, challenges, and their own way of talking about the game. This is not only about memes. It shows how much the combat system connects with players. Many people remember the game because it forced them to learn through failure, focus, and mastery.

The most famous phrase from Sekiro is “Hesitation is defeat.” You see it in forums, streams, videos, and even tattoos. It captures the main lesson of the game. If you play too passively, you will lose. Sekiro rewards pressure. It punishes fear and retreat. Over time, this phrase became the best way to describe the mindset the game demands.

Another common phrase is “Git gud.” In Sekiro, this phrase feels more direct than in many other FromSoftware games. In Dark Souls, you can often use stronger gear, better stats, or a different build. Sekiro gives you fewer shortcuts. You have to improve your timing, reactions, and confidence. When players say “git gud” in Sekiro, they are saying something harsh but true. The tools are already there. You just have to learn how to use them.

Boss ranking is also a big part of the community. Players often argue about which bosses are the hardest or best designed. Sword Saint Isshin is usually seen as one of the greatest tests in the game. Genichiro Ashina feels like an exam that checks if you understand the combat. Lady Butterfly teaches timing, pressure, and calm movement. These debates are not only about difficulty. They also show how each boss teaches the player something different.

Sekiro also has many memes. The Guardian Ape is remembered for its screams, grabs, and unpredictable movements. The Mist Noble became a joke because of how strangely the community talks about him. Sword Saint Isshin also got the nickname “Glock Saint Isshin” because of his fast gun attacks. These jokes work because players remember how shocking these moments felt the first time.

Speedrunning became a major part of Sekiro’s legacy. Any% runs focus on finishing the game as fast as possible. Boss Rush runs focus more on pure combat. Hitless runs are even more extreme. In these runs, players finish the game without taking damage. This requires deep knowledge, perfect timing, and total control.

Mods and community challenges have also kept Sekiro alive. Randomizers change items or enemy placements. Boss rush mods create new versions of familiar fights. These challenges give experienced players new ways to test themselves. They show that Sekiro is not only a game people finished once. It is a combat system people keep returning to because it still feels deep, sharp, and rewarding.

Advanced Techniques and Mastery

For players who understand Sekiro’s basic combat loop, the game starts to feel much deeper. Combat is no longer just hard. It starts to feel like a martial art. Advanced techniques are not only about making the game harder. They are about playing with style, control, and skill.

One advanced technique is animation canceling. This means stopping part of an animation early so you can act sooner. In Sekiro, this can happen when you use a prosthetic tool or combat art right after an attack. It lets you connect moves in ways the game does not clearly explain. For example, you can cancel the end of a sword slash into the loaded umbrella. This gives you a quick defensive option. You can also cancel into a Mikiri Counter if you know a thrust attack is coming.

Prosthetic combos are another way skilled players get creative. Each prosthetic has a main purpose. But experienced players learn how to connect them in different situations. For example, you might use firecrackers to stun an enemy. Then you can follow up with the loaded axe to damage their posture. After that, you can use Ichimonji to set up a deathblow. These combos are not just about damage. They help you control the fight and create openings.

Combat arts are also deeper than they first seem. Advanced players do not just equip a combat art and use it randomly. They know when each one is useful. Mortal Draw is great for dealing heavy health damage in one strong hit. Whirlwind Slash can pressure enemies from a distance and break their rhythm. Real mastery comes from knowing the right moment to use each move.

source reddit

No-hit runs and charmless runs are challenges made by the community. They push the player’s skill very far. In a no-hit run, you cannot take any damage at all. One mistake can end the run. In a charmless run, you lose some of the safety that normally helps you survive. This forces you to rely on timing, focus, and skill. These challenges show how fair Sekiro can be when mastered. The game gives little room for mistakes, but it also rewards precision.

The Demon Bell is another way to make the game harder. It makes enemies more dangerous and more aggressive. But it does not make the game feel unfair. Instead, it makes your mistakes matter more. It teaches you to manage posture better and deflect more carefully. Winning with the Demon Bell active feels more rewarding because every mistake is more costly.

Frame-perfect deflections are one of the highest forms of skill in Sekiro. A perfect deflection needs very precise timing. The window is very small. When done correctly, it damages the enemy’s posture and keeps you safe. Players who can do this again and again against fast bosses like Sword Saint Isshin show incredible control. Their timing can feel as sharp as high-level fighting game players.

Resources and Further Exploration

For those inspired to dive deeper into Sekiro's combat system, the following resources offer valuable insights, detailed analysis, and community wisdom. All links were verified during research and represent authoritative sources on the game's mechanics, lore, and player culture.

How Chess Engines Handle Opening Theory

Thu, 23 Apr 2026 00:00:00 GMT

Cover image source: lexica.art

Chess engines have a real problem in the opening phase. The position is too complex for brute-force calculation from move one, yet the opening is exactly where engines are most exposed. They're excellent at calculating tactics and evaluating material imbalances in the middlegame and endgame. But the opening is a different beast. The branching factor is enormous, and the strategic considerations are long-term, subtle, and often don't show up on the board for another 15 moves.

From the starting position, White already has 20 legal moves. After just two moves each, that number jumps to more than 8,900 possible positions roughly. By move four, it grows to over 197,000. And it keeps increasing at an exponential rate.(Chess - OeisWiki)

Modern engines go a step further with neural network evaluations. For example, Stockfish uses NNUE, which helps the engine evaluate positions it has never seen before. This is especially useful in the opening, where it allows the engine to rely less on memorized lines and more on general understanding.

What’s interesting is how these pieces work together in practice. Engines use opening books to move through well-known theory without spending time on calculation. Once they reach something unfamiliar, they switch to evaluation and search to figure things out. On top of that, modern engines use machine learning to discover new ideas through self-play.It’s not a single method so much as a spectrum. On one side, you have pure memorization. On the other, pure calculation. Today’s engines sit somewhere in the middle, combining both depending on the position.

Why Openings Are Hard for Engines

The core problem is Combinatorial explosion. Chess has an average branching factor of around 35 moves per position in typical middlegame play. In the opening, it's higher because the position is open and tactical constraints are minimal.

Here's how quickly position counts grow from the starting array:

Piles	Positions
0(start)	1
1(White's first move)	20
2 (Black's response)	400
3	~8,092
4	-197,742
5	~4.8 million
6	~119 million

Even a shallow search can get out of hand. Looking just 6 plies ahead, which is only three moves each, already means evaluating over 100 million positions. Engines can process millions of positions per second, but spending that effort on every opening move is wasteful. Many of those positions are effectively the same from a strategic point of view.

Humans and engines handle this phase very differently. Humans rely on pattern recognition, long-term understanding, and memorized ideas built from study and experience. They can look at a position and understand why a move makes sense. Traditional engines work the other way around. They assign numerical scores to positions and calculate concrete variations.

This leads to a tricky evaluation problem in the opening. There are usually no immediate tactics to latch onto. Instead, the position is shaped by small, long-term factors like piece activity, pawn structure, and space. These advantages might not become clear until 10 or 20 moves later. Because of that, an engine might see two opening moves as almost equal, while human theory strongly prefers one based on deeper strategic understanding.

To see just how fast the numbers get out of hand:

def estimate_nodes(branching_factor, depth):
    nodes = 0
    for d in range(depth + 1):
        nodes += branching_factor ** d
    return nodes

# Branching factor of 20 in the opening
print("Nodes to depth 4:", estimate_nodes(20, 4))   # ~168,421
print("Nodes to depth 6:", estimate_nodes(20, 6))   # ~67M
print("Nodes to depth 8:", estimate_nodes(20, 8))   # ~26.9B

Nodes to depth 4: 168421  
Nodes to depth 6: 67368421  
Nodes to depth 8: 26947368421

Searching to depths where engine evaluation becomes reliable (typically 12+ plies for tactical positions) would require billions of node evaluations for just the first few moves. Opening books exist to skip all of that.

Opening Books and Databases

An opening book is a precomputed database of chess positions and associated moves, representing established theory. When an engine receives a position, it first checks whether that position is in its opening book. If found, the engine selects a move from the book (often with some weighting to avoid being predictable) and plays it instantly, no search required. Only when the position isn't in the book does the engine invoke its normal search process.

Polyglot Books

The Polyglot format is one of the most widely used formats in computer chess. It is designed as a simple, well-documented binary format for opening books. Instead of storing positions directly, it identifies them using a Zobrist hash key.

Each entry in a Polyglot book contains:

A 64-bit Zobrist hash of the position
The recommended move (encoded as source and destination squares)
A weight indicating the move's popularity or effectiveness
A learn value (used by some engines for book learning)

Stockfish, Komodo, and most UCI-compatible engines support Polyglot books.

A simplified Polyglot book entry looks like this:

Bytes   Field        Size    Description
0–7     key          8 bytes  64-bit Zobrist hash of the position
8–9     move         2 bytes  Encoded move
10–11   weight       2 bytes  Move weight (preference/frequency proxy)
12–15   learn        4 bytes  Learning value (used by some engines)

Each entry is a compact, fixed-size record:

[8 bytes key][2 bytes move][2 bytes weight][4 bytes learn]

PGN Databases

Portable Game Notation (PGN) is a text-based format for recording chess games. It's not as efficient for lookup as binary books, but PGN databases are the raw material from which opening books get built. Engines can use PGN files directly by searching for matching positions, though it's slower. Common PGN sources include TWIC (The Week in Chess), ChessBase game databases, FIDE-rated game collections, and engine tournament games.

PGN example:

[Event "Live Chess"]
[Site "Chess.com"]
[Date "2026.04.20"]
[Round "?"]
[White "JeyBe6"]
[Black "masterbr1an"]
[Result "1-0"]
[TimeControl "600"]
[WhiteElo "775"]
[BlackElo "772"]
[Termination "JeyBe6 won by checkmate"]
[ECO "D00"]
[EndTime "8:37:55 GMT+0000"]
[Link "https://www.chess.com/game/live/167561955386?move=0"]

1. d4 d5 2. e3 Nc6 3. Nf3 Bf5 4. Bd3 e6 5. Bxf5 exf5 6. O-O Bd6 7. Nc3 Nf6 8. a3
Ne4 9. Nxd5 Qd7 10. b4 O-O-O 11. c4 Nxd4 12. exd4 Nc3 13. Nxc3 f4 14. c5 Be7 15.
d5 Qg4 16. h3 Qh5 17. Bxf4 g5 18. Bxg5 Bxg5 19. Nxg5 Qxg5 20. Ne4 Qxd5 21. Qxd5
Rxd5 22. Nf6 Rf5 23. Ne4 Re8 24. Rfe1 Rfe5 25. Nf6 Rxe1+ 26. Rxe1 Rxe1+ 27. Kh2
Ra1 28. Nxh7 Rxa3 29. Ng5 f6 30. Ne6 Kd7 31. Nd4 Rd3 32. Nf3 Kc6 33. Ne1 Rb3 34.
Nc2 Kb5 35. Nd4+ Kc4 36. Nxb3 Kxb3 37. h4 Kxb4 38. h5 a5 39. h6 a4 40. h7 a3 41.
h8=Q Kb3 42. Qxf6 a2 43. g4 Kc2 44. Qa1 Kb3 45. g5 b6 46. g6 bxc5 47. g7 c4 48.
g8=Q c5 49. f4 Ka3 50. f5 c3 51. Qgxa2+ Kb4 52. Qa4# 1-0

Human-Made Vs. Automatically Generated Books

Opening books come from two sources. Human-made books are curated by chess experts who select moves based on grandmaster games, theoretical novelties, and strategic judgment. Automatically generated books process large game databases with engines to find what performs best statistically.

Human-made books tend to have better strategic nuance and exclude dubious lines that score well in engine vs. engine play but fall apart against human creativity. Automated books can process far more data and adapt to new trends quickly but may miss subtleties that experienced annotators would catch.

:::note Opening books go stale. A book that was state-of-the-art five years ago may contain lines that have since been refuted by new engine analysis. Regular updates matter for competitive play, especially in popular openings where theory moves quickly. :::

How Engines Transition out of Theory

An engine is "in book" when the current position exists in its opening book. It's "out of book" when the position isn't found, requiring it to fall back on search and evaluation. The transition point matters a lot because it's where memorized theory ends and independent calculation begins.

The transition can happen for several reasons. A novelty move (either player plays something not recorded in the book), the position exceeds the book's depth limit, or the specific variation or move order simply isn't covered.

When deciding whether to stay in the opening book or start calculating, engines look at a few practical factors. They consider the position itself, since some engines will leave the book early if the suggested move leads to something clearly worse. Time also matters. In time pressure, sticking to book moves avoids spending precious seconds on calculation.

They also take move selection into account. An engine might steer away from sharp, heavily analyzed lines and choose something quieter instead. On top of that, transposition tables play a role. If the same position shows up through a different move order, the engine can still recognize it and reuse what it has already learned.

:::tip Engines sometimes deliberately avoid the most popular book move. If the main line leads to a deeply theoretical variation, an engine might choose a sounds good but less popular alternative to steer into territory where its calculation strengths matter more. This comes up often in engine vs. engine matches where dodging preparation can be a real advantage. :::

Transposition tables smooth the transition considerably. These hash tables store previously searched positions and their evaluations, so an engine can reuse earlier work even when it reaches familiar positions through different move orders. A position reached via 1.e4 e5 2.Nf3 Nc6 3.Bb5 is the same position as one reached via 1.e4 e5 2.Bb5 Nc6 3.Nf3. If the engine has already analyzed it once, it doesn't start from scratch the second time.

Modern Engines, Neural Networks, and Self-Play

Neural networks have changed how engines handle the opening in ways that weren't fully anticipated even a decade ago. Engines like Stockfish (with NNUE), Leela Chess Zero, and AlphaZero learn to evaluate positions directly from training data rather than relying on hand-crafted evaluation functions.

NNUE in Stockfish

Stockfish's NNUE (Efficiently Updatable Neural Network) replaced the traditional hand-tuned evaluation function with a neural network trained on millions of engine-generated positions to predict game outcomes from any position.

What this means for the opening is NNUE can recognize subtle positional features that traditional evaluation missed, generalize to positions never seen before based on similarity to training data, update incrementally rather than recomputing the full network for each move, and improve as more training data is added.

The efficiency comes from a few specific techniques. Incremental updates mean only the changed portions of the network get recomputed after each move. Quantization uses 8-bit or lower precision weights to cut memory bandwidth requirements. Sparse input representation makes the feature transformation fast to compute. In practice, Stockfish evaluates millions of positions per second even with NNUE. Better evaluation quality also improves pruning decisions, reducing the number of nodes searched and partly offsetting the higher per-node cost.

Leela Chess Zero and AlphaZero

Lc0 and AlphaZero take a different approach entirely. Deep neural networks combined with Monte Carlo Tree Search (MCTS), trained through self-play from scratch, with no human knowledge fed in beyond the rules of chess.

In the opening, these engines develop understanding purely from self-play experience. They regularly discover ideas that contradict established theory. They show stylistic tendencies that differ from human players (Lc0's affinity for certain flank openings is well documented). And they require much less explicit book support because their positional understanding is strong enough to navigate early play without it.

Feature	Stockfish (NNUE)	Leela Chess Zero	AlphaZero
Training method	Supervised learning on engine positions	Self-play reinforcement learning	Self-play reinforcement learning
Evaluation	Neural network (NNUE)	Deep neural network	Deep neural network
Search algorithm	Alpha-beta pruning	Monte Carlo Tree Search	Monte Carlo Tree Search
Opening book use	Still useful, less critical	Minimal; relies on NN evaluation	None in original formulation
Notable opening traits	Follows theory closely, strong in tactical lines	Positional, sometimes unconventional	Aggressive, dynamic; sacrifices material for initiative

Classical engines before NNUE relied on hand-crafted evaluation functions, deep opening books to compensate for weak opening evaluation, and aggressive pruning that sometimes missed positional nuances. Neural-network engines shift that balance. Better evaluation reduces book dependence, generalization from similar positions fills gaps in coverage, self-play generates novel ideas, and positional compensation (material sacrificed for activity or structure) gets understood more like a human player would understand it.

Tools, Formats, and Ecosystem

The computer chess ecosystem around opening theory is larger than most people realize.

Key tools:

ChessBase: Industry-standard commercial database and analysis tool used by professionals and engine developers
SCID (Shane's Chess Information Database): Free, open-source alternative with robust game filtering and search
Arena: Free GUI for chess engines with opening book support, engine tournaments, and analysis
Cute Chess: Command-line and GUI tool built for engine vs. engine testing with sophisticated book handling
Polyglot: Reference implementation for creating and managing Polyglot-format books
Opening Tree: Web-based tool for visualizing opening statistics and move popularity

Common file formats:

PGN (Portable Game Notation): Human-readable text format for chess games
EPD (Extended Position Description): Describes chess positions with annotations, used for test suites
BIN: Binary format, often refers to Polyglot book files
Polyglot book files: Specialized binary format for efficient opening book lookup

:::warning Compatibility issues between engines and opening books are common. Not all engines support the same book formats, and even within supported formats there are implementation variations. Some engines expect Polyglot books to include specific metadata or handle learning values differently. Always verify that your engine supports the specific book format you're using and test that book lookups work correctly before relying on them in play. :::

Advanced Concepts and Future Directions

Several things are changing how opening theory gets handled as engine technology advances.

Dynamic opening books are shifting away from static, precomputed databases toward adaptive systems that update based on recent engine performance or new games. These books adjust move weights based on how lines perform in engine vs. engine play and can incorporate new games automatically.

Cloud analysis lets engines use distributed computing for deeper opening preparation. Services like ChessBase Cloud or Lc0's cloud analysis network give individual users access to analysis farms that would otherwise require dedicated server hardware.

Engine tournaments like TCEC (Top Chess Engine Championship) and the Chess.com Computer Chess Championship have become a real driver of opening theory development. Engine developers use these events to test new ideas, and the games themselves become valuable data for improving books.

Anti-book strategies involve deliberately playing moves designed to take opponents out of their opening preparation as quickly as possible. This includes rare sidelines, transpositions to unfamiliar structures, and positions where calculation matters more than memorization.

Personalized repertoires match opening books to an individual engine's or player's strengths. An engine that thrives in tactical positions might have a book built around sharp, double-edged openings. A more positional engine might focus on slower, maneuvering games.

Reinforcement learning approaches, following AlphaZero's lead, continue advancing. Future engines may rely less on static theory as their neural networks get better at evaluating opening positions from first principles.

Conclusion

Modern engines use opening books to navigate theory efficiently, neural networks to evaluate unfamiliar positions, and search algorithms to calculate concrete variations when needed. No single method carries the full weight. The interplay between them is what makes current engines as strong as they are in the opening phase.

The transition from book play to independent calculation isn't a sharp cutoff. Engines typically stay in book for the first 10-15 moves in major openings, reaching playable middlegame positions with minimal compute. As they move past book coverage or hit a novelty, they rely more on evaluation and search, with neural networks providing increasingly precise positional judgment.

What's changed most in recent years is how blurry the line between "book" and "calculation" has become. NNUE and similar approaches let engines generalize from training data, evaluating positions they've never seen before with real accuracy. That reduces dependence on memorization while retaining the benefits of human-derived theory where it's reliable.

:::tip[Quote] "The opening book is not a crutch for weak engines, but a tool for strong engines to reach positions where their strengths can be best utilized." - Inspired by discussions in computer chess forums and engineering documentation :::

As engines keep improving, opening theory handling will become more integrated and less reliant on static databases. Neural networks will keep getting better at evaluating opening positions from first principles, while still benefiting from the collective knowledge in their training data. The goal stays the same: reach a playable middlegame where the engine's calculation and evaluation strengths can take over.

References

https://en.wikipedia.org/wiki/Chess_opening_book_(computers)
https://www.chessprogramming.org/Polyglot_Opening_Book
https://www.chessprogramming.org/Opening_Book
https://www.youtube.com/watch?v=yAtVwiyXPxQ
https://www.youtube.com/watch?v=4EVjP091WLU
https://github.com/official-stockfish/Polyglot
http://scid.sourceforge.net
https://www.playwitharena.com
https://cutechess.com
https://lucaschess.github.io

How a Third-Party OAuth App Bypassed Vercel's CI/CD Platform Defenses

Mon, 20 Apr 2026 00:00:00 GMT

A Vercel employee used an AI meeting assistant called Context.ai and gave it access to their Google Workspace account. An attacker later used that OAuth token to move through Vercel's internal systems and read customer secrets. The secrets marked as "sensitive" were protected because they were encrypted at rest, but everything else could be read in plain text.

What happened

On April 19, 2026, Vercel published a security bulletin saying someone had gained unauthorized access to some of its internal systems and affected a small number of customers. The company traced the attack back to Context.ai, a third-party AI tool used by a Vercel employee.

Here’s what happened:

Context.ai’s Google Workspace OAuth app was compromised. The attacker got access to the app with client ID 110671459871-30f1spbu0hptbs60cb4vsmv79i7bbvqj.apps.googleusercontent.com. This was not a Vercel-only app. It was used by hundreds of organizations.
Using that OAuth access, the attacker took over the employee’s Google Workspace account at Vercel. Since Google Workspace is connected to Vercel’s internal systems, that account became a way into the company.
From there, the attacker moved into customer environments and accessed environment variables that were not marked as sensitive. Those variables were stored in a readable format.
The attacker then used those variables to discover and access more systems.

Vercel described the attacker as highly sophisticated because of how quickly they moved and how well they understood the company’s internal systems.

Guillermo Rauch said the attacker moved unusually fast and seemed to know Vercel’s internal architecture very well. He also said the attack may have been significantly sped up by AI.

What was exposed

Vercel has confirmed that environment variables marked as "sensitive" were not accessed. These variables use Vercel's sensitive environment variable feature, which stores values in a non readable format once created. The feature was released before this incident and is available for production and preview environments. Development environment variables cannot be marked sensitive.

What was exposed: environment variables that had not been marked as sensitive. These are stored in an encrypted-but-readable format, protected at rest, but accessible to anyone with the right level of access to the project. In practice, this means API keys, tokens, database credentials, and signing keys that customers had entered without enabling the sensitive flag could have been read by the attacker.

Vercel has not disclosed the total number of affected customers or what specific data was exfiltrated. The investigation is ongoing. See the "What the threat actor is claiming" section below for additional details and context on the claims circulating online.

What the threat actor is claiming

A threat actor using the ShinyHunters name posted on a hacking forum claiming to have breached Vercel and offering access keys, source code, database data, and internal deployment access for $2 million. They shared a sample file containing 580 Vercel employee records, names, email addresses, account status, and activity timestamps. The threat actor claimed on Telegram that they were in direct communication with Vercel about the incident, though Vercel has not independently confirmed this.

The forum post specifically claimed the attacker gained "access to multiple employee accounts with access to several internal deployments, API keys (including some NPM tokens and some GitHub tokens)." The threat actor also shared what appeared to be a screenshot of an internal Vercel Enterprise dashboard.

The identity of the threat actor is disputed. Members of the actual ShinyHunters group have reportedly denied to security reporters that they are involved in this incident. The ShinyHunters name has been used by multiple different actors over the years, and some of the individuals currently associated with it have denied the involvement. This matters because the real ShinyHunters is the group behind the Ticketmaster breach and several other high-profile incidents. If someone is using the name without the backing of the actual group, the data claims could be inflated, genuine, or somewhere in between.

BleepingComputer has not independently confirmed whether the leaked data is authentic. Vercel has not confirmed whether their data was sold. Treat the threat actor's claims as allegations, the breach itself is confirmed, but the scope and sale are not.

The bigger picture

This incident stands out because it shows a problem SaaS companies have struggled with for years: employee productivity tools can become entry points into core infrastructure.

An engineer might connect Vercel to their Google account, then connect that same account to an AI meeting assistant like Context.ai. That creates a chain of access the security team may never have directly approved or fully understood.

The compromise of Context.ai’s OAuth app may have affected hundreds of organizations, not just Vercel. Vercel is the most visible victim so far, but any company whose employees approved that app could face similar risk.

What makes this especially concerning for developers is the size of the blast radius. Vercel does not just host websites. It also manages deployment pipelines, build systems, and environment variables for thousands of projects. If an attacker gets access at the provider level, every downstream project can be exposed, even if those teams never approved the risky integration themselves.

This also highlights an important design problem. The feature for marking environment variables as sensitive already existed, but it was optional and not enforced. After the incident, Vercel changed that. For other platforms, the real question is not whether they offer a security feature like this. The real question is whether they make it the default.

Sources

Vercel April 2026 Security Bulletin — Official incident disclosure, root cause analysis, IOC, customer recommendations
Guillermo Rauch on X — CEO's detailed update covering escalation chain, AI-accelerated attacker assessment, supply chain verification, product changes
BleepingComputer: Vercel confirms breach as hackers claim to be selling stolen data — Reporting on ShinyHunters claims, $2M ransom demand, 580 employee records
The Hacker News: Vercel Breach Tied to Context AI Hack — Incident coverage and Context.ai connection
Vercel Docs: Sensitive Environment Variables — Technical details on the sensitive env var feature and policy enforcement
Vercel on X — Initial public disclosure and security bulletin link

Why We Seek Validation from Others

Sat, 18 Apr 2026 00:00:00 GMT

Cover image source: 根暗

"We check our phones not to connect, but to see if we've been seen."

The invisible audience

You've just posted a photo on social media. A shot from your weekend hike, the one where the light caught the trees just right. You set your phone down, but within seconds you're picking it up again. Not to reply to a message. Not to check the time. Just to see if anyone has liked it yet.

Zero notifications.

You scroll through the feed, waiting for that little red dot. When it finally arrives, a single like from a friend you barely talk to, you feel a small unexpected lift. Then you notice your friend's similar post has dozens of likes and that familiar sting creeps in. Why does this moment feel so significant? Why do we care so much about what others think, even when we know it's irrational?

This plays out constantly, not just on social media but in meetings, in relationships, in the small negotiations of everyday life. We rehearse what we'll say before a difficult conversation, hoping to sound competent. We laugh a little too hard at a joke we don't find funny. We change our opinions mid-sentence when we sense disagreement. We say "I'm fine" when we're not, because admitting the truth feels too risky. We stay late at work not because we have to, but because we want to be seen as dedicated.

The need for validation is not a modern quirk of digital life. It's an old drive, operating mostly below conscious awareness, shaping behavior in ways we rarely stop to examine.

James is a software engineer who sees himself as logical and practical. But after posting something on LinkedIn, he checks his notifications over and over. When a coworker's post gets more attention, he feels jealous and starts doubting himself. He knows likes and views do not define his value, but it still gets to him.

Maria loves being a mother. Still, when she posts on Instagram, she only shares the sweet, happy moments. She does not show the late nights, the stress, or the times she feels overwhelmed. Part of her wonders if people think she is a good mother based on what they see online.

What begins as a natural desire for connection can become a constant monitoring of external signals that leaves us feeling perpetually unsettled, always performing for an audience whose approval we can never fully secure.

The real question is why. Why does approval from other people feel so important? Why does it feel so good when we get it, and so painful when we do not?

What validation actually means

Maya just finished a presentation at work. She spent hours preparing, practicing her talking points, anticipating questions. Her manager gives her a quick "good job" and moves on. Later, Maya finds herself replaying the moment, wishing she'd gotten more specific feedback. She checks her email repeatedly, hoping for a follow-up. That evening, she tells her partner about the presentation and watches their reaction closely for signs of approval.

Validation is the feeling that our thoughts, emotions, or actions are understood, accepted, or valued by other people. It is not just praise. It is the feeling of being seen.

Psychologists usually talk about two kinds of validation:

External validation: Approval or affirmation that comes from outside ourselves. Other people, social media likes, awards, societal standards.
Internal validation: The ability to recognize and affirm our own experiences and worth without depending on others opinions.

External validation can feel good, but it does not last long. It depends on other people, and other people are inconsistent. One day they are supportive, the next day they are distracted, critical, or silent.

Internal validation is more stable. It gives you a sense of worth that does not disappear every time someone forgets to text back or does not react the way you hoped.

:::note[External vs Internal Validation] External validation seeks approval from others to feel worthy. Internal validation comes from recognizing our own inherent worth regardless of others opinions. :::

Research (The relationship of social approval contingency to trait self-esteem) supports the difference between internal and external validation.

Studies on something called "contingent self-worth" show that some people base their value more heavily on things like praise, appearance, success, or approval from others. When that happens, their confidence depends a lot on how other people react to them.

People with stronger internal validation tend to work differently. They base their sense of worth more on their own values, beliefs, and personal standards instead of constantly looking for approval from others.

Psychologists have found that depending too much on external validation can create more pressure, insecurity, and emotional ups and downs. When your self-worth depends on other people's opinions, you are relying on something you cannot fully control.

Internal validation is usually more stable. People who are more self-validating and internally motivated often feel more independent, resilient, and emotionally grounded because their sense of worth is not constantly changing based on outside reactions.

This helps explain why the need for validation can feel so intense. We are not only trying to feel good. We are trying to avoid the uncomfortable feeling of being disconnected or unsure of where we stand with other people.

David moved to a new city for a job he was genuinely excited about. Even so, he kept reaching out to friends and family back home, looking for reassurance that he had made the right choice. When they supported him, he felt better for a while. When they did not, he started to feel anxious.It was not just about wanting praise. Part of him needed to feel that the people close to him still understood and supported him. Without that, he started to feel uncertain and alone.

Research in social neuroscience suggests that rejection does not just feel emotionally upsetting. The brain processes it in a way that closely resembles physical pain.

Studies summarized by the American Psychological Association ( The pain of social rejection) show that when people are excluded or rejected, the same neural systems involved in detecting physical injury also become active. This overlap helps explain why rejection can feel physically painful, not just emotionally uncomfortable.

This is often referred to as social pain. The idea is that the brain uses overlapping systems to respond to both physical harm and threats to social connection. From an evolutionary perspective, this makes sense. For early humans, being excluded from a group could be dangerous, so the brain likely evolved to treat social rejection as something urgent and harmful.

Seen in this light, the need for validation becomes easier to understand. When approval is missing or when we feel ignored or dismissed, the brain may register it as a threat similar to physical harm. That helps explain why social disconnection can feel so intense, and why we are often strongly motivated to seek reassurance from others.

The pursuit of validation is, among other things, an attempt to avoid pain.

Where it begins

Think back to being a child, standing in front of a parent with a drawing you just made. A lopsided house, a smiley sun, a stick-figure family.

You hold it up and wait.

If they smile and say, “Wow, you worked hard on this,” you feel warm and proud. But if they barely look up because they are busy, something small but sharp hits you. You slowly lower the drawing and maybe even hide it behind your back.

Moments like this teach us an early lesson: do I matter just because I exist, or only when I perform well enough to get attention?

This idea is closely related to Attachment Theory, developed by psychologist John Bowlby. He observed that children form deep emotional bonds with caregivers, and those early experiences become a kind of template for how we expect relationships to work later in life.

When caregivers are consistent, warm, and responsive, children tend to develop what is called a Secure Attachment Style. They learn that people are generally reliable, their needs matter, and they do not have to earn love through constant effort or achievement.

When care is inconsistent, something different can form. With Anxious Attachment, a caregiver might be loving at times but distant or unavailable at others. The child learns to stay alert, always watching for signs of approval or withdrawal. With Avoidant Attachment, where emotional needs are often ignored, the child may learn to shut down those needs altogether to avoid disappointment.

These patterns do not disappear in adulthood. Research shows that people with anxious attachment styles are more likely to seek reassurance and approval from others compared to securely attached individuals The contribution of attachment styles and reassurance seeking to trust in romantic couples.

So when someone constantly looks for likes, feedback, or reassurance, it is not just about insecurity in the present moment. Often, it is a learned strategy. A way the nervous system adapted early on to make sense of love, attention, and safety.

If approval once felt conditional, tied to behavior or achievement, it is easy for the mind to carry that logic forward: I am okay when I am noticed. I am uncertain when I am not.

:::note[Attachment styles at a glance]

Secure: Consistent caregiving builds trust and comfort with intimacy
Anxious: Inconsistent caregiving creates fear of abandonment and excessive need for reassurance
Avoidant: Rejecting or unavailable caregiving leads to emotional distance as self-protection :::

Validation

The brain on validation

Imagine posting a thoughtful comment on a friend’s update. A genuine compliment, something you actually mean. You set your phone down, but your mind keeps circling back to it. Without really deciding to, you pick it up again.

Still nothing.

Later, a notification finally appears. A like, a reply, even just a small emoji. It gives you a quick, noticeable lift.

That reaction is not just a habit. It is connected to how the brain learns what is worth repeating.

A key part of this system is dopamine. It is not simply a “pleasure chemical.” It works more like a learning signal. It spikes when something turns out better than expected, helping the brain figure out what actions are worth doing again.

Social approval fits neatly into this system. When someone responds positively to us, the brain treats it as a rewarding outcome. The reward system activates, involving areas like the ventral tegmental area, nucleus accumbens, and prefrontal cortex. That activation is part of what creates the feeling of satisfaction and the urge to repeat the behavior.

Research has shown that social approval engages the brain’s reward system in a way similar to primary and monetary rewards. Studies reviewed in Frontiers in Neuroscience highlight that regions such as the striatum are consistently activated during social interactions involving positive feedback, including receiving approval, reputation gains, or favorable evaluation from others. These neural responses overlap with those observed in reward-based learning tasks involving money or other incentives, suggesting that social validation is processed as a form of reward by the brain. The role of the striatum in social behavior

In particular, activity in the ventral striatum has been linked to the subjective value of social outcomes. Functional imaging studies show that when individuals receive positive social feedback or experience socially rewarding outcomes, striatal activation increases in proportion to how much they value the interaction. This supports the idea that the brain encodes social approval using the same valuation circuitry involved in general reward processing.

Together, these findings suggest that seeking validation from others is partly rooted in the brain’s reward system, where social approval is treated as a meaningful and reinforcing signal.

Over time, this creates a simple loop. We do things that might earn approval. We feel rewarded when it happens. The brain remembers that connection and pushes us to do it again.

In environments where feedback is instant and frequent, like social media or fast-paced workplaces, this loop can run in the background without us really noticing.

:::note[What dopamine actually does] Dopamine isn't just the "feel-good" chemical. It's a learning signal. It teaches the brain which behaviors lead to rewarding outcomes, making us more likely to repeat them. In the context of validation-seeking, it reinforces whatever we believe will gain us social approval. :::

Social media as a validation machine

You’ve just finished editing a photo for Instagram. You tweak the brightness, add a soft filter, and write a caption that feels real enough, but still a little planned.

You hit share.

Then you wait.

Five minutes later, you check your phone. Nothing. Two minutes after that, you check again. Still nothing.

You tell yourself it is early and people are busy. But a minute later, you are checking again anyway. Still no likes.Now you start second-guessing everything. Was the lighting off? Did the caption feel forced? Did you pick the wrong photo?.

When the likes finally do come in, you feel relief. But it does not last. Almost immediately, a new thought shows up: will the next post do as well?

Social media did not create our need for approval. It just made it louder, faster, and harder to ignore.

These platforms are built in ways that keep this cycle going:

Instant feedback. Unlike face-to-face interactions where feedback might be delayed or subtle, social media provides immediate, quantifiable responses. Likes, comments, shares. A clear cycle of action and reward.

Algorithmic reinforcement. Platforms prioritize content that generates high engagement, which creates a feedback loop where behaviors that produce validation, posting provocative content, sharing personal updates, are rewarded with greater visibility, which increases the potential for more validation.

Upward comparison by design. Social media exposes us to carefully curated versions of other people's lives. When a friend's post gets hundreds of likes while yours struggles to break double digits, it's easy to interpret that as a reflection of your worth.

:::tip[The vending machine analogy] Think of social media as a vending machine for approval. Insert a post, pull the lever, wait to see what dispenses. Sometimes you get a jackpot. Sometimes nothing. The variability is exactly what makes it compelling, and potentially destructive. :::

Platform behavior	Psychological effect
Instant likes/comments	Immediate dopamine release
Algorithmic feed prioritization	Increased posting frequency to gain visibility
Follower/friend counts	Social comparison and status evaluation
Notification alerts	Anticipatory anxiety and compulsive checking
Comment threads	Opportunities for validation or rejection

The hidden costs

Alex prides himself on being the “go-to” person at work. He is always the one who stays late, takes on extra tasks, and agrees with teammates to keep things smooth. Over time, he gets very good at saying what others want to hear.

Lately, though, something has started to wear him down.

He feels tired in a way that rest does not fix. Not just physically, but mentally. He agrees to things he does not actually want to do, then feels annoyed afterward that he said yes. Even small choices, like what to eat for lunch, start to feel difficult because he keeps thinking, “What will other people think?”

This is what constant validation-seeking can look like from the inside.

Anxiety and stress. When our sense of worth depends on others opinions, we become hypervigilant to social cues, constantly scanning for signs of approval or disapproval. This activates the body's stress response, elevated cortisol, muscle tension, difficulty sleeping.

Eroded identity. When we consistently prioritize others expectations over our own preferences, we lose touch with what we actually think and want. Simple questions become hard: What do I genuinely enjoy? What matters most to me? Over time, this can produce a fragile sense of self that feels inauthentic, no matter how much approval arrives.

Decision paralysis. When every decision becomes a calculation of how others will perceive it, we choose based on external expectations rather than genuine desires. Career paths chosen to impress parents. Relationships maintained for appearances. Opinions expressed to fit in rather than because we actually hold them. The result is a life that may look successful from the outside but feels hollow from within.

Self-perpetuating dissatisfaction. The boost from external approval fades quickly. Then we're craving the next one. Ever-increasing doses to achieve the same emotional effect. A treadmill where we're constantly moving and never arriving anywhere.

The difficult part is that none of this usually feels extreme in the moment. It builds slowly, through small “yes” answers, small adjustments, small moments of self-editing, until it starts to shape how a person lives without them fully noticing.

:::warning[What excessive validation-seeking tends to produce]

Anxiety from constant monitoring of others opinions
Self-esteem that depends on external approval rather than inherent worth
Difficulty distinguishing between authentic preferences and performed ones
Increasing difficulty making autonomous choices
Relationships built on performance rather than genuine connection
Emotional exhaustion from managing impressions
Greater susceptibility to manipulation :::

Validation-seeking isn't inherently problematic. It's a natural human tendency. The problem comes when it becomes the primary source of self-worth, crowding out everything else.

Building internal validation

After years of tying her worth to other people’s opinions, Maya reached a point where something had to change. On paper, her life looked good. A solid career, plenty of friends, everything she was supposed to want. But internally, she felt drained, anxious, and strangely disconnected from herself.

One moment at work made it clear. During a team meeting, she realized she had spent the entire time planning what she was going to say instead of actually listening. When she was finally asked for her opinion, she gave a careful, agreeable answer that did not really reflect what she thought.

That night, she decided to approach things differently. Not by trying to get more approval, but by learning to trust her own judgment again.

At first, it felt uncomfortable. Almost like she was relearning something basic. But slowly, things started to shift. She felt less tense in conversations. She made choices based more on what mattered to her, not what would look good to others. And over time, she noticed something new, a sense of satisfaction that did not disappear the moment someone stopped paying attention.

This is what building internal validation looks like. It is not about ignoring other people’s opinions. It is about having a stable sense of self that does not collapse or shift every time someone reacts differently than expected.

Think of it as an internal compass. You still listen to others, but you are no longer completely dependent on them to decide what is right or enough.

There are a few practical ways people start building this:

1. Practice self-acknowledgment. Start by consciously recognizing your own experiences, feelings, and accomplishments. This might feel awkward if you're used to dismissing your own work ("it was nothing special") or waiting for others to point out what's valuable. Try this: at the end of each day, write down three things you did well, no matter how small they seem.

2. Develop emotional awareness. Learn to identify and name your emotions without immediately seeking external confirmation about whether they're "right." When you notice a strong feeling, try asking yourself "what is this telling me?" rather than "what will others think of me for feeling this way?"

3. Set internal standards. Clarify your own values and preferences separate from external expectations. What qualities do you want to cultivate? What activities make you lose track of time? What principles would you hold to even if no one else agreed?

4. Practice self-compassion. Treat yourself with the same understanding you'd offer a friend. When you make a mistake, instead of immediately thinking about how others will judge you, offer yourself some patience.

5. Experiment with small behavioral changes. Choose what you genuinely want to eat for lunch. Wear what you feel comfortable in rather than what's trendy. Express an opinion that differs from the group when you actually believe it. Notice what happens. Often the feared rejection doesn't come. And even when it does, you discover you can handle it.

6. Create validation rituals. Establish regular practices that reinforce your internal sense of worth. A morning reflection, a weekly review of accomplishments and growth, a monthly check-in on how you've lived in alignment with your values. Internal validation, like any skill, strengthens with consistent practice.

Internal validation is not something you suddenly “have.” It is something you slowly strengthen. And as it grows, the need for constant external reassurance starts to loosen its grip, not because other people stop mattering, but because you are no longer using them as the only measure of your worth.

:::tip[Key strategies]

Self-acknowledgment: Regularly recognize your own experiences and accomplishments
Emotional awareness: Identify and honor feelings without external validation
Internal standards: Clarify your own values and preferences
Self-compassion: Treat yourself with kindness, especially during difficulties
Behavioral experiments: Test making decisions based on your own preferences
Validation rituals: Create regular practices that reinforce internal worth :::

Exercises to try:

The compliment shift: When someone compliments you, instead of deflecting or minimizing it, try simply saying "thank you" and letting it land. Notice what happens in your body.
The opinion experiment: Share a genuine opinion or preference in a low-stakes situation and observe the outcome. Did the world end when you disagreed?
The achievement journal: For one week, write down three things you did well each day, focusing on effort and intention rather than outcomes. Review it at the end of the week.
The values check: Before making a decision, pause and ask "does this align with my values?" rather than "what will others think?"

Research from self-determination theory shows that when people cultivate internal sources of motivation, they experience greater psychological wellbeing, more authentic relationships, and greater resilience when external feedback is negative (Self-Determination Theory). Mindfulness-based interventions have also been shown to reduce reliance on external validation by increasing present-moment awareness and decreasing automatic reactivity to social cues.

Carlos is a graphic designer who used to say yes to everything. He was afraid that setting boundaries would make him look uncommitted, so he took on extra work, accepted unrealistic deadlines, and often worked late into the night. Eventually, he burned out and had to take medical leave.

During recovery, he tried something simple. Each morning, he wrote down one thing he actually wanted to focus on that day, without thinking about what others expected. At first, it felt uncomfortable, even selfish. But over time, things shifted. He started producing more meaningful work, felt less drained, and actually enjoyed collaborating with others again.

Aisha is a college student who originally chose her major based on her parents’ expectations. She did well academically, but felt disconnected from what she was studying. Later, she took an environmental science class just out of curiosity. That one class changed something for her. She felt engaged in a way she had not felt before.

She eventually changed her major, even though she knew her family might not fully support the decision. Her performance improved once she started studying something she actually cared about.

These are not dramatic transformation stories. They are examples of what often happens when people shift their focus slightly, from constantly performing for others to paying attention to what actually matters to them.

Reflection

:::important[Questions for self-inquiry]

When was the first time you remember seeking validation from others? What happened, and how did it shape your understanding of what earns approval?
In which areas of your life do you notice yourself seeking validation most intensely? What fears underlie the seeking?
How does your behavior change when you're seeking validation versus when you feel internally validated? Notice differences in how you speak, how you hold your body, how you make decisions.
What would it feel like to trust your own judgment completely, even if others disagreed or disapproved? What's one small step you could take toward that trust?
How might your relationships change if you were less dependent on others approval? What authenticity might emerge? :::

Resources and references

Security Is Not a Feature. It's a Way of Thinking.

Sun, 12 Apr 2026 00:00:00 GMT

Cover image source: lexica.art

In March 2017, Apache disclosed a critical vulnerability in Struts CVE-2017-5638. The patch dropped the same day. Equifax, one of the largest credit agencies in the US, received internal alerts telling their teams to apply it within 48 hours.

They didn't.

Attackers probed the exposed portal three days later, found it unpatched, and spent the next 76 days inside the network. They moved laterally, grabbed plaintext credentials, and walked out with the personal data of 148 million Americans. Social security numbers. Birth dates. Addresses. The breach wasn't discovered internally until late July. The public didn't hear about it until September.

A congressional investigation eventually called it "entirely preventable."

That's the part I keep coming back to. Not the scale, though losing half the US population's identity data is obviously catastrophic. The part that sticks is how mundane the failure was. No zero-day exploit. No nation-state magic. A known vulnerability. An available patch. A team that apparently never asked: what if we missed this?

That's not a technical failure. That's a failure of thinking.

The checkbox problem

There's a way of treating security that I'd call feature thinking. You implement 2FA, check. You deploy a WAF, check. You run a vulnerability scan before release, check. The controls are real, but the model underneath them is wrong. It assumes that once a control is in place, the problem it addresses is solved. It treats security as something you ship, like a login form or a payment gateway.

The problem is that attackers don't care about your checklist. They probe assumptions, find gaps between checkboxes, and exploit the space between "we have this feature" and "this feature works the way we think it does."

Compare it to building a house. You could install a top-of-the-line alarm system, never test it, never change the default PIN, and leave a window cracked for ventilation. Or you could assume that someone will try every door and window, so you reinforce frames, test the motion lights, and know what you'd do if the alarm actually went off. The first person bought a security feature. The second has a security mindset. The difference sounds simple. In practice, it changes how you think about every decision you make while building systems.

Feature thinking	Mindset thinking
Security is a phase (we do it in testing)	Security is continuous across the whole lifecycle
Controls exist to pass audits	Controls exist to reduce real risk
Vulnerabilities are bugs to fix before release	Vulnerabilities are inevitable — detection and containment matter
Security is the security team's job	Security is everyone's job
Success = no findings in the scan	Success = low mean time to detect and respond
Reliance on perimeter	Assume breach, verify everything

When technical perfection fails

Here's a thought experiment I find useful. Imagine a system built with genuinely excellent security engineering: formally verified code, hardened configs, CIS benchmarks, memory-safe languages, hardware encryption, red team tested. On paper it's airtight.

Now deploy it in a hospital. The developers move on. Staff share a password across shifts because individual logins "slow down emergencies." IT disables MFA for the same reason. Nobody funds security training because the budget went elsewhere. Six months in, a phishing email gets a nurse's credentials. The attacker logs in, moves through the internal network freely because internal traffic was implicitly trusted, and exfiltrates thousands of patient records.

The code was fine. The system failed.

This scenario exposes what feature thinking misses: you can't separate the security of a system from the humans who build, operate, and use it. No formal verification tells you how a nurse under pressure will respond to an MFA prompt at 3am. No red team engagement anticipates that IT will quietly disable controls to reduce friction. These are human factors, and they're not edge cases — they're the norm.

A mindset-based approach asks different questions during design: Who actually uses this? What pressures do they face? What workarounds will they invent? It builds in monitoring for drift — the gradual loosening of controls that happens when convenience consistently wins over friction. It treats "the code is secure" as the beginning of the question, not the end.

What these breaches actually have in common

The Equifax breach. Target in 2013. Yahoo's disasters from 2013-2014 (disclosed years later, affecting 3 billion accounts). Different attackers, different industries, different techniques. The mindset failures are almost identical.

Target: Attackers stole credentials from an HVAC vendor. The vendor had broad network access — because why wouldn't a vendor with a contractual relationship be trusted? The malware detection tool (FireEye) saw what was happening and fired alerts. Security teams received them and dismissed them as noise. Nobody owned the response process. By the time the holiday season was over, 40 million credit cards were gone.

The tool worked. The culture didn't.

Yahoo: Attackers accessed 3 billion accounts. Passwords were hashed with MD5.Weak even for 2013. The breaches were discovered internally and then... not disclosed. For years. Partly because there was acquisition pressure (Verizon was buying Yahoo at the time), partly because the culture had normalized ignoring security warnings after years of minor incidents. Data was treated as something to monetize, not something to protect.

Across all three, you see the same patterns: complacency born from size or success ("we're too monitored to be breached"), misaligned incentives, diffused ownership, and a reactive posture that waited for incidents instead of hunting for assumptions to challenge.

More tools wouldn't have saved any of them. A different way of thinking might have.

Threat modeling as productive paranoia

If a security mindset is a habit, threat modeling is the exercise that builds it. The core idea is simple: before you build something, think like an attacker and ask how it breaks.

STRIDE is the framework I find most useful because it forces you to think across multiple dimensions rather than just "is this input validated." It covers:

Spoofing — can someone pretend to be something they're not?
Tampering — can someone modify data or code without authorization?
Repudiation — can someone deny an action they performed?
Information Disclosure — can someone access data they shouldn't?
Denial of Service — can someone make something unavailable?
Elevation of Privilege — can someone gain more access than intended?

Let me run through a concrete example. Say you're building a document sharing app. Users upload files, other users can view them. Simple enough. Here's a partial threat model:

User Browser → (HTTPS) → Load Balancer → Web App → Auth Service
                                                   → Database
                                                   → Object Storage
Admin Dashboard → (HTTPS) → Web App

Now apply STRIDE to each connection:

Web App → Database:

Spoofing: If app credentials leak, an attacker can query the database directly.
Tampering: SQL injection on any unsanitized input.
Information Disclosure: Overly broad queries returning excess data.
Elevation of Privilege: If the app's DB role is overprivileged, one compromised endpoint exposes everything.

Web App → Object Storage:

Information Disclosure: A misconfigured bucket with public read access. This one bites people constantly.
Tampering: If the storage role allows overwrites, an attacker can replace files.

Admin Dashboard → Web App:

Spoofing: If admin sessions aren't properly scoped and short-lived, stolen cookies escalate privileges.
Repudiation: If admin actions aren't logged, you can't reconstruct what happened during an incident.

From this you derive concrete mitigations: parameterized queries, least-privilege IAM roles, explicit bucket policies blocking public access, short-lived session tokens, comprehensive audit logging. Not because a compliance doc said to — because you traced specific threats to specific gaps.

That's what makes threat modeling different from a checklist. It connects your decisions to actual failure modes. And because you revisit it as the system evolves, it stays current in a way that a one-time audit never does.

A note on code

Threat modeling identifies the risks. Your code is where you address them.

The most common SQL injection pattern in Python Flask:

# This gets people fired
@app.route('/user/<user_id>')
def get_user(user_id):
    conn = get_db_connection()
    cursor = conn.cursor()
    query = "SELECT * FROM users WHERE id = " + user_id
    cursor.execute(query)
    user = cursor.fetchone()
    return jsonify(dict(user)) if user else ("User not found", 404)

Request /user/1 OR 1=1-- and you get every user in the database. Request /user/1; DROP TABLE users-- and you get something much worse.

The fix is parameterized queries:

@app.route('/user/<user_id>')
def get_user(user_id):
    conn = get_db_connection()
    cursor = conn.cursor()
    query = "SELECT * FROM users WHERE id = %s"
    cursor.execute(query, (user_id,))
    user = cursor.fetchone()
    return jsonify(dict(user)) if user else ("User not found", 404)

The database driver handles escaping. user_id is a value, never executable SQL.

This is a solved problem. The code to fix it is trivial. The reason it keeps appearing in production is not that developers don't know about it, it's that the culture around code review, training, and secure defaults doesn't make it impossible to write the wrong version. A security mindset changes what you check in review and what defaults you reach for first.

Zero Trust is a way of thinking, not a product

"Zero Trust" has become vendor-speak for a product category. The actual idea is important and worth separating from the marketing.

The traditional model was perimeter-based: harden the network edge, then trust everything inside. This made some sense when users worked on-site, applications lived in data centers, and data rarely left the building. It makes no sense now. Cloud infrastructure, remote work, contractor access, third-party integrations — the perimeter dissolved. Attackers don't need to breach the castle walls if they can phish someone's credentials and walk through the front gate.

Zero Trust says: stop assuming trust based on network location. Verify every access request, regardless of where it comes from. The four principles that matter:

Never trust, always verify. Every request — internal or external — gets authenticated, authorized, and encrypted. Your internal services don't get a free pass just because they share a VPC.

Least privilege. Users and systems get exactly the access they need and nothing more. When a credential gets compromised (and it will), the blast radius stays small.

Assume breach. This one changes your investment priorities. If you assume attackers will get in, you stop spending everything on prevention and start investing seriously in detection, segmentation, and response. You design for containment, not just exclusion.

Continuous monitoring. Trust isn't granted once — it's re-evaluated constantly. Anomalous behavior should trigger re-authentication or session termination, not just a logged warning nobody reads.

The contrast with traditional thinking is sharp:

	Traditional	Zero Trust
Trust model	Implicit inside the perimeter	Never trust, always verify
After a breach	Attacker moves freely internally	Segmentation limits lateral movement
Access control	Network-based (IP, VLAN)	Identity and context based
Monitoring	Perimeter-focused	Continuous, everywhere

The human element here matters as much as the architecture. Zero Trust works when engineers design systems that default to denial. It breaks down when MFA prompts get disabled for convenience, when IAM roles get expanded because "it was easier," when alert fatigue causes teams to stop investigating anomalies. The architecture is the enabler. The mindset sustains it.

Culture is the hard part

You can have excellent threat modeling practices, clean code, and a well-architected Zero Trust deployment and still watch it erode over 18 months if the culture doesn't support it.

The Target breach makes this concrete. Their FireEye deployment was configured correctly. It saw the attack and fired alerts. The security team received them and didn't act, partly alert fatigue, partly unclear ownership of who was supposed to respond. The tool worked. The culture didn't support using it.

Two teams building the same product, same tooling budget:

Team A gets quarterly security training, runs SAST scans, treats vulnerabilities as low-priority tech debt, and views security review as something that slows down releases.

Team B raises abuse cases during sprint planning, praises developers who catch edge cases in design review, runs blameless postmortems after near-misses, and shares lessons from external breaches in their regular meetings.

Over two years, Team B builds fewer vulnerabilities in, detects the ones they have faster, and recovers from incidents more cleanly. Not because they have better tools. Because security thinking is part of how they work, not a gate they pass through.

A few practices that actually make a difference:

Make security questions part of existing rituals. Not separate security meetings, that signals it's someone else's domain. Ask "what could go wrong here?" during sprint planning. Include threat review in design reviews. Check for authorization logic in code review alongside style and correctness.

Psychological safety for security concerns. If a junior engineer spots a potential issue and raises it, and the response is "that's not your area" or "we'll handle it later," they won't raise the next one. Leaders who visibly reward people for surfacing concerns, even false alarms, change this. Leaders who don't, quietly eliminate it. Blameless postmortems. When something goes wrong, the instinct is to find who made the mistake. This is the wrong frame. If one person's error can cause an outage or a breach, the system enabled it. Focus on what systemic conditions allowed it to happen and how to change them. Blame silences the people who'd otherwise surface the next problem early.

Reward finding problems, not just shipping features. If the only thing that gets recognized is velocity, that's what people optimize for. Recognizing a developer who found a subtle authorization flaw in review, or a team that improved their detection coverage, sends a signal about what actually matters.

Tools won't save you

Every year the security industry releases new categories of tools. SAST, DAST, SCA, CSPM, CWPP, EDR, XDR, SIEM, SOAR. Each promises to close a specific gap. Each creates a new alert stream that needs interpretation, tuning, and a team with the judgment to act on it.

The pattern in most organizations: a breach occurs or a regulation changes, leadership buys a tool, the tool gets deployed with default config, alerts start firing, the team gets overwhelmed, alert fatigue sets in, the tool becomes expensive background noise.

What's actually happening here is that the tool amplified a capability the team didn't have. A SAST scanner that flags a potential path traversal means nothing if the team's response is to apply a quick blacklist fix and mark it resolved. A security mindset would ask: why does this code accept file paths at all? Is there a design that avoids this class of vulnerability entirely? Can we learn something here that changes how the team writes code next time?

The tool surfaced a question. The mindset determines whether you answer it.

Some specific limitations worth knowing:

SAST generates false positives. If developers don't understand the underlying vulnerability classes, they'll dismiss real findings along with the noise.
WAFs can be bypassed with encoding tricks and logic flaws. They're a useful layer, not a substitute for fixing the application.
SIEM without proper tuning is a very expensive logging system. The signal-to-noise ratio degrades fast.
SCA only catches known vulnerabilities in published versions. Zero-days in your dependencies show up nowhere until they're disclosed.

None of this means don't use tools. It means don't confuse deploying a tool with having a security posture. In skilled hands, these tools are force multipliers. Without the judgment to interpret their output, they're theater.

What this looks like day to day

I've been describing a mindset, which is abstract. Let me make it concrete.

A day for an engineer who's actually internalized this:

Morning standup surfaces a new payment feature. The instinctive question that runs in the background: what are the credential stuffing risks here? What happens if this endpoint gets hit with high volume?

Design review for an API change. Before implementation: sketch the trust boundaries on a whiteboard. Note that the logging currently captures raw user data, switch to correlation IDs instead. Mention it.

Writing a file upload handler. Automatic: validate file type, set a size limit, consider whether the processing happens sandboxed.

Code review. Spot that an admin endpoint is missing an authorization check. Raise it. Thank the person who catches the next one.

End of day. Read a summary of a recent breach in a similar industry and think for five minutes about whether any of it applies to what you're building.

None of that requires a dedicated security role or a separate security sprint. It's just questions that become habitual when you've shifted from "have we secured this" to "how would we break this."

The uncomfortable conclusion

Security is not a state you achieve. It's a state you maintain, continuously, against an adversary who adapts. The perimeter doesn't hold. Patches get missed. Credentials get stolen. Insiders make mistakes. Anyone building systems who isn't thinking about how those systems fail is not thinking about them completely.

Equifax had the patch. They had the alert. They had the tools. What they didn't have was a culture where someone, anywhere in the chain, was asking: what if we missed something?

That question is free. Asking it habitually, at every stage of design and development and operation, is what separates the teams that catch breaches early from the ones that find out 76 days later.

Security isn't a feature you ship. It's a way of thinking you cultivate, incrementally, imperfectly, and without end.

Further reading if you want to go deeper:

We Stopped Too Early: Why I'm Building a Classical Chess Engine from Scratch

Sat, 28 Mar 2026 00:00:00 GMT

Cover image source: civitai.com

I've been writing chess engines for few years now. Not playing chess. Writing engines. There's a difference, and it matters for what I'm about to say.

I'm an average chess player at best. I know enough to not blunder my queen in the opening, and that's roughly where my playing ability stops. But the engines, the code, the search trees, the eval functions, the way you can make a CPU chase down the best move in a position with nothing but logic and math, that stuff has had me hooked since I first touched it. I've written engines. Bad ones first, then less bad ones. I've read the papers, dug through every chess engines ever existed , benchmarked things that didn't need benchmarking like i have OCD. (yeah yeah, i know i need help). I've spent weekends staring at positions where my engine made a move I thought was terrible and then slowly realized the engine was right and I was wrong.

So when I say the chess engine world moved on too fast from classical search, I'm not saying it from the outside.

How Classical Engines Actually Work

Before I get into what I think is missing, I want to explain how classical engines actually work. Not at a surface level. The real thing. Because I've noticed that most people who talk about "classical vs neural" don't have a clear mental model of what classical eval actually does, and it matters for the argument I'm making.

A classical chess engine has two separable components: search and evaluation. These are different problems solved in different ways, and conflating them causes a lot of confusion.

Search is the process of exploring the game tree. Given a position, the engine generates all legal moves, plays them out, then generates all responses, plays those out, and keeps going until it hits a depth limit or a terminal state. The naive version of this is called minimax: at your turn you pick the move that maximizes your score, at the opponent's turn they pick the move that minimizes your score. The score propagates back up the tree.

If the game tree had branching factor b and you searched to depth d, the number of nodes you'd need to visit is:

$$N = b^d$$

For chess, b is roughly 35 on average. At depth 10, that's 35^10, which is around 2.76 * 10^15 nodes. On modern hardware doing maybe 10 million nodes per second, that's about 87 years of computation for a single move. Completely unusable.

The first major insight that made chess engines practical is alpha-beta pruning. The idea is that you don't need to explore the entire tree. If you're searching a subtree and you find a move that's already worse than something you've already found, you can stop searching that subtree entirely. The opponent would never let you play into it anyway.

The algorithm maintains two values: alpha (the best score the maximizing player is guaranteed) and beta (the best score the minimizing player is guaranteed). When beta falls below alpha, you prune.

function alphabeta(position, depth, alpha, beta, maximizing):
    if depth == 0:
        return evaluate(position)
    
    if maximizing:
        value = -infinity
        for move in legal_moves(position):
            value = max(value, alphabeta(play(position, move), depth-1, alpha, beta, false))
            alpha = max(alpha, value)
            if alpha >= beta:
                break  // beta cutoff
        return value
    else:
        value = +infinity
        for move in legal_moves(position):
            value = min(value, alphabeta(play(position, move), depth-1, alpha, beta, true))
            beta = min(beta, value)
            if beta <= alpha:
                break  // alpha cutoff
        return value

In the best case, with perfect move ordering, alpha-beta reduces the effective branching factor from b to roughly sqrt(b). For chess that means around 6 instead of 35, which brings depth 10 down to 6^10 = about 60 million nodes. Manageable.

But move ordering matters enormously. If you search the best moves first, you get more pruning. Real engines spend a lot of effort on this: killer moves, history heuristics, static exchange evaluation to order captures. The idea is to search the most promising moves first so alpha-beta cuts off the garbage quickly.

On top of this, engines add a bunch of other things. Null move pruning: if you skip your turn entirely and the position is still good for you, it's probably not worth searching deeply. Late move reductions: moves that are unlikely to be good get searched to shallower depth. Aspiration windows: search with a narrow window around the expected score, and widen only if the score falls outside it. Iterative deepening: search depth 1 first, then depth 2, then depth 3, using results from shallower searches to order moves for deeper ones. Transposition tables: cache positions you've already evaluated so you don't re-search them when the same position is reached by a different move order.

All of this adds up to engines that can realistically search 20-30 moves deep in a few seconds.

Evaluation is what happens at the leaves. When the engine hits its depth limit on a node, it needs a number. That number is the static evaluation of the position, a single score representing how good the position is for White (positive) or Black (negative).

Classical eval is a weighted sum of hand-crafted features. Here's a simplified version of what Stockfish's classical eval was doing before NNUE:

eval(position) = 
    material_score(position)
  + pawn_structure_score(position)
  + piece_mobility_score(position)
  + king_safety_score(position)
  + passed_pawn_score(position)
  + bishop_pair_bonus(position)
  + rook_open_file_bonus(position)
  + ... (dozens more terms)

Each of these terms is computed by looking at the board state directly. Material is just counting pieces with known values (pawn = 100 centipawns, knight = 320, bishop = 330, rook = 500, queen = 900). Pawn structure looks at doubled pawns, isolated pawns, backward pawns, pawn chains. Mobility counts how many squares each piece can reach. King safety looks at pawn shields, open files near the king, attacking pieces.

The weights on these terms were tuned, originally by hand, and later by automated methods like Texel tuning, where you adjust weights to minimize prediction error on a large set of positions with known outcomes.

This whole system is interpretable. You can look at it and say "the engine thinks this position is +1.3 because White has a passed pawn worth +0.5, better king safety worth +0.4, and a bishop pair worth +0.15." Every piece of the score is traceable.

The problem is that chess positions have interactions that this additive model can't capture well. A passed pawn is worth different amounts depending on whether there are rooks on the board, what color the opposing bishops are, how far advanced it is, whether the opposing king can catch it. These interactions are real and strong, but modeling them explicitly requires exponentially more features as you try to capture more of them. The classical eval was always an approximation, and the approximation had a ceiling.

What NNUE Actually Did

NNUE stands for Efficiently Updatable Neural Network. The name is more descriptive than it sounds.

The architecture was designed specifically for use inside a chess engine search loop. The key constraint is speed: the eval function gets called millions of times per second, so it needs to be fast. A full neural network forward pass for every node would be prohibitively slow. NNUE solves this with a specific architecture and an incremental update trick.

The input to the network is a high-dimensional binary feature vector. The most common scheme is called HalfKA or HalfKP: for each side, and for each piece type and square combination, you have a binary feature for whether that piece is on that square, relative to the king's position. This gives you something like 40,000 input features, but almost all of them are zero for any given position.

The network has a few fully connected layers:

Input layer:   ~40,000 features (sparse)
Hidden layer 1: 256 neurons (ReLU)
Hidden layer 2: 32 neurons (clipped ReLU)
Hidden layer 3: 32 neurons (clipped ReLU)
Output:         1 value (eval in centipawns)

The first hidden layer is the expensive one because the input is large. But here's the trick: when you make a move on the board, only a few features change. A piece moved from square A to square B turns off a few features and turns on a few others. Instead of recomputing the entire first layer from scratch, you incrementally update it. Add the weights for the new features, subtract the weights for the old ones. This makes the first-layer update O(k) where k is the number of changed features, not O(n) where n is 40,000.

The subsequent layers are small enough (256 to 32 to 32 to 1) that they can be computed quickly. And with SIMD instructions doing vectorized integer arithmetic, the whole forward pass takes a few dozen nanoseconds.

The result is an eval function that's both faster and much stronger than the old classical eval. The network learns, from millions of self-play games, exactly how pieces interact with each other, what king safety really means, when a passed pawn is dangerous and when it isn't. All the interactions that the classical weighted sum approximated badly, the network captures automatically.

When Stockfish switched to NNUE in 2020, it gained something like 80-100 Elo almost immediately. The jump was that clean. And it's continued improving every year since.

I'm not skeptical of any of this. NNUE is real and it works.

What I keep thinking about is the question it didn't answer.

The Thing That Kept Bothering Me

For years I've had this thought I couldn't shake. It'd come up reading about new NNUE architectures, benchmarking my own engines, or just sitting with a position thinking about what makes it good or bad.

We never really answered the question of what evaluation is.

Every classical engine I've ever read, written, or studied answers the same question: how good is this position? It scores material. It looks at pawn structure. It adds something for king safety, checks mobility. Then it sums everything up into a number and says "this position is +1.3 for White." NNUE answers the same question, just with a more expressive function. The question itself never changed.

But I keep thinking about how grandmasters actually think. Not how they describe it in chess books, which is often post-hoc rationalization, but what they're actually responding to when they look at a position.

A strong player doesn't look at a position and think "White has a passed pawn worth 0.5 and better king safety worth 0.4." They look at the position and think: "White has a plan. Black is shuffling." Or: "There are six candidate moves for White, but only one of them actually threatens anything. Black has to find that one move or the game is over."

That's a statement about the structure of the future, not the state of the present. And it's the thing I've never seen formalized in a chess engine.

The Classical Evaluation Ceiling

I've spent a long time thinking about where specifically classical eval breaks down. Not in vague terms. In specific position types I've tested against my own engines repeatedly.

Zugzwang is the clearest case. A position is in zugzwang when the side to move would prefer to pass. In pure zugzwang, any move you make makes your position worse. Classical eval has essentially no way to detect this. The features it computes are all about the current board state. Whether moving is an advantage or disadvantage depends entirely on the structure of the continuation tree, which classical eval doesn't look at.

Engines handle zugzwang in practice by searching deeply enough that the tree reveals it. But that's the search doing the work, not the eval. The eval itself is blind to it.

Fortress positions are another one. A fortress is a drawn position where the losing side can hold a draw by keeping pieces in a specific configuration, even though they're materially behind. Classical eval typically scores fortresses as losing, because the feature-based view sees material deficit and doesn't see why the position is actually drawn. Engines again handle this through deep search and endgame tablebases, not through eval.

Quiet maneuvering positions are harder to articulate but just as real. Sometimes a position is good for one side not because of any feature you can point to, but because they have a long-term plan and the opponent has nothing meaningful to do. The side with a plan is improving their position slowly while the opponent shuffles. Feature-based eval often scores these positions as roughly equal because nothing dramatic is happening, and then the engine is surprised when the slowly improving side converts.

All of these cases have something in common. The feature-based eval is missing information about what can be done from the position, not just what is in the position. It's evaluating the board state when it should be evaluating the board state's relationship to the future.

A Different Question

What if instead of asking "how good is this position," the engine asked "how much does this position constrain the future?"

When a grandmaster looks at a position and says "White is clearly better," they're often responding to exactly this. White has a clear plan. Black's options are bad or forced. The position is good not because of any single feature, but because the future is lopsided.

Information theory has a way to measure this: entropy.

Shannon entropy of a probability distribution P over outcomes is:

$$H(P) = -sum_i [ p_i * log2(p_i) ]$$

High entropy means the distribution is spread out. Many roughly equal options. Low entropy means the distribution is concentrated. A few options dominate.

Applied to chess: imagine you're at a position and you have a probability distribution over your legal moves, weighted by how good each move is. If all your moves are roughly equally good (or bad), that's high entropy. If one move is clearly forced and everything else loses, that's low entropy.

Here's the thing: low entropy on one side combined with high entropy on the other is what a grandmaster means when they say "White has a clear plan and Black is lost." White's move tree is concentrated. Black's move tree is chaotic or all-losing.

So let me define this more carefully.

For a position P and a side s, let M(P, s) be the set of legal moves for side s. For each move m, let v(m) be a shallow evaluation of the resulting position (using any eval function). Convert these values to a probability distribution using softmax:

$$q(m) = exp(v(m) / T) / sum_{m' in M} exp(v(m') / T)$$

Here T is a temperature parameter controlling how sharply the distribution peaks around the best moves. Low temperature means the distribution concentrates on the top moves. High temperature means it spreads more evenly.

Now define the positional entropy for side s at position P:

$$H(P, s) = -sum_{m in M(P, s)} [ q(m) * log2(q(m)) ]$$

And define the entropy advantage for the moving side (White, say) over Black:

$$A(P) = H(P, Black) - H(P, White)$$

A positive A(P) means Black has higher entropy than White. Black has many options, most of them roughly equal in value, while White's options are more concentrated around a few clearly good moves. This is what "White has a clear plan" looks like mathematically.

A negative A(P) means White is the one lost in complexity, which is bad.

And crucially, A(P) near zero for both sides with high individual entropy values means the position is genuinely complicated and roughly equal. A(P) near zero with low individual entropy values means both sides have limited options, which is a different kind of equal: quiet, forced, maybe drawish.

These four cases correspond to real chess categories that a single material-and-features score completely flattens:

H(White) low,  H(Black) high   --> White has initiative, Black is struggling
H(White) high, H(Black) low    --> Black has initiative, White is in trouble  
H(White) high, H(Black) high   --> Complicated, roughly equal
H(White) low,  H(Black) low    --> Simplified, forced, probably drawish or endgame

No classical eval I've ever seen gives you that four-way distinction. The standard score gives you a single number on a line, and all four of those cases can produce the same score with different meanings.

Handling Depth

One obvious problem: the entropy I defined above is computed over the immediate legal moves. That's only one ply deep. Chess is a deep game and shallow entropy might not mean much.

The solution is to recurse. Define the continuation entropy at depth d:

$$H_d(P, s) = (1 - lambda) * H_0(P, s) + lambda * E_{m ~ q} [ H_{d-1}(next(P, m), opponent(s)) ]$$

Where:

H_0(P, s) is the immediate entropy defined above
lambda is a discount factor in (0, 1) controlling how much future entropy matters
The expectation is taken under the move distribution q
next(P, m) is the position after playing move m
opponent(s) flips the side

This is a recursive definition. At depth 0, you just use the immediate move entropy. At depth d, you take the immediate entropy and blend it with the expected future entropy of the positions you'll reach.

The discount factor lambda is important. It controls how much weight you give to future positions versus the current one. High lambda means the engine is forward-looking. Low lambda means it's more focused on immediate structure.

There's a connection here to temporal difference learning in reinforcement learning: the discounted sum of future rewards. Except here the "reward" is entropy, not a win/loss signal.

In practice, computing this exactly is expensive. You can't afford to recurse deeply on every node during search. The implementation approach I'm planning uses approximations: sample a subset of continuations under the distribution q rather than exhaustively branching, cache computed entropy values in an extended transposition table, and use the shallow version at leaf nodes while using the deeper version at root and early nodes.

The Zugzwang Case, Formally

Here's how the formalism handles zugzwang. And I think it actually gets it right.

In zugzwang, any move the side to move makes is worse than passing. That means if White is in zugzwang, all of White's moves lead to positions that are better for Black. Formally, v(m) is low (bad for White) for every m in M(P, White).

In this case, the softmax distribution q over White's moves is high entropy but with all values low. All options are roughly equally bad. The entropy is high not because White has many good choices but because White has many equally terrible ones.

But the key is what this does to the entropy advantage A(P). Black, in the same position (before White moves), has options that avoid zugzwang entirely: they can play any move that maintains the zugzwang structure. Their distribution q is concentrated on those moves. H(P, Black) is low.

So A(P) = H(P, Black) - H(P, White) is large and negative: Black has low entropy (clear plan: maintain zugzwang) while White has high entropy (many moves, all bad). This correctly identifies that White is in trouble, which is exactly what zugzwang means.

A classical eval looking at the same position might see material equality and no obvious features pointing to a winner. The entropy eval sees the structure of the future and gets the right answer.

The Fortress Case, Formally

Fortress is slightly different. Say Black is a piece down (classical eval says White is winning) but Black has arranged pieces in a fortress. Any White attempt to break through fails. Black's responses to all White incursions are forced and available.

From Black's perspective: high entropy on White's side (White has many attempts) but low entropy on Black's side (Black always has the clear defensive response). From White's perspective: high entropy (many plans to try) but none of them lead to progress.

The recursive entropy captures this because at depth 1, every White move leads to a position where Black has a high-quality, clear response (low entropy for Black). White's apparent entropy is high but "fake": the moves explore lots of territory that all leads to the same dead end.

Over multiple recursive steps, the engine would learn that White's high-entropy position doesn't translate to a high-entropy advantage because Black's responses are always available and clear.

This is exactly what tablebases tell us about fortress positions, arrived at from a completely different direction.

Why CPUs, Why Classical, Why Now

I'm an engineer. I like CPUs. That's not a philosophical position, it's just what I'm interested in.

There's a version of this field that went: CPUs got fast, then we made classical engines, then we added neural nets, now GPUs do most of the interesting work. And that arc makes sense commercially and competitively. But I find myself not very interested in the GPU side of things. Not because it's wrong or unimportant, it clearly works, but because I want to see how far pure logic on a CPU can go when you change the underlying assumptions.

NNUE is extraordinary but it's also a black box. The net learns something, it improves position scores, we can verify it's better but we can't say why in any satisfying human-readable way. You can probe the activations, you can do ablation studies, but you can't look at a position and trace through why the eval is +1.3. The number comes from a matrix multiply chain that encodes everything and explains nothing.

I want to build something where the reasoning is inspectable. Where you can look at a position, ask "why does the engine think White is better here," and get an answer that points to the structure of the future: "White's moves concentrate around three forced continuations, Black has twelve roughly equal options that are all slightly bad, and the recursive entropy projects that this asymmetry grows over the next four plies."

That's a chess explanation. Not a feature sum, not a net output. An actual description of what the position does to the future.

I'm not interested in winning the GPU arms race. I'm interested in what's possible when you change the question.

What the Research Claim Actually Is

This is a research project, not just an engine project. The goal is a paper, and the paper needs a precise falsifiable claim.

The claim is: positional advantage in chess is better modeled as future option asymmetry, quantified by differential continuation entropy, than by any linear or nonlinear combination of static board features.

That's testable. I'm going to construct specific position classes where this should hold:

Zugzwang positions from endgame tablebases (ground truth: one side loses with the move)
Known fortress positions (ground truth: drawn despite material imbalance)
Quiet strategic positions from grandmaster games where one side maneuvers for 15-20 moves without material change before converting
Positions just before tactical combinations, where the entropy asymmetry should spike before the classical score changes

For each class, I'll compare the entropy eval against classical feature eval (not NNUE, that's a different comparison) and measure how well each predicts the ground truth outcome.

The hypothesis is that entropy eval will outperform classical feature eval specifically on the position types where future option structure matters most, while performing comparably elsewhere.

The target is the ICGA Journal as primary and arXiv as a preprint as soon as the theoretical framework is tight enough to stand on its own.

Where I'm Starting

First two weeks: math only. No code.

The formal definition needs to be exact before I write a single function. What exactly is the probability distribution over moves? Softmax with what temperature? Is temperature fixed or position-dependent? What counts as a "move" for entropy purposes: all legal moves, or only moves that survive a shallow quiescence search? How does the recursive depth interact with the search depth in the main alpha-beta loop? Does the transposition table store entropy values separately from eval scores, or can they be combined?

These aren't implementation questions. They're definitional. And if the math is shaky, no amount of code will fix it.

After that: engine. Probably built on top of an existing move generation library so I'm not spending six months reinventing bitboards. The novel part is the eval and the entropy computation. That's where the time goes.

The main implementation risk is computational cost. Entropy computation at each node is more expensive than a classical eval: you need to generate all legal moves, evaluate each one shallowly, compute the softmax, and compute the entropy. On a node you'd spend maybe 10x as long as a classical eval. That kills your nodes per second and limits effective search depth.

The way I'm thinking about handling this: use entropy eval only at nodes above a certain depth threshold, fall back to a fast classical eval at leaf nodes, and use the entropy estimate as a signal for search extension rather than leaf evaluation. A position with extreme entropy asymmetry gets searched deeper automatically. This is analogous to how check extensions work in standard engines: the search structure uses a cheap signal to decide where to look harder.

I don't know if this works yet. I think it does, but I've been wrong about engine ideas before. What I do know is that nobody has tried it, and after ten years in this space, that's enough reason to try.

The classical engine era ended not because it was exhausted, but because something better came along. I want to find out how much was left.

Manage Your Own Applications Without Local Hardware

Mon, 31 Mar 2025 00:00:00 GMT

Cover image source: civitai.com

What is Self Hosting?

Have you ever wondered people at Reddit - r/selfhosted/ or Selfhosted - Lemmy.World talking about ? . Yes . they are talking about self hosting . So, what exactly is self-hosting?

If you ask 10 people about self hosting, you'll likely get 10 different answers.

from wikipedia:

Self-hosting is the practice of running and maintaining a website or service using a private web server, instead of using a service outside of the administrator's own control. Self-hosting allows users to have more control over their data, privacy, and computing infrastructure, as well as potentially saving costs and improving skills.

random user from reddit:

Selfhosting means that you are running some form of application on your own premises or servers (including virtual servers). Usually it also implies Open-Source and Privacy Selfcontrol.

There aren't any requirements for selfhosting itself. You need to check the apps you want to selfhost to check that.

You can host selfhosted stuff on your own hardware or on a VPS, as far as I am concerned it's the same for most concerns in selfhosting. (If you are privacy concerned you might prefer a physical server you own at some point)

Traditionally, self-hosting implies running applications on your own physical hardware. However, in today's cloud-centric world, the definition has evolved. While strictly speaking, running applications on someone else's hardware (like AWS or Google Cloud) isn't "self-hosting" in the purest sense, it's more accurately termed "self-managed."

But why self-managed ?

Why would you choose to self-manage applications in a cloud environment instead of relying on local hardware?

Living Conditions

For many, especially those in regions with unreliable infrastructure, the cloud offers a lifeline. electricity cost, expensive hardware costs, and limited access to reliable hardware make local self-hosting a painful task. Cloud servers provide a stable and cost-effective alternative, allowing you to manage my applications without the constant worry of hardware failures or power disruptions.

Accessibility

The ability to access your applications from anywhere with an internet connection. Forget the complexities of port forwarding, static IPs, and other network configurations. Cloud platforms handle the networking, ensuring your services are always within reach.

Reliability

Cloud servers, by design, prioritize reliability. Providers invest heavily in redundant infrastructure, minimizing downtime and ensuring your applications remain available. This level of reliability is often difficult, if not impossible, to achieve with local hardware.

Reduced Maintenance

Eliminating the hardware maintenance is a significant advantage. No more worrying about power outages, physical security, or hardware failures.

Cost-Effectiveness

Especially for individuals facing high electricity bills and limited budgets, cloud self-management can be surprisingly cost-effective. The pay-as-you-go model allows you to scale resources as needed, avoiding the upfront costs and ongoing expenses associated with local hardware. This is especially true for people who live in areas with high electricity prices, where running local servers can be very expensive.

How to Get Started ?

Choose a Cloud Provider

The foundation of your self-managed cloud environment rests on your choice of cloud provider. This decision impacts everything from cost and performance to the available services and your overall experience.

Major Cloud Providers (AWS, GCP, Azure): The BIG Providers
Smaller, Specialized Cloud Providers
Renting Servers from a Cloud Provider: Infrastructure as a Service (IaaS)

The decision between major and smaller providers depends on your requirements. If you already have an account with a major provider and need its extensive ecosystem, it's a logical choice. However, if you're prioritizing cost-effectiveness, simplicity, and a more focused service offering, smaller providers are worth serious consideration.

Where to Find Smaller Providers:

To explore smaller cloud providers, here are a couple of starting points:

Select a Virtual Machine (VM)

The required specifications for your VM will depend on the applications you intend to run. For instance, a simple web server or file storage solution might function with minimal resources, while a complex database or media server will demand more power.

If you're just beginning your self-hosting journey, it's wise to start with a modest configuration. A VM with 1GB or 2GB of RAM and 1 or 2 CPU cores will likely suffice for many basic applications. This allows you to experiment and learn without incurring excessive costs.

Install Your Operating System

This step involves choosing and installing the operating system (OS) that will run on your virtual machine. Linux distributions, like Ubuntu or Debian, are popular choices due to their stability, security, and flexibility. Select an OS that you are familiar with, and that is compatible with your applications. The OS will be the base on which all your applications will reside.

Install and Configure Your Applications

Once your OS is installed, you'll install and configure the applications you want to run. This could include web servers, media servers, databases, or any other software. Follow the application's installation instructions carefully, and configure them to meet your specific needs. This is where you tailor your server to perform the tasks you want it to perform.

Set Up Security

Security is very important. Configure firewalls to restrict unauthorized access, use strong passwords, and enable SSH key-based authentication for secure remote access. Regularly update your OS and applications to patch security vulnerabilities. This step ensures that your server is safe from unwanted access, and data breaches.

Manage Backups

Implement a backup strategy to protect your data from loss due to hardware failures or accidental deletion. Schedule regular backups of your important files and databases, and store them in a secure location. This allows you to restore your server to a previous state, and recover data, if needed.

Monitor Your Applications

Use monitoring tools to track your server's performance, including CPU usage, RAM usage, and network traffic. This allows you to identify and address potential issues before they impact your applications. Monitoring helps you keep your server running smoothly, and allows you to catch problems before they become critical.

Example Applications that you can self host

Web servers - nginx,caddy
Media Servers - jellyfin,plex
Databases - mysql,postgres
Game Servers - minecraft server
Automation tools - nodered,n8n

Conclusion

In short, using cloud services to run your own applications ("self-managing") lets you skip the hassle of owning and maintaining physical hardware. It's especially useful if you have limited resources or unreliable local infrastructure.

To get started, pick a cloud provider (big or small), choose a virtual server, install your operating system, set up your applications, and make sure everything is secure and backed up. You can run all sorts of things, like websites, media servers, and databases.

Cloud self-managing gives you more control and flexibility, letting you run your digital life your way, without the headaches of traditional hardware.