Forem: Neo

JIT-Picking: Exploiting the Logic Gap in Modern JavaScript Engines

Neo — Sun, 04 Jan 2026 15:11:00 +0000

Introduction

JavaScript has evolved from a simple scripting language into the backbone of the modern web. Today’s browsers rely on massive, hyper-optimized engines such as V8 (Chrome), SpiderMonkey (Firefox), and JavaScriptCore (Safari).

To achieve native-like performance, these engines employ Just-In-Time (JIT) compilers, transforming hot code paths into optimized machine code. However, this relentless pursuit of speed has created a vast attack surface. Beyond traditional memory-safety bugs lies a quieter and more dangerous class of vulnerabilities: silent JIT miscomputations.

These logic flaws often evade conventional security oracles, yet they can be weaponized into powerful remote code execution primitives.

The Problem

Securing JIT engines is uniquely difficult because most testing methodologies are blind to semantic correctness. Traditional fuzzing strategies fall short for several reasons:

Silent Failures
A JIT optimization may incorrectly assume a variable is always a positive integer. The program continues executing but produces subtly wrong results—often eliminating bounds checks and enabling out-of-bounds memory access.
Sanitizer Blindness
Tools like ASAN instrument the engine’s C++ host code, not the dynamically generated machine code emitted by the JIT compiler.
Cross-Engine Noise
Differential testing across engines (e.g., V8 vs. JSC) produces excessive false positives due to implementation-defined behavior permitted by the ECMAScript standard (e.g., Array.sort()).

The Solution: JIT-Picking

JIT-Picking introduces a precision-focused differential fuzzing architecture by turning a JavaScript engine against itself.

Differential Oracles
The same JavaScript input is executed twice:
- Instance A: Interpreter-only mode (stable, conservative)
- Instance B: JIT-enabled mode (aggressive, optimized)
Probe Injection

The fuzzer injects calls to a custom probe_state() function, capturing the values of local variables during execution.
Execution Hashing

All probed values are serialized into a single execution hash. Any mismatch between the interpreter and JIT runs signals a miscomputation.
Transparent Probing

Probes are embedded directly into the engine’s IR (MIR/LIR) to prevent the optimizer from eliminating them—without suppressing the optimizations under test.

Technical Deep Dive

“By turning the JavaScript engine against itself, we create a domain-specific bug oracle. We no longer wait for crashes; we alert on the smallest semantic deviation.”

This approach excels at detecting bugs in loop optimizations, where logic errors may occur during intermediate iterations and disappear by program termination.

By distributing probes throughout execution rather than only at the end, JIT-Picker captures transient miscomputations that traditional fuzzers never observe.

Key Findings & Impact

A 10-month evaluation against production-grade engines revealed the effectiveness of JIT-Picking:

Engine	Total Bugs Found	JIT-Specific Bugs	Status
V8 (Chrome)	1	1	Patched
JavaScriptCore (Safari)	14	12	Patched / Reported
SpiderMonkey (Firefox)	17	14	Patched
Total	32	27	$10,000 Mozilla Bounty

The Architect’s Mandate

As software complexity increases, generic crash oracles are no longer sufficient.

For speculative, optimizing systems like JIT compilers, every miscomputation must be treated as a potential exploit primitive. The future of browser security lies in semantic-aware testing—tools that understand not just whether code runs, but how it is transformed by the compiler.

Secure browsers require treating logic correctness as a first-class security boundary.

🗣️ Discussion

With the rise of WebAssembly and increasingly aggressive JIT tiers:

Should automated differential testing become mandatory in browser CI/CD pipelines?
How would you manage the performance overhead of deep semantic probing in production-scale engines?

Let’s talk JIT security in the comments 👇

The Open Source Paradox: Decoding the Economics of Distributed Innovation

Neo — Sun, 04 Jan 2026 15:00:00 +0000

Introduction

To the traditional economist, the open-source process of production appears paradoxical. In a world where firms protect intellectual property and compensate workers to direct effort, open-source projects thrive on unpaid labor and publicly shared code.

Yet the dominance of Apache in web servers and Linux in embedded systems demonstrates that this “unconventional” model has consistently outperformed commercial giants. Open source is not an economic anomaly—it is a sophisticated system of distributed innovation and strategic signaling.

The Problem

Traditional economic frameworks assume that innovation depends on appropriability—the ability to capture returns on investment. Open source challenges this assumption on multiple fronts:

The Incentive Gap
Why would elite programmers invest thousands of unpaid hours into software they cannot sell?
The Coordination Headache
Without corporate hierarchy, how do projects avoid destructive forking or duplicated effort?
The Symbiosis Dilemma
Why would firms like IBM invest over $1 billion into software they do not own?
The Patent Thicket
How do community-driven projects survive in a litigation-heavy ecosystem dominated by software patents?

The Solution

Open source succeeds by leveraging delayed rewards, reputation markets, and complementary business models. It reframes software from a product into a signaling and service platform.

Signaling Incentives
Contributors use open source to publicly demonstrate competence. Empirical studies show that high-ranking contributors earn 14%–29% higher wages than comparable peers.
Ego and Peer Recognition
Status within elite technical communities often provides stronger motivation than short-term pay.
The “Razor and Blades” Strategy
Firms open-source the core technology (the razor) to grow demand for proprietary consulting, hosting, and support (the blades).
Adaptive Licensing
Copyleft (GPL) and Permissive (MIT/BSD) licenses allow creators to control appropriation while preserving collaboration.

Technical Deep Dive

“The open-source programmer takes full responsibility for the success of a subproject, producing high-fidelity information about their ability to execute—information far more valuable than closed-door performance reviews.”

At its core, open source operates on strategic complementarities. Developers prefer projects with large audiences because visibility maximizes career returns. This creates a powerful network effect: popular projects attract more talent, accelerating innovation and reinforcing dominance—as seen with Linux.

Key Licensing Comparison

License Type	Key Feature	Economic Impact	Best Use Case
Restrictive (GPL)	Requires derivatives to remain OSS	Prevents private capture	End-user tools, platforms
Permissive (MIT/BSD)	Allows proprietary reuse	Maximizes adoption	Libraries, kernels
Proprietary	Code is closed and owned	High short-term ROI	Niche business logic
Hybrid (MySQL)	OSS + paid commercial license	Dual revenue streams	Databases, infrastructure

The Architect’s Mandate

The shift toward open source is not about free software—it is about transparent infrastructure.

For modern technical leaders, the mandate is clear:

Treat software as a public good requiring collective maintenance
Subsidize open source to avoid vendor lock-in and patent exposure
Decide not whether to use open source, but where it delivers strategic leverage

In this model, competitive advantage moves up the stack—from ownership of code to ownership of insight, service, and integration.

🗣️ Discussion

Does your organization practice symbiotic development, or are you primarily a consumer of open source?

As career signaling shifts toward GitHub portfolios and public contributions, do you believe the traditional wage-for-labor model is losing its hold on elite engineering talent?

Let’s discuss below 👇

The Decoupled Revolution: Engineering High-Performance Front-Ends with React and Next.js

Neo — Fri, 02 Jan 2026 09:22:00 +0000

Introduction

The landscape of web development has shifted from the monoliths of the early 2010s to a decoupled architecture where the front-end is no longer a mere “view” but a sophisticated, standalone application.

Before 2015, the industry standard was a tight coupling of PHP, HTML, and CSS. Today, the demand for scalability, modular design, and instantaneous interactivity has pushed us toward a component-driven future.

Using the Indonesian State Civil Service Agency (BKN) and their SIASN application as a case study, we can see how the synergy between React.js and Next.js defines the modern standard for enterprise-grade web engineering.

The Problem

Modern web applications face a Performance Paradox. While users demand highly interactive, app-like experiences, traditional delivery methods introduce architectural bottlenecks:

The CSR Delay
Standard Client-Side Rendering (CSR) produces a “white screen” while the browser downloads and executes large JavaScript bundles.
SEO Invisibility
Search engine crawlers struggle to index pages that are empty on initial load.
State Management Bloat
Managing persistence for millions of users—such as Indonesia’s civil service—requires more than local storage; it requires a global state strategy.
Infrastructure Strain
Excessive client-side API calls can overload servers when rendering logic is poorly distributed.

The Solution

The evolution from a library (React.js) to a framework (Next.js) introduces a multi-layered solution by redistributing rendering responsibility between server and client.

Virtual DOM & Diffing
React minimizes DOM mutations by updating only the nodes that actually change.
Server-Side Rendering (SSR)
Using getServerSideProps, HTML is generated per request—eliminating the white screen and ensuring instant visibility.
Incremental Static Regeneration (ISR)
Next.js updates static pages after build time, blending static performance with dynamic freshness.
Global State with Redux
A centralized Single Source of Truth prevents state loss and simplifies debugging across complex UI flows.

Technical Deep Dive

“The shift from React to Next.js is not merely a change in tooling, but a fundamental evolution in how we distribute the cost of rendering between the server and the client. The most performant code is the code the user never has to wait for.”

The SIASN front-end follows a strict Slicing Architecture:

Reusable Components
Headers, footers, navigation, and shared UI elements.
Dynamic Layouts
Page-level containers responsible for data fetching and composition.

This enables UI/UX prototypes to be sliced directly into modular components and connected seamlessly to a REST-based backend.

Data Fetching Comparison

Mechanism	Execution Time	SEO Impact	Best Use Case
CSR (Client-Side)	Post-render (Browser)	Low	Dashboards, private user data
SSR (Server-Side)	Per-request (Server)	High	Dynamic content, SEO-critical pages
SSG (Static Gen)	Build-time	High	Blogs, documentation, static data
ISR (Incremental)	Revalidated intervals	High	E-commerce, large-scale portals

The Architect’s Mandate

The SIASN implementation highlights a core truth:

Optimization is an architectural decision, not a coding trick.

React.js provides modularity and UI efficiency, but it is Next.js that resolves initial load latency and SEO constraints at scale.

For enterprise platforms serving millions of users:

Use SSR where data is volatile
Use SSG/ISR where performance is paramount

🗣️ Discussion

Are you still relying on pure Client-Side Rendering, or have you transitioned to a server-side framework?

What was the biggest hurdle you faced when moving from a library to a full-stack framework like Next.js?

Let’s discuss in the comments 👇

The Data Liberation: Amazon Athena and the Architecting of a Serverless Future

Neo — Thu, 01 Jan 2026 20:34:00 +0000

For the better part of three decades, the enterprise relationship with data has been defined by a paradox of scarcity amidst plenty. While the volume of data generated has grown exponentially, our ability to derive meaning from it remained tethered to the physical constraints of the data warehouse.

As the Amazon Athena API Reference makes clear, we have moved beyond the era of the "Infrastructure Mirage." This isn't just a technical manual; it is a manifesto for the final transition of data analysis from a maintenance burden to a utility-grade service.

Part I: The Infrastructure Mirage and the Crisis of Scale

In the traditional model, to analyze data, you first had to build a home for it. This meant hardware procurement, cluster configuration, and perpetual performance tuning.

Athena fundamentally redefines the "Backend" as an invisible, on-demand force through the Decoupling Revolution:

Schema-on-Read: Unlike traditional databases that require "Schema-on-Write" (forcing data into rigid structures via ETL), Athena enables analysis of raw data sitting in Amazon S3.
Efficiency through Non-Movement: By utilizing the StartQueryExecution action, organizations query petabytes without moving a single byte into a proprietary engine.
The Intelligent Layer: API actions like CreateDataCatalog and GetTableMetadata act as a thin layer over oceans of raw storage, providing structure only when logic demands it.

Part II: The API as an Orchestrator of Agility

The true power of Athena lies in the granular control offered by its Actions list. This is an ecosystem built for Autonomous Analytics.

Programmatic Intelligence

Unlike a SQL console where a human manually enters commands, the Athena API allows backend systems to trigger queries based on external events—such as a new log file appearing in S3.

The Democratization of the Query

By adopting standard SQL (Presto/Trino engines), AWS ensured the "learning tax" is near zero.

BatchGetNamedQuery: For high-volume retrieval.
CreatePreparedStatement: For reusable, secure logic.
The Result: Any analyst who understands a SELECT statement is now, through the API, a Big Data Engineer.

Part III: The Economic Sovereignty of Pay-Per-Query

Perhaps the most persuasive argument for Athena is its financial architecture. In a traditional backend, you pay for "Idle Costs"—CPU cycles running even when no queries are active.

Zero-Floor Cost: If you don't call the API, your cost is zero. This gives a startup the same analytical power as a MAANG company.
WorkGroups (CreateWorkGroup): Allows enterprises to track costs with surgical precision across departments.
Capacity Reservations: For the skeptics of serverless performance, CreateCapacityReservation allows for dedicated DPUs (Data Processing Units) for critical workloads, blending the best of fixed and variable costs.

Part IV: Security, Governance, and the Managed Backend

Any enterprise-grade technology must address the "Big Three": Security, Reliability, and Scalability.

"The backend is no longer a 'black box'; it is a transparent, audited environment."

Granular Governance: Isolated WorkGroups ensure one rogue query doesn't consume all resources.
Stateless Resilience: Athena queries are independent. A failure doesn't crash a database; it returns an error code. The API handles retries, scaling, and memory management automatically.
Auditability: Every action is tracked via Signature Version 4, providing a complete trail for compliance teams.

Part V: The Spark Integration – Beyond Relational Data

The inclusion of CreateNotebook and StartCalculationExecution signals Athena’s evolution into the realm of Apache Spark.

Athena is no longer just for SQL analysts; it is for Python developers and data scientists. By providing a serverless Spark environment, the API commoditizes the most difficult parts of data science infrastructure—allowing for machine learning and graph analysis without managing an EMR cluster.

Conclusion: The Architect’s Mandate

The Amazon Athena API Reference is a map of a new world—one where the backend is defined by the efficiency of the requests we send, not the hardware we manage.

To choose Athena is to make three strategic bets:

Bet on S3: Storage should be cheap, durable, and separate from compute.
Bet on SQL: Standard languages outlive proprietary ones.
Bet on Serverless: An engineer’s most valuable asset is their time, not their ability to configure a Linux kernel.

Ultimately, Athena provides the scale of a supercomputer with the interface of a simple web service. It doesn’t just answer queries; it answers the fundamental challenge of the information age: how to turn infinite data into infinite value.

What are your thoughts on the Serverless Data Lake? Are you moving away from traditional warehouses toward a Schema-on-Read architecture? Let's discuss in the comments!

The Geometry of Stability: Why Manifold-Constrained Hyper-Connections Are the Future of Large-Scale AI

Neo — Thu, 01 Jan 2026 20:15:00 +0000

For nearly a decade, the residual connection has been the silent heartbeat of deep learning. Since the introduction of ResNets, the simple act of adding an input to a layer’s output has allowed neural networks to grow deeper, more stable, and more capable.

However, as we push toward the next generation of foundational models, this classic paradigm has reached a crossroads.

The Evolution: From Residuals to Hyper-Connections

Recently, a breakthrough known as Hyper-Connections (HC) suggested that we could achieve massive performance gains by widening this residual stream. But as a seminal paper from DeepSeek-AI reveals, this complexity comes at a cost: training instability and a breakdown of the mathematical "identity mapping" that keeps models from collapsing.

The solution? Manifold-Constrained Hyper-Connections (mHC). It represents a critical evolution in architecture, proving that the path to more powerful AI lies not just in adding complexity, but in constraining it through elegant geometry.

The Problem: The "Unbounded Signal"

In a standard residual network, the signal is preserved as it moves through layers. When Hyper-Connections were introduced, they allowed for multiple parallel streams and learnable "mixers" between them.

While this increased the model's plasticity (its ability to learn complex patterns), it destroyed the mathematical conservation of the signal:

The Scale Issue: In unconstrained HC, signals can grow exponentially.
The DeepSeek Discovery: In 27B parameter models, unconstrained connections can lead to a gain magnitude of 3000.
The Result: Exploding gradients, loss surges, and total training failure.

To build bigger models, we cannot simply let the math run wild; we need a mechanism that allows for information exchange without sacrificing structural integrity.

The Innovation: The Birkhoff Polytope

The brilliance of mHC lies in its application of the Birkhoff polytope. Rather than allowing the "mixers" in the residual stream to be arbitrary matrices, mHC projects them onto a manifold of doubly stochastic matrices.

How it works:

The Constraint: Every row and column in the connection matrix must sum to exactly one.
The Tool: This is achieved using the Sinkhorn-Knopp algorithm.
The Result: The architecture effectively functions as a convex combination of signals, ensuring the "mean" of the features is conserved across the network.

This constraint restores the identity mapping property, allowing the model to enjoy the benefits of expanded width while maintaining the rock-solid stability of a traditional ResNet.

Engineering the "Free Lunch"

Critics often argue that rigorous mathematical constraints introduce "system overhead." However, DeepSeek’s implementation proves that stability doesn’t have to come at the expense of efficiency.

Through two key engineering feats, the framework achieves a marginal time overhead of only 6.7%:

Kernel Fusion: Consolidating mathematical operations to reduce GPU memory bottlenecks.
DualPipe Scheduling: Optimizing communication across parallel compute nodes.

"In the world of high-performance computing, mHC offers a rare 'free lunch': superior stability with negligible cost."

Empirical Evidence: Scaling to 27B

The data from DeepSeek’s 27B parameter trials confirms that mHC isn't just a theoretical improvement—it’s a functional necessity for the next generation of LLMs.

Metric	Standard Baseline	Unconstrained HC	mHC (DeepSeek)
BBH (Reasoning)	Base Level	(Unstable)	+2.1%
MMLU	Base Level	(Unstable)	Significant Gain
Stability	High	Low (Loss Surges)	Rock Solid

Specifically, mHC completely mitigated the "loss surges" that plagued earlier iterations, showing that the Birkhoff constraint is the key to scaling beyond the current horizon.

Conclusion

Manifold-Constrained Hyper-Connections represent a paradigm shift in how we think about neural architecture. By moving away from unconstrained "macro-designs" and embracing the disciplined geometry of the Birkhoff polytope, mHC provides the blueprint for the next generation of foundational models.

The lesson of mHC is clear: The most powerful systems are those that find the perfect balance between the freedom to learn and the mathematical constraints that ensure they never break.

If you're interested in the intersection of geometry and deep learning, you can read the full DeepSeek-AI technical report on their latest mHC implementation.

Most orgs do not use zero trust model, costing them millions.

Neo — Mon, 26 Dec 2022 16:07:05 +0000

Cybercrime remains a major threat to individuals, businesses, and governments around the world. Leaked credentials will continue to be the main attack vector for initial access. As the internet of things continues to develop, cybercriminals will have access to a greater number of vulnerable devices. 59% of organizations don't deploy zero-trust, incurring an average of 1 million USD in greater breach costs. Cybercrimes such as DDoS, malware, and ransomware are all offered as subscription services, lowering the entry barrier into cybercrime.

The proliferation of crypto payment platforms makes it even easier to trade in cybercrime products and services. Lapsus$, a UK teen group that went on a hacking spree targeting tech titans, were "doing it for the lulz". LAPSUS$'s modus operandi was based on a text-book sim swapping scam. They bought credentials of someone with the right access to resources within an enterprise, called the phone provider, reported the phone stolen, rerouted the sim to their own phone, triggered multi factor authentication on an enterprise access point, and did a password reset. It was ridiculously simple and devastatingly efficient.

The cybersecurity workforce gap compelled enterprises to outsource this part of their cybersecurity to a managed detection and response (MDR) service. Global MDR market size is expected to grow from an estimated value of 2.6 billion USD in 2022 to 5.6bn USD by 2027.

AI assistance produce less secure code than those who fly solo.

Neo — Mon, 26 Dec 2022 15:50:53 +0000

Computer scientists from Stanford University have found that programmers who accept help from AI tools like Github Copilot produce less secure code than those who fly solo. They also found that AI help tends to delude developers about the quality of their output. An NYU study has shown that AI-based programming suggestions are often insecure in experiments. The results of a Stanford study are inconclusive as to whether artificial intelligence (AI) assisted or harmed developers. Participants were asked to write code in response to five prompts using a React-based Electron app monitored by the study administrator.

The authors conclude that AI assistants should be viewed with caution because they can mislead inexperienced developers and create security vulnerabilities. At the same time, they hope their findings will lead to improvements in the way AI assistants are designed for use in the field of computer programming.