Forem: Figsy

Elixir Comprehensions: Learn Enough to be Dangerous

Figsy — Sat, 18 Apr 2026 23:50:34 +0000

When you first encounter a for comprehension in Elixir, it looks like a standard loop. But Elixir doesn't have traditional for loops. Instead, comprehensions are powerful pipelines for iterating, filtering, and transforming data all at once.

To master comprehensions, we need to understand their anatomy. Let's look at the basic blueprint, and then scale it up to the advanced, infinite chain.

1. Simple Comprehension (like a simple `Enum.map`)

The absolute simplest comprehension has one <generator> and an <expression>.

for <generator> do <expression> end

Or, in its single-line form:

for <generator>, do: <expression>

Example:

nums = [1, 2, 3]
for x <- nums do
  x * 10
end
# Result: [10, 20, 30]

for x <- nums, do: x * 10
# Result: [10, 20, 30]

Think of it like a simple Enum.map:

nums = [10, 20, 30]
Enum.map(nums, fn num -> num * 10 end)
# Result: [10, 20, 30]

# Or

Enum.map(nums, & &1 * 10)
# Result: [10, 20, 30]

2. Adding Filters

You can add a <filter> immediately after your <generator> to discard items you don't want. You aren't limited to just one; you can add multiple <filter>s in a row.

for <generator>, <filter>, <filter> do
  <expression>
end

As long as every <filter> evaluates to "truthiness" (anything other than false or nil), the comprehension continues to the next step. If any <filter> evaluates to false or nil, the item is immediately skipped.

🤔 How does Elixir know it's a <filter>?

Elixir figures it out by process of elimination. If an expression in your comma-separated list
(1) doesn't have an <generator> arrow (<-),
(2) isn't a predefined option (like into:, uniq:, or reduce:),
(3) and isn't the do block,
Elixir automatically treats it as a <filter>!

result = for x <- 1..10, rem(x, 2) == 0, x > 5 do
  x * 10
end
# Result: ~c"<Pd"

IO.inspect(result, charlists: :as_lists)
# Result: [60, 80, 100]

If IEx sees a list where every single number is a printable character, it tries to be "helpful" by printing it as a string of characters (prefixed with ~c).
Because 60, 80, and 100 all fall within the "printable" range, Elixir shows you <Pd instead of the numbers.

3. Adding Options

You can also add <options> at the very end of your setup (just before the do block) to change the behavior of the loop or format the final output.

for <generator>, <option> do <expression> end

🤔 How does Elixir recognize <option>s?

Unlike <generator>s (which use <-) or <filter>s (which are arbitrary expressions), <option>s are recognized because they belong to a strictly predefined set of keywords built into the Elixir language. The most common ones are into:, uniq:, and reduce:.

For example, using the predefined into: keyword turns the output from a standard list into a map:

for x <- [1, 2, 3], into: %{} do
  {x, x * 10}
end
# Result: %{1 => 10, 2 => 20, 3 => 30}

We can mix and match <option>s (more than one) to change how data is collected. However, not all <option>s play well together.

The most common combination is using into: and uniq: together.

for n <- [1, 1, 2, 2, 3], uniq: true, into: %{} do
  {n, n * n}
end
# Result: %{1 => 1, 2 => 4, 3 => 9}

reduce: is the "lone wolf". You cannot combine reduce: with into: because they are two different ways of handling the accumulation.

words = ["apple", "banana", "apple", "cherry", "banana", "apple"]

for word <- words, reduce: %{} do
  acc -> Map.update(acc, word, 1, & &1 + 1)
end
# Result: %{"apple" => 3, "banana" => 2, "cherry" => 1}

for <generator>, reduce: <initial_accumulator> do
  <current_accumulator> -> <new_accumulator>
end

In the reduce: case, Elixir swaps the default collection behavior for a manual accumulation process.

<initial_accumulator>:

We provide an initial value (like 0, [], or %Base{}) which acts as the starting state for the accumulator.

<current_accumulator> -> <new_accumulator>:

Instead of the do block simply returning a value to be added to a list, it acts as a reducing function that takes the current accumulator on the left side of the -> arrow.
Whatever the expression on the right side returns becomes the new state of the accumulator for the very next iteration.
Elixir skips the do block entirely and passes the unchanged accumulator forward, ensuring that by the time the <generator> is exhausted, you are left with a single, final value.

4. Adding Filters + Options

Before jumping into Complex Chain, let's combine these concepts. You can shape the data with a <filter> and change the output format with an <option>:

for <generator>, <filter>, <option> do <expression> end

Here are some examples that walk through the increasing complexity of Elixir comprehensions:

Example 4.1.

for n <- [1, 1, 2, 2, 3, 4], # generator
  rem(n, 2) == 0, # filter: find even numbers
  uniq: true, # option: remove duplicates
  do: n * 10 # expression
# Result: [20, 40]

In this example, we use one <filter> to find even numbers and the uniq: true option to remove duplicates.

Example 4.2.

for n <- 1..10, # generator
  rem(n, 2) == 0, # filter: find even numbers
  n > 5, # filter: find numbers > 5
  into: %{}, # option: collect the results in a Map
  do: {n, "Number #{n}"}
# Result: %{6 => "Number 6", 8 => "Number 8", 10 => "Number 10"}

Here, we use two <filter>s to narrow down the list before collecting the results into a Map.

Example 4.3.

for n <- [2, 4, 6, 8, 8, 10, 12], # generator
  n > 5, # filter: find numbers > 5
  n < 11, # filter: find numbers < 11
  uniq: true, # option: remove duplicates
  into: [], # option: collect the result in a List
  do: n * 2
# Result: [12, 16, 20]

This shows the uniq: and into: working together. It filters the data and ensures the destination collection only receives unique keys.

Example 4.4.

for x <- [1, 2], # generator 1
  y <- [10, 20], # generator 2: every single x, it will try every possible value of y
  x + y > 12, # filter 1
  y < 25, # filter 2
  reduce: 0, # option
  do: (acc -> acc + x + y)

# Result: 43

5. The Complex Chain

The true power of Elixir comprehensions lies in the Complex Chain. A comprehension isn't limited to just one <generator> or one <filter>. You can string together as many steps as you want, in almost any order.

The blueprint can take many forms depending on how you want to process your data. You can group all your data extraction first, followed by all your filtering:

for <generator>, <generator>, <generator>,
    <filter>, <filter>, <filter>,
    <options> do 
  <expression> 
end

Or, you can interleave them step-by-step (which is highly recommended for performance):

for <generator>, <filter>,
    <generator>, <filter>,
    <generator>, <filter>,
    <options> do 
  <expression> 
end

As long as you start the entire comprehension with at least one <generator>, you can mix and match <generator> and <filter> combinations infinitely!

6. How Elixir Decodes the Syntax (The Clues)?

With so many possible combinations, looking at a massive block of for code can be intimidating. How does the engine know which part is a <generator> and which is a <filter>?

Elixir's compiler reads it very simply. It looks for specific "clues" in your comma-separated list to know exactly what a piece of code is supposed to do, regardless of the order you place them in:

Clue	Description
The `<-` symbol	If an element has an arrow, it is a `<generator>`. It means "pull data from this collection".
Known Keywords (`into:`, `uniq:`, `reduce:`)	If an element uses one of these keys, it is an `<option>`. It configures the final output.
The `do:` or `do` keyword	This marks the end of the setup and the beginning of the `<expression>` (what you want to return for each item).
Everything Else	If an element doesn't have an arrow (`<-`), isn't an `<option>`, and isn't the `do` block... it is a `<filter>`.

7. Execution Flow

Because Elixir uses these simple clues, you don't have to put all <generator>s first and all <filter>s last. You can interleave them.

Let's look at how Elixir processes the chain: <generator 1>, <filter 1>, <generator 2>, <filter 2>

Generator 1 pulls the first item.
Filter 1 evaluates that item. (a) If the <filter>'s truthiness is false or nil, Elixir throws the item away, skips the rest of the chain, and asks Generator 1 for the next item. (b) If it evaluates to truthy (e.g., true, a number, a string), it passes the gate.
Generator 2 is now triggered. Because it sits after Generator 1, it runs a full loop for every single item that survives Filter 1. This creates a nested loop, also known as a Cartesian Product.
Filter 2 evaluates the combined result of Generator 1 and 2.

Example 7.1. Finding valid mixed colors from RGB channels

for r <- [0, 255], g <- [0, 255], b <- [0, 255], # 3 Generators Grouped
  r + g + b > 0, # Filter 1: No pure black
  r + g + b < 765 do # Filter 2: Nor pure white
    {r, g, b} 
  end
# Result: [{0, 0, 255}, {0, 255, 0}, {0, 255, 255}, {255, 0, 0}, {255, 0, 255}, {255, 255, 0}]

This approach is useful when you need to calculate the entire Cartesian product first before you have enough context to filter it.

Example 7.2. Finding senior staff on high-performing teams at profitable companies.

companies = [
  %{
    name: "TechCorp",
    profit: 100_000,
    teams: [
      %{
        name: "Alpha",
        rating: 5,
        members: [
          {:senior, "Alice"},
          {:junior, "Bob"}
          ]
      }
    ]
  },
  %{
    name: "BankInc",
    profit: -50_000,
    teams: []
  } # Unprofitable company
]

for company <- companies,
    company.profit > 0, # Filter 1: Skip losing companies instantly
  team <- company.teams,
    team.rating >= 4, # Filter 2: Skip low-rated teams instantly
  { role, member_name } <- team.members,
    role == :senior do # Filter 3: Only keep senior members
  "#{member_name} from #{team.name} at #{company.name}"
  end
# Result: ["Alice from Alpha at TechCorp"]

This is where Elixir shines. By placing a <filter> immediately after its relevant <generator>, you prune bad branches early. If a company isn't profitable, Elixir skips iterating over its teams entirely!

As long as you start the entire comprehension with at least one <generator>, you can mix and matchand` combinations infinitely!

to be continued...

Is the Internet a Junkyard?

Figsy — Wed, 08 Oct 2025 21:18:44 +0000

The internet was once seen as a new frontier for creativity and original ideas. Today, many people describe it differently: as a junkyard or an echo chamber, where the same ideas are repeated over and over. Let's explore the idea that the internet is in a state of decline, constantly recycling its own content, which leads to a drop in quality and originality.

This didn't happen overnight. It's the result of changes in technology and culture over the last 3 decades.

The Early Web (1990s - early 2000s): This was a time of passion projects. People created websites about their hobbies and interests because they wanted to share them with small, like-minded communities. Originality was natural because the web was new and not yet commercialized.
The Rise of Social Media (mid-2000s): Platforms like Facebook, YouTube, and blogs made it easy for anyone to create content. But this also meant that a few large companies started to control where and how people shared information. The goal shifted from personal expression to getting likes, shares, and followers.
The Age of Google (2010s - 2022): Getting to the first page of Google search results became the most important goal for many creators. This led to a new way of making content called Search Engine Optimization (SEO). Instead of coming up with new ideas, people began to copy what was already popular, creating slightly different versions of the same articles and lists. We can call this the "human copy machine" 😉 phase.
The AI Flood (2022 - Today): Artificial Intelligence (AI) can now do the job of the "human copy machine" but thousands of times faster and cheaper. This has flooded the internet with AI-generated content, creating a serious problem: AI models are now learning from other AI content, which can cause them to get progressively worse over time.

Characteristic	Phase I: The Early Web (1990s – early 2000s)	Phase II: The Rise of Social Media (mid-2000s)	Phase III: The Age of Google (2010s – 2022)	Phase IV: The AI Flood (2022 – Today)
Why People Created	To share passions and build communities	To get likes, go viral, and make money	To rank high on Google and get traffic	To create content automatically and cheaply
Where People Created	Personal websites, forums	Blogs, social media, video sites (like Blogger, Facebook, YouTube)	Search engines, large content websites	AI tools like ChatGPT
Creator-Audience Link	Direct, small, niche groups	Interactive, community-focused	Controlled by algorithms, business-like	Distant, no real relationship
Key Technology	HTML, dial-up internet, early browsers	Social media platforms, high-speed internet	Search algorithms, analytics tools	Artificial Intelligence (AI), Large Language Models (LLMs)
Typical Content	A personal homepage, a fan site, a forum discussion	A blog post, a viral video, a social media profile	A “how-to” guide for Google, a list article (“listicle”)	An AI-written article, an AI summary, a deepfake video

The Internet Starts to Eat Itself (c. 2022-Present)

The current era of Artificial Intelligence (AI), which took off with the release of tools like ChatGPT in late 2022, is the logical conclusion of the previous phase (The Age of Google). AI models are extremely good at the exact task that SEO taught human writers to do: analyze huge amounts of existing text and create a new summary of it. The only difference is that an AI can do it in seconds, for almost no cost.

The result has been a massive flood of AI-generated, or "synthetic" content.

A 2025 study of 900 thousand new web pages found that nearly 75% of them had at least some AI-generated content.

The amount of AI content in the top 20 Google search results has grown dramatically, from around 2% in 2019 to nearly 20% by mid-2025.

Some experts now believe that 90% of all online content could be generated by AI as early as 2025.

AI slop

This flood of AI content is making the internet a less reliable place. The web is being filled with what some call "AI slop": generic, repetitive, and often boring content that lacks any real human insight or experience.

This has made services like Google search less useful. Around mid-2024, reports of several incidents highlighted a growing problem with internet search quality. Many users expressed frustration that services like Google had become less useful, with search results increasingly cluttered by low-quality, AI-written websites created only for ad revenue.

Even Google's own AI-powered summaries have given dangerously wrong answers, like telling people to put glue on pizza or to eat rocks. This erodes the trust we have in the internet as a source of good information.

Model Collapse

The biggest long-term threat is a problem called "model collapse". This is a feedback loop where new AI models are trained on the low-quality AI content created by older models. It's like making a photocopy of a photocopy; each new copy gets blurrier and less clear.

As AI models learn from other AI-generated text, they start to forget the diversity and richness of real, human-created information. Researchers have found this happens in two stages:

First, the models forget rare or unusual information. They learn the most common patterns, which makes their output very generic.
As the cycle continues, the models' understanding of the world becomes distorted. Their output becomes a flat, boring copy of a copy.

This process is polluting the internet's knowledge base. The web, which was the main source of training data for AI, is now being contaminated by AI's own output. This has led some researchers to see all data created before 2022 as a precious, "uncontaminated" resource.

Some experts still believe the fears of "model collapse" are exaggerated and can be seen as a "doomsday fear".

This article explains that while model collapse (where AI models trained on other AI-generated data lead to a decline in quality) is a real concern, some experts argue that the most severe predictions are unlikely to happen in the real world. With proper management and a continued emphasis on using high-quality, human-generated data, the most catastrophic outcomes can be avoided.

The goal of content creation is shifting. It's no longer about informing a human, but about creating a massive amount of content as cheaply as possible to fill up digital space and be seen by search engines. This turns the web into a giant, automated content farm.

Model collapse is a serious threat. The internet has been our collective memory. If that memory becomes corrupted by endless, degrading copies, we could enter a new kind of digital dark age, where finding true, original knowledge becomes nearly impossible because it's buried under a mountain of synthetic junk.

Human Creativity in the Age of AI

The rise of AI presents two main challenges to human creativity.

Economic Threat: For many jobs, like writing marketing copy or making simple graphics, AI can now produce "good enough" content much faster and cheaper than a human. As businesses look to save money, many creative professionals could lose their jobs, which might mean less human creativity overall.
Direct Threat:AI could one day become more creative than humans. However, for now, AI has major limitations. AI creativity is just very good pattern-matching. It doesn't come from real understanding or life experience.

AI lacks the key things that make human creativity special, such as

AI cannot feel joy or sadness, nor can it have the sudden flashes of insight that lead to great art.
AI doesn't understand culture or social situations in the way humans do.
AI can only remix what it has learned from its training data. It can't create something completely new from a unique personal vision.

AI as a Creative Partner

This leads to a more positive view: AI not as a replacement, but as a powerful assistant that can help humans be more creative.

In this partnership, AI can do the boring work and spark new ideas.

Do the Boring Work

Every creative project has tedious tasks. AI can handle things like basic research, cleaning up audio, or drafting simple text. This frees up human creators to focus on the artistic vision and emotional heart of the work.

Spark New Ideas

By mixing ideas in unexpected ways, it can give creators a starting point for something new. For example, Musicians use AI to generate new musical phrases that they then arrange into a finished song that reflects their human vision. Visual artists use tools like DALL-E to quickly test out different ideas and styles. Humans switch from being creators to curators.

The New Value of Authenticity

In a world flooded with fake and generic AI content, things like authenticity, real expertise, and genuine human experience are becoming more valuable than ever. The content that AI can't create (i.e. personal stories, unique insights from real life, and a distinct point of view) will be what people seek out and are willing to pay for.

The internet's content will likely split into two tiers. At the bottom will be a huge amount of cheap, mass-produced AI content. At the top will be a premium level of authentic, human-made content that focuses on originality and emotional connection.

In this new world, the most important skill for a creator won't just be making things, but having good taste and a strong vision. The successful creator will be someone who can use AI as a powerful assistant to generate ideas, but then use their uniquely human judgment to shape that raw material into something truly meaningful and authentic.

Conclusion

The Story So Far

The internet is now feeding on itself, risking a future where information quality continues to decline. It has become difficult to tell the difference between something made by a human and something made by a machine.

A New Solution?

In this new reality, we need a way to trust what we see online. The first idea was to build AI content detectors, but these are in a constant battle with AI models designed to trick them. A better, more lasting solution is not to just find what's fake, but to prove what's real. This is the idea of content provenance: creating a clear, verifiable record of where a piece of content came from.

A group of major tech and media companies, including Adobe, Microsoft, and the BBC, have already created an open standard for this, called the Coalition for Content Provenance and Authenticity (C2PA).

This system works through something called Content Credentials, which act like a secure "nutrition label" for digital content.

An Example: Here's how C2PA works

When a photo is taken or a file is created, the creator can attach Content Credentials. This is a secure piece of information that is cryptographically signed ("label"), so you can tell if it's been tampered with.
This "label" contains key information, such as who created the content, what tools were used (including if AI was involved), and a history of any changes made to it.
Companies like Leica, Nikon, and Canon are building this technology directly into their cameras. Software companies like Adobe are also including it in their tools, and you will start to see a "cr" icon on content that has these verifiable credentials.

The Future of a More Trustworthy Internet

The internet may feel like a junkyard, but we are not without hope. The way forward is to give people the tools to tell the difference between real and fake. Content provenance standards like C2PA do just that. They allow us to ask important questions about the content we see (i.e. who made this? how was it made?) and get trustworthy answers. This helps real human creators prove the authenticity of their work and stand out from the sea of AI-generated media.

The future of originality online won't be about banning AI, but about building a new culture of verification. By using these tools, we can move from a world of doubt to one where we can trust what we see, ensuring that even in the junkyard, the real treasures can still be found.

Anatomy of a Supply Chain Heist: The Day 'chalk' and 'debug' Became Crypto-Thieves

Figsy — Tue, 09 Sep 2025 21:08:23 +0000

Every day, millions of developers type a simple, almost reflexive command into their terminals: npm install. It’s the foundational act of modern web development, a gateway to a universe of open-source tools that make building complex applications possible. But this routine command, a gesture of implicit trust in a global community, can sometimes open a door to unseen threats. On September 8, 2025, this trust was weaponized in one of the most significant supply chain attacks in recent history, turning ubiquitous, "boring" packages like chalk and debug into silent crypto-thieves.

This incident was not a flaw in the code of these packages but a hijacking of the trust placed in their maintainer. A single, well-crafted phishing email set off a chain reaction that compromised packages with a combined total of over ~two billion weekly downloads, sending shockwaves through the entire JavaScript ecosystem.

The Attack: 🤔 How One Phishing Email Compromised Billions of Downloads?

The effectiveness of this supply chain attack hinged not on a complex zero-day exploit, but on the meticulous exploitation of the most vulnerable part of any security system: the human element. The attackers targeted a single, highly trusted individual to gain a foothold in an ecosystem used by millions.

🎯 The Target: A Respected Developer

The developer at the center of this incident was Josh Junon, a prolific and respected open-source contributor known by the handle qix. With over ~1,800 contributions on GitHub in the past year alone, Junon was the trusted maintainer of dozens of foundational npm packages. These were not obscure libraries; they included utilities like chalk (for terminal text styling), debug (a debugging tool), and strip-ansi (for removing ANSI escape codes), which are transitive dependencies in countless popular frameworks and applications. Combined, the affected packages accounted for a staggering ~2.6 billion weekly downloads, establishing the immense potential blast radius for any compromise.

🧲 The Lure

The attack began with a phishing email. The message was sent from the domain support@npmjs.help, a convincing lookalike of the official npmjs.com domain. This fraudulent domain npmjs.help had been registered at porkbun.com just three days before the attack, a clear sign of a premeditated and targeted operation rather than an opportunistic one.

The email's content was a masterclass in psychological manipulation, employing classic social engineering tactics to bypass the recipient's natural caution. It created a sense of urgency and fear, falsely claiming that Junon's account would be locked within 48 hours if he did not update his Two-Factor Authentication (2FA) credentials, which the email alleged were over 12 months old. According to Junon himself, the email looked "very legitimate". The attack's success was aided by circumstance; Junon was on his mobile device during a busy week, a common scenario where individuals are more likely to let their guard down. He later candidly acknowledged the compromise on platforms like HackerNews, stating, "Hi, yep I got pwned... Sorry everyone, very embarrassing".

🪄 Bypassing 2FA

Crucially, the attack was not a simple credential theft; it was designed to defeat the very 2FA protection that developers are urged to use. The phishing site was not just a static form but an active Adversary-in-the-Middle (AitM), acting as a proxy between the Junon (the victim) and the real npm service. This technique bypasses many common forms of MFA by hijacking the authenticated session itself.

The process unfolded in real-time:

Junon visited the fake site (npmjs.help) and entered his username and password
The "AitM" proxy immediately forwarded these credentials to the legitimate npmjs.com login service.
The real npm site responded with a challenge for a 2FA token.
npmjs.help (the fake site) mirrored this prompt, asking Junon for his Time-based One-Time Password (TOTP) code.
Junon entered the live 2FA code from his authenticator app into the fake site.
The proxy passed this valid, time-sensitive token to the real npm site, successfully completing the login process.
The attacker, sitting in the middle, intercepted the resulting session cookie. This token granted them full, authenticated access to Junon's account, rendering his password and 2FA device irrelevant for the duration of the session.

This method highlights a critical vulnerability in authentication security. While MFA methods like TOTP codes and SMS messages are effective against simple password theft, they are not phishing-resistant. An "AitM" attack doesn't break the cryptography of 2FA; it tricks the user into authenticating on the attacker's behalf. True phishing resistance requires standards like FIDO2/WebAuthn, which cryptographically bind the authentication process to the specific domain origin, making it impossible for a proxy on a different domain to relay the sign-in attempt.

Once they had control, the attackers immediately changed the email address associated with the npm account, temporarily locking Junon out and giving them a window to publish their malicious packages.

What exactly is FIDO/WebAuthn?

Passwordless authentication is a growing trend in IT security that seeks to replace weak passwords with more secure alternatives, enhancing both user experience and protection.
At its core is WebAuthn, an API created by the W3C and FIDO Alliance, which allows users to register and authenticate using public key cryptography, generating unique private-public key pairs (credentials) often associated with biometric authenticators like 'Windows Hello" or "Apple’s Touch ID".
The FIDO Alliance is responsible for developing technical standards for non-password authentication based on public-key cryptography and certifying interoperable solutions.
CTAP (Client to Authenticator Protocol), a specification from the FIDO Alliance, outlines how applications and operating systems interact with authentication devices, with CTAP2 being essential for FIDO2.
FIDO2 merges WebAuthn and CTAP2 to deliver strong passwordless authentication through devices capable of biometrics or security keys.
This approach greatly enhances security by employing unique key pairs for each application, relying on inherence (biometrics) and possession (registered device) factors instead of shared secrets, thus reducing the risks of phishing, stolen credentials, and man-in-the-middle attacks.

Rapid Detection and Response

Despite its sophistication, the attack had a very short lifespan thanks to the vigilance of the security community.

September 8, 2025, ~13:16 UTC: The malicious versions of ~18 packages were first published to the npm registry. Security firm "Aikido" Security's automated intelligence feed flagged the suspicious updates almost immediately and alerted Junon via the social network Bluesky.
September 8, 2025, ~15:15 UTC: Less than two hours after the first malicious publish, Junon had confirmed the compromise and begun the cleanup process.
September 8, 2025, ~17:17 UTC: npm had officially acknowledged the breach and was working to remove the tainted packages from the registry.

This rapid, community-driven response was instrumental in containing the damage from what could have been a far more catastrophic incident.

Package Name	Malicious Version	Approx. Weekly Downloads
ansi-regex	6.2.1	~243 million
ansi-styles	6.2.2	~371 million
backslash	0.2.1	~260,000
chalk	5.6.1	~300 million
chalk-template	1.1.1	~3.9 million
color	5.0.1	~27 million
color-convert	3.1.1	~193 million
color-name	2.0.1	~191 million
color-string	2.1.1	~27 million
debug	4.4.2	~357 million
error-ex	1.3.3	~47 million
has-ansi	6.0.1	~12 million
is-arrayish	0.3.3	~73 million
simple-swizzle	0.2.3	~26 million
slice-ansi	7.1.1	~59 million
strip-ansi	7.1.1	~261 million
supports-color	10.2.1	~287 million
supports-hyperlinks	4.1.1	~19 million
wrap-ansi	9.0.1	~198 million

The Weapon: A Deep Dive into the Crypto-Clipper Malware

The payload injected into the compromised packages was a highly specialized piece of malware known as a crypto-clipper. It was designed with a singular purpose: to steal cryptocurrency by intercepting and redirecting transactions in the victim's browser.

🥷 What is a Crypto-Clipper? The Digital Pickpocket Analogy

At its core, clipper malware, also known as "cryware" or a "ClipBanker," is a digital thief that exploits the copy-and-paste function. Imagine writing down a friend's bank account number on a slip of paper to make a transfer. As you hand the slip to the bank teller, a pickpocket deftly swaps it with another slip containing their own account number. You complete the transfer, oblivious to the change, and the money goes to the thief.

A crypto-clipper does this digitally. It silently monitors the device's clipboard, waiting for the user to copy a long, complex cryptocurrency wallet address. When it detects one, it instantly replaces it with an address belonging to the attacker. When the user pastes the address to initiate a transaction, they unknowingly paste the attacker's address, sending their funds into the wrong hands.

Under the Hood: Browser Hooking and API Interception

This specific malware was engineered to execute exclusively in a client-side browser environment, meaning it targeted end-users of websites that bundled the malicious packages, not the developers' machines or servers directly. It employed a sophisticated, two-pronged strategy to ensure maximum coverage.

Passive Network Interception: The malware began by "hooking," or overriding, the browser's fundamental networking functions (fetch and XMLHttpRequest). This gave it the power to inspect all network traffic flowing in and out of the webpage. When it detected an API response containing a cryptocurrency address, it would rewrite that address on the fly before the website's legitimate JavaScript code had a chance to process or display it. more...
Active Transaction Hijacking: The malware's behavior escalated if it detected the presence of a Web3 wallet extension like MetaMask, which it identified by checking for the window.ethereum object in the browser. In this mode, it moved from (above mentioned) passive interception to active hijacking. It would intercept API calls made to the wallet, such as eth_sendTransaction, and directly manipulate the transaction parameters in memory just moments before the user was prompted to sign and approve it. The user would see a legitimate-looking confirmation pop-up from their wallet, but the underlying recipient address had already been maliciously altered. more...

This dual-pronged approach was architected to exploit both the technical workings of web applications and the psychological trust a user has in their wallet's interface. By intercepting data at both the network and wallet layers, the malware ensured that even if a user was careful, the information they were verifying had already been compromised. (Holy moly, that's wild 😎)

Levenshtein Distance

Perhaps the most clever aspect of the malware was its method for choosing which of the attacker's wallet addresses to use for the swap. Instead of using a single, static address, it employed the Levenshtein distance algorithm.

This algorithm measures the "edit distance" between two strings - essentially, the minimum number of single-character edits (insertions, deletions, or substitutions) required to change one string into the other. The malware contained a pre-compiled list of attacker-controlled wallets. When a user copied a legitimate address, the malware would calculate the Levenshtein distance between that address and every address in its list. It would then select the attacker's address that was visually most similar to the original, making the swap incredibly difficult to detect with a cursory glance (without much attention to detail). This technique preys on the fact that cryptocurrency addresses are long and complex, and users rarely verify them character by character.

Hiding in Plain Sight: Code Obfuscation

To avoid immediate detection by developers or security scanners, the malicious code was heavily obfuscated.

Code obfuscation is the process of making source code intentionally difficult for humans and automated tools to understand, without altering its functionality.

Common techniques used in such malware include:

Symbol Renaming: Replacing descriptive variable and function names like replaceWalletAddress with meaningless single letters like x or a1.
String Encryption: Hiding critical strings, such as wallet addresses or targeted function names, by encoding them in formats like Base64 or hex, only to be decoded at runtime.
Control Flow Obfuscation: Restructuring the code's logic, turning simple conditional statements into convoluted loops (like for, while) and jumps (like break, continue, return, goto). This creates "spaghetti code" that is functionally identical but logically incomprehensible to a human analyst.

The goal was to embed a small, unreadable block of code into the otherwise legitimate package files, allowing it to slip past all but the most thorough of code reviews.

The Pattern: This Has Happened Before, and It Will Happen Again

The qix incident, while shocking in its scale, was not an isolated event. It is the latest and most prominent example in an escalating trend of software supply chain attacks targeting the open-source ecosystem. Attackers have recognized that compromising a single trusted component is a highly efficient way to infect thousands or even millions of downstream users.

The New Perimeter: Why Attackers Love Open Source

A software supply chain attack operates on a simple principle: instead of attacking a fortified castle directly, poison the well that supplies its water. In software, this means injecting malicious code into a trusted upstream dependency (i.e. a library, a framework, or a developer tool) and waiting for that code to be distributed to unsuspecting consumers.

The npm ecosystem is a particularly fertile ground for these attacks. As the world's largest software registry, it forms the backbone of modern web development. Projects often have deep and complex dependency trees, with hundreds of "transitive dependencies" pulled in automatically without the developer's direct knowledge. This complexity, combined with a culture of implicit trust, creates an environment where a single compromised maintainer account can have a catastrophic ripple effect across the entire industry.

A Rogues' Gallery of Recent npm Attacks

Analyzing recent major npm compromises reveals a clear pattern of evolving attacker sophistication. They are moving from broad, opportunistic attacks to highly strategic operations with payloads tailored to the specific context of the compromised package.

ua-parser-js (October 2021): In a similar account hijacking incident, an attacker gained control of the ua-parser-js package, which boasts millions of weekly downloads. They published malicious versions designed to install a Monero cryptocurrency miner on infected machines and deploy the DANABOT banking trojan on Windows systems. This attack demonstrated a similar entry vector (account compromise) but with a more generic, resource-hijacking payload. more...
eslint-config-prettier & is package (July 2025): These compromises were part of a sustained phishing campaign that used typosquatted domains (like npnjs.com - n instead of m) and clever social engineering to harvest maintainer credentials. The attack on the is package was particularly insidious, as the attackers phished an old maintainer and then tricked the current maintainer into re-granting them publishing rights, exploiting the trust between developers. more...
The nx Compromise (August 2025): This attack marked a significant leap in sophistication. After a maintainer's npm token was leaked, attackers published malicious versions of the popular nx build system. The payload was not generic; it was a highly targeted credential harvester designed to steal secrets directly from the developer's environment, including SSH keys, .npmrc files, cloud credentials, and GitHub tokens. more...

This evolution shows that attackers are no longer just dropping malware; they are strategically analyzing their targets. When they compromise a front-end utility like chalk, they deploy a browser-based payload. When they compromise a developer tool like nx, they deploy a payload designed to steal developer credentials, which can then be used to launch even more supply chain attacks. This strategic tailoring of the weapon to the target represents a dangerous new phase in the security of the open-source supply chain.

True Costs and the Lingering Threat in Your Nexus Cache

The real impact of a supply chain attack is rarely measured by the attacker's direct financial gain. Instead, it is measured in the disruption, cost, and erosion of trust inflicted upon the entire ecosystem.

Pennies Stolen, Millions Wasted

Despite the attack's enormous reach, the amount of cryptocurrency successfully stolen was surprisingly minuscule. Reports indicate the primary attacker wallet received only about 5 cents worth of ETH and $20 of a memecoin. This paltry sum stands in stark contrast to the true cost of the incident.

The real damage was a massive, industry-wide "denial-of-service" attack on productivity. Thousands of engineering and security teams across the globe were forced to drop everything, spending countless hours investigating their exposure, auditing their dependency trees, purging potentially contaminated systems, and reassuring stakeholders. This collective loss of productivity represents the true, multi-million-dollar financial impact of the attack.

Furthermore, incidents like this inflict long-term damage on the trust that underpins the open-source model. Every npm install now carries a small but palpable risk, forcing developers and organizations to adopt more defensive, time-consuming, and cautious development practices.

How Sonatype Nexus Amplifies the Threat

For many organizations, the threat did not disappear when npm removed the malicious packages from the public registry. Companies that use a local repository manager like "Sonatype Nexus" faced a hidden, persistent danger. A repository manager acts as a private, local cache for external dependencies. When a developer or a CI/CD pipeline requests a package, Nexus checks its local storage. If the package isn't there, Nexus fetches it from the public registry (like npmjs.com), stores a copy for future use, and then serves it to the requester. This process is designed to improve build speed, ensure dependency availability during public registry outages, and provide a central point for security scanning.

However, this very mechanism for resilience becomes a critical vulnerability during a supply chain attack. The sequence of events is as follows:

During the two-hour window when the malicious packages were live, an internal build requests a compromised version, for example, chalk@5.6.1.
Nexus, not having this version cached, downloads it from the public npm registry and stores it in its local "blob store."
Nexus serves the poisoned package to the internal build, potentially compromising the resulting application.
The npm security team acts swiftly and removes chalk@5.6.1 from the public registry.
The Problem Persists: The malicious package still exists within the company's private Nexus cache. From this point forward, every internal developer and every CI/CD build that requests that specific version will be served the poisoned copy directly from Nexus, which no longer checks the public registry for a package it has already cached.

In this scenario, a tool designed to enhance security and reliability becomes a persistent internal vector for the malware, amplifying and prolonging the attack's window of exposure long after the public threat has been neutralized. Infrastructure designed for operational resilience can inadvertently create significant security blind spots, demonstrating a fundamental tension between the DevOps goals of speed and reliability and the security imperative of continuous verification.

A Step-by-Step Guide to Recovery and Resilience

Recovering from a supply chain attack requires a coordinated effort. The following steps are divided into three parts: immediate triage for individual developers, a guide for purging contaminated infrastructure like Nexus, and long-term strategies to harden defenses.

Part A: Immediate Triage for Your Projects (For Every Developer)

Step 1: Audit Your Dependencies

Run npm audit in the root of every project. This command checks the project's dependency tree against the npm advisory database for known vulnerabilities and will flag the malicious versions of the compromised packages.

Step 2: Manually Inspect Your Lockfiles (beyond `npm ls`, `npm explain`)

Do not rely on npm audit alone. Manually search the package-lock.json or yarn.lock file for any of the compromised packages and versions listed in the table earlier in this report. This provides definitive proof of whether a malicious version was ever installed.

Step 3: Search for Indicators of Compromise (IoCs)

If a malicious package was used in a front-end build, the malware's code may be present in the final bundled JavaScript files. Use a command-line tool like grep or your code editor's search function to scan the built application code for the following specific strings and patterns, which are known IoCs for this malware

Global variables: stealthProxyControl, runmask, newdlocal, checkethereumw
Attacker's Ethereum address: 0xFc4a4858bafef54D1b1d7697bfb5c52F4c166976

Step 4: Perform a Clean Reinstall

To ensure the environment is completely clean, perform a full reinstallation of dependencies:

Delete the node_modules directory and the project's lockfile (package-lock.json or yarn.lock).
In the package.json file, ensure dependencies are pinned to known safe versions (i.e., versions published before the incident)
Clear the local npm cache to remove any tainted packages stored on the machine by running npm cache clean --force.
Run npm install to generate a new, clean lockfile and install dependencies from a safe state.

Part B: Purging the Poison from Your Nexus Repository (For System Administrators)

Removing the malicious packages from the central Nexus cache is critical to prevent reinfection across the organization.

Option 1: The Surgical Approach (Component Deletion)

Use the search feature in the Nexus Repository UI to locate the specific malicious components by name and version (e.g., repository: npm-proxy, name: chalk, version: 5.6.1). Alternatively, use the Nexus REST API to script this search. Once located, use the "Delete component" button in the UI to remove it. This can also be done programmatically.

Option 2: The Aggressive Approach (Cleanup Policies)

Navigate to Administration -> Repository -> Cleanup Policies and create a new policy. Set an aggressive criterion, such as "Component Usage," to remove components that were "Last downloaded before 1 day(s)"
Edit the configuration of the affected repository (i.e. npm-proxy) and assign this new cleanup policy to it.
Manually execute the "Admin -> Cleanup repositories using their associated policies" task from the System -> Tasks menu to trigger the purge.

Mandatory Final Step: Compact the Blob Store

Both of the above methods only "soft delete" the components; the data still resides on the disk and the space is not reclaimed. To permanently remove the data, an administrator must run the "Admin -> Compact blob store" task for the relevant blob store. This is a critical and often-overlooked final step to ensure the malicious artifact is truly gone.

Part C: Hardening Your Defenses for the Future

Preventing the next attack requires adopting more resilient practices at both the developer and organizational levels.

For Developers:

Enforce Lockfiles: Always commit package-lock.json or yarn.lock to source control. In CI/CD environments, use npm ci instead of npm install. The ci command performs a clean install based only on the lockfile, ensuring deterministic and repeatable builds that are not susceptible to newly published malicious versions.
Harden Your Accounts: Enable 2FA on all developer accounts, especially for package registries (npm) and source control (GitHub). More importantly, advocate for and adopt phishing-resistant MFA methods like FIDO2/WebAuthn security keys, which are immune to the "AitM" attack that caused this incident.

For Organizations:

Automate Security in CI/CD: Integrate dependency scanning directly into the CI/CD pipeline. Configure npm audit to run on every build and set a failure threshold (e.g., --audit-level=high) to automatically block code with critical vulnerabilities from being deployed.
Manage the Proxy: Continue using a local proxy like Nexus, but incorporate the purging procedures from Part B into the official incident response plan. Consider investing in tools like Sonatype Repository Firewall, which can automatically identify and block malicious packages from entering the cache in the first place, shifting from a reactive to a proactive defense.

Ultimately, recovery from a supply chain attack is a shared responsibility. Developers must secure their local environments and codebases, while operations and security teams must secure the shared infrastructure. A clean node_modules folder is of little use if the CI server pulls the same poison from a contaminated Nexus cache, and a pristine Nexus cache cannot protect a developer whose lockfile is already pointing to a malicious version. A coordinated, multi-layered response is the only effective path to resilience.

The Price of Trust

The qix incident serves as a powerful reminder of the fragile nature of trust in the digital supply chain. It demonstrated how sophisticated phishing can bypass standard security controls, how clever malware can exploit both technical and psychological vulnerabilities, and how infrastructure designed for efficiency can become a vector for persistent threats. The open-source ecosystem is built on a foundation of trust, but this event makes it clear that trust must now be paired with rigorous verification.

The true impact was not the theft of cryptocurrency but the theft of time, productivity, and confidence. Yet, the story also contains a lesson of empowerment. The rapid response from the security community, the transparency of the compromised developer, and the collective effort to remediate the issue highlight the ecosystem's resilience.

By understanding these attacks, adopting defensive coding practices, and advocating for stronger security measures, developers (even junior ones) are not helpless. They are the essential guardians on the front lines of the software supply chain.

V8, the engine behind Chrome & Node.js, just made JSON.stringify more than twice as fast! This is a huge win for web performance.

Figsy — Sun, 17 Aug 2025 14:42:19 +0000

Figsy

Aug 17 '25

The Invisible Optimization That Sped Up the Web: How V8 Supercharged JSON.stringify

#node #javascript #v8 #jsonstringify

Comments 2

18 min read

The Invisible Optimization That Sped Up the Web: How V8 Supercharged JSON.stringify

Figsy — Sun, 17 Aug 2025 14:17:24 +0000

If you've ever built a web application, especially one with a backend (like a server written in Node.js), you've almost certainly used JSON.stringify. It's the go-to tool for turning structured data (like a list of users or products) into a plain text format that can be sent over the internet as part of an API response, or saved in your browser's local storage.

Well, the JavaScript engine called V8 (which powers popular browsers like Chrome and Node.js) has made JSON.stringify more than twice as fast! This is a huge deal, meaning quicker page interactions and more responsive applications for all of us.

This was not an optimization in search of a problem. For years, developers in the Node.js community have identified JSON.stringify as a critical performance chokepoint. In community discussions, it has been described as one of the "biggest impediments to just about everything around performant node services". Given that Node.js operates on a single-threaded event loop, a CPU-intensive, blocking operation like serializing a large JSON object can halt the entire server, preventing it from handling other requests. This makes the function's performance a direct factor in a server's scalability and throughput.

The V8 team's work, therefore, addresses a well-known and systemic pain point, directly enabling developers to build more efficient and scalable backend systems. Let's dive into how they pulled this off, with some simple examples.

What Does Actually Do?

Imagine you have some information organized neatly in your JavaScript code, like a profile for a person.

const userProfile = {
  id: 123,
  name: "Jane Doe",
  isActive: true,
  roles: ["admin", "editor"]
};

JSON.stringify takes this structured data and converts it into a plain string of text that can be easily sent over a network or stored.

JSON.stringify converts it to a string:

// This is the output of JSON.stringify(userProfile)
'{"id":123,"name":"Jane Doe","isActive":true,"roles":["admin","editor"]}'

You'll often see this when an API sends back a list of items, like an array of these kinds of objects with the same structure, which is a very common scenario.

The Big Improvements and How They Work

The engineers at V8 re-thought JSON.stringify from the ground up, focusing on core operations like memory management and character handling

1. The "Super Highway" for Clean Data (Side-Effect-Free Fast Path)

Think of it like shipping a package. If your package is simple, contains only standard items, and doesn't require any custom processing or special instructions, it can go on a super-fast, automated conveyor belt.

V8 now has a special fast path for data that's plain and clean. This means the data doesn't involve any hidden code running or complex internal operations that could cause side effects when it's being converted to JSON.

Most typical data we send, especially in API responses, falls into this "clean" category. This allows V8 to bypass many expensive checks and defensive logic that the older, more general serializer had to perform, leading to a significant speedup for common JavaScript objects.

To stay on the fast path, the data being serialized must be "plain". This means it cannot contain features that would force the engine to execute arbitrary code during the serialization process.

Consider the following examples:

Clean Object (Eligible for the Fast Path):
This object is a simple container for data. It has no hidden logic.

const userProfile = {
  id: 42,
  username: "dev_user",
  isActive: true,
  tags: ["javascript", "performance"]
};

// V8 can safely assume serializing this object has no side effects.
// It will use the ultra-fast "Super Highway."
JSON.stringify(userProfile);

Object with Side Effects (Forced onto the Slower, General Path):
This object contains custom logic that gets triggered during serialization, creating side effects.

const userProfileWithSideEffects = {
  id: 42,
  username: "dev_user",
  // A custom.toJSON method is user-defined code. V8 must execute it.
  toJSON: function() {
    console.log("Custom.toJSON() method was called!"); // A clear side effect (I/O)
    return {
      userId: this.id,
      user: this.username
    };
  }
};

// When V8 sees the.toJSON() method, it cannot make assumptions.
// It must fall back to the slower, general-purpose serializer to execute the function safely.
JSON.stringify(userProfileWithSideEffects);

Other features that cause a fallback include using a replacer function or encountering a Proxy object, as both involve executing user code that V8 cannot predict.

The replacer function

A replacer is a function passed as the second argument to JSON.stringify. It gets called for every key-value pair in the object being serialized, giving you a chance to modify or skip values on the fly. Since this involves running arbitrary user-defined code for each property, V8 can't predict the outcome and must opt out of its "fast path".

Consider the following example:

Imagine you have user data but you don't want to expose the user's email and you want to format their lastLogin date for the output.

// The data object
const user = {
  id: 42,
  username: "jdoe",
  email: "john.doe@example.com",
  lastLogin: new Date("2025-08-17T08:30:00Z"),
  roles: ["editor", "viewer"]
};

// The replacer function
const replacer = (key, value) => {
  // 1. Skip the 'email' property
  if (key === "email") {
    return undefined; // Returning undefined removes the property
  }

  // 2. Format the 'lastLogin' date
  if (key === "lastLogin") {
    // V8 can't know this logic ahead of time
    return value.toLocaleString('en-US', { timeZone: 'UTC' });
  }

  return value; // Return the original value for all other keys
};

// Using JSON.stringify with the replacer
const userJson = JSON.stringify(user, replacer, 2); // The '2' is for pretty-printing

console.log(userJson);

Output:

{
  "id": 42,
  "username": "jdoe",
  "lastLogin": "8/17/2025, 8:30:00 AM",
  "roles": [
    "editor",
    "viewer"
  ]
}

V8 cannot optimize this process because it has to pause and execute the replacer function for every single property (id, username, email, etc.). It's impossible to know in advance that you'll be filtering the email or reformatting the lastLogin date. This unpredictability forces a retreat to the slower, more cautious serialization method.

The Proxy Object

A Proxy is an object that wraps another object and intercepts fundamental operations, such as getting or setting a property. When JSON.stringify tries to access the properties of a Proxy, it's not directly reading the data; it's triggering user-defined "trap" functions (get, has, etc.). This is another form of unpredictable user code that V8's fast path cannot handle.

Consider the following example:

Let's create a proxy that logs every time a property is accessed and hides any property that starts with an underscore (_).

// The original data object, with a "private" property
const userSecret = {
  id: 101,
  username: "secret_agent",
  _missionCode: "Alpha-7" // This should not be serialized
};

// The handler with the trap logic for the Proxy
const handler = {
  // This 'get' trap is called whenever a property is read
  get: (target, property) => {
    console.log(`Intercepted: Getting property "${property}"`);

    // Hide properties starting with '_'
    if (property.toString().startsWith('_')) {
      return undefined;
    }
    return target[property];
  },

  // This 'ownKeys' trap is needed for JSON.stringify to know which keys exist
  ownKeys: (target) => {
    console.log("Intercepted: Getting all keys");
    return Object.keys(target).filter(key => !key.startsWith('_'));
  }
};

// Create the proxy
const proxyUser = new Proxy(userSecret, handler);

// Try to stringify the proxy
// JSON.stringify will trigger the 'get' and 'ownKeys' traps
const proxyJson = JSON.stringify(proxyUser, null, 2);

console.log("\nFinal JSON output:");
console.log(proxyJson);

Output:

Intercepted: Getting all keys
Intercepted: Getting property "id"
Intercepted: Getting property "username"

Final JSON output:
{
  "id": 101,
  "username": "secret_agent"
}

When JSON.stringify processes proxyUser, it doesn't just read { id: 101, ... }. Instead, for every property it wants to read, it must execute the logic inside the handler.get and handler.ownKeys traps. The behavior of these traps is completely unpredictable - they could return anything, perform calculations, or even throw errors. V8 cannot make any safe assumptions and must use the "slow path" that correctly invokes the proxy's logic.

Iteration over Recursion

A subtle but critical architectural improvement within the new "fast path" is that it is iterative, not recursive. A traditional approach to traversing a nested object structure often uses recursion, where a function calls itself to process each level of nesting. However, this can lead to a "Maximum call stack size exceeded" error if the object is too deep.

The new iterative design completely sidesteps this problem. It "eliminates the need for stack overflow checks" and allows for the serialization of "significantly deeper nested object graphs". This means the optimization is not just about raw speed; it also enhances the robustness and capability of JSON.stringify, allowing it to handle larger and more complex data structures without crashing.

Consider the following example:

The JavaScript code examples below demonstrate the conceptual difference between a recursive and an iterative approach to traversing an object. The actual high-performance implementation of this iterative logic is handled deep inside the V8 engine's C++ source code. The examples are provided for illustrative purposes to help developers visualize the robust, non-blocking strategy that V8 now uses internally.

Traversing a Nested Object
Let's use a common task for JSON.stringify: traversing a nested object to read all its values.

1. The Recursive Way

In this approach, the traverse function calls itself for every nested object it finds.

const userProfile = {
  name: "Alex",
  settings: {
    theme: "dark",
    notifications: {
      email: true,
      push: false
    }
  }
};

function traverseRecursively(obj) {
  for (const key in obj) {
    console.log(`Found key: ${key}, value: ${obj[key]}`);

    // If the value is another object, call the same function on it
    if (typeof obj[key] === 'object' && obj[key] !== null) {
      traverseRecursively(obj[key]); // <<< RECURSIVE CALL
    }
  }
}

console.log("--- Recursive Traversal ---");
traverseRecursively(userProfile);

How it works?

traverseRecursively is called on userProfile.
It processes name and then settings.
When it sees settings is an object, it pauses and calls traverseRecursively on the settings object.
That second call processes theme and notifications.
When it sees notifications is an object, it pauses and calls traverseRecursively a third time.

What is the Danger?

Each function call is added to the call stack. If the object were 20,000 levels deep, you would have 20,000 function calls waiting on the stack, leading to a crash.

// A deeply nested object that will cause a stack overflow
let deepObject = {};
let current = deepObject;
for (let i = 0; i < 20000; i++) {
  current.next = {};
  current = current.next;
}

// This will likely throw: "Maximum call stack size exceeded"
try {
  traverseRecursively(deepObject);
} catch (e) {
  console.error(e.message); 
}

2. The Iterative Way

This version uses a simple while loop and an array (nodesToVisit) that acts as our to-do list, completely avoiding deep function calls.

const userProfile = {
  name: "Alex",
  settings: {
    theme: "dark",
    notifications: {
      email: true,
      push: false
    }
  }
};

function traverseIteratively(obj) {
  // Our "to-do list" starts with the main object
  const nodesToVisit = [obj];

  // Loop as long as there are objects to process
  while (nodesToVisit.length > 0) {
    const currentNode = nodesToVisit.pop(); // Get the next object to work on

    for (const key in currentNode) {
      console.log(`Found key: ${key}, value: ${currentNode[key]}`);

      // If a value is another object, add it to our to-do list
      if (typeof currentNode[key] === 'object' && currentNode[key] !== null) {
        nodesToVisit.push(currentNode[key]); // <<< NO RECURSIVE CALL
      }
    }
  }
}

console.log("\n--- Iterative Traversal ---");
traverseIteratively(userProfile);

How it works?

The nodesToVisit array starts with just [userProfile].
The while loop starts. It takes userProfile out of the array.
It processes name and settings.
When it finds the settings object, it just adds it to the nodesToVisit array. The array is now [settings object].
On the next loop, it takes settings out, processes its keys, and adds the notifications object to the array.

What is the Benefit?

This version can handle the deeply nested object without any problems.

let deepObject = {};
let current = deepObject;
for (let i = 0; i < 20000; i++) {
  current.next = {};
  current = current.next;
}

// This works perfectly, no crash!
console.log("\n--- Iterative on Deep Object ---");
// We won't print every line, but we can confirm it runs.
try {
    traverseIteratively(deepObject);
    console.log("Successfully traversed deep object iteratively!");
} catch(e) {
    console.error("This should not happen:", e.message);
}

Conclusion:

By switching JSON.stringify from a recursive to an iterative internal design, V8 made it more robust. It's not just faster for common cases; it's now capable of handling extremely deep, complex objects without the risk of crashing from a "Maximum call stack size exceeded" error. This makes it a more reliable tool for heavy-duty data serialization.

2. The "Express Lane" for Similar Data (A huge win for API responses!)

Within the main "Super Highway," V8 introduced an even faster "Express Lane." This optimization provides a massive speed boost for one of the most common use cases on the web: serializing an array of objects that all have the same structure, such as a list of products or users returned from an API. To understand how this works, one must first understand a core concept of V8's internal design: Hidden Classes

A Primer on V8's Hidden Classes

JavaScript is a dynamically typed language, meaning you can add or remove properties from an object at any time. While flexible, this poses a performance challenge. If objects are treated like simple dictionaries, accessing a property like user.email would require a slow string-based lookup to find the memory location of that property's value.

To solve this, V8 uses a mechanism called Hidden Classes (also known internally as Maps). When an object is created, V8 creates a hidden class that acts as an internal blueprint, describing the object's "shape" - its properties and the order they were added in. When another object is created with the exact same shape, V8 can reuse the same hidden class. This allows the engine to treat the object's properties as if they had a fixed layout, similar to statically typed languages like Java. Instead of a slow dictionary lookup, V8 knows the exact memory offset for each property, enabling incredibly fast access.

What might have happened without this (Hidden Classes) optimization?

At its core, a basic JavaScript object is like a dictionary or a hash map. It's a collection of key-value pairs. When you write user.email, you're telling the engine to find the value associated with the key "email" inside the user object.

Without optimizations, the engine would have to perform a string-based lookup:

Get the key: The engine takes the string "email".
Hash the key: It might run the string through a hashing function to get a unique identifier, like 48291.
Find the key in memory: It then has to search through the object's internal list of properties to find a match for the string "email" (or its hash).
Retrieve the value's location: Once it finds the matching key, it gets the memory address where the actual value ("jane.doe@example.com") is stored.
Return the value: Finally, it fetches the data from that memory address.

This process, especially the "find the key" step, is computationally expensive. It has to be repeated every single time you access user.email, even inside a tight loop running thousands of times. For a dynamic language, this is the default, safe way to do things, but it's not fast.

How Hidden Classes (Shapes) solves this problem?

The engineers behind V8 realized that in most real-world applications, developers create many objects with the exact same structure (same properties in the same order). V8 leverages this pattern to avoid the slow string lookups.

It does this using a concept called Hidden Classes (also known as Shapes or Maps).

Here’s how it works:

Step 1: Creating a Hidden Class

When you create an object, V8 creates a Hidden Class behind the scenes. This acts as a blueprint for that object's shape.

JS Code	V8's action
`const user1 = {};`	Creates a blank Hidden Class, let's call it `C0`.
`user1.name = "Jane";`	Creates a new Hidden Class `C1` based on `C0`. `C1` describes an object that has a single property, `name`. V8 also records the memory offset for `name`. For example, it knows `name` is stored right at the beginning of the object's memory block (offset: 0).
`user1.email = "jane.doe@example.com";`	Creates another Hidden Class `C2` based on `C1`. `C2` describes an object with properties `name` and `email`. V8 records that `email` is stored at the next memory location (e.g., offset: 1).

The user1 object is now tagged with Hidden Class C2.

Step 2: Reusing the Hidden Class

Now, here comes the magic. When you create a second object with the same properties in the same order:

const user2 = {};
user2.name = "John";
user2.email = "john.smith@example.com";

V8 follows the exact same steps. It sees you're creating an object with the same "shape" as user1. Instead of creating new Hidden Classes, it simply tags user2 with the existing Hidden Class C2.

Step 3: The High-Speed Access

Now, when your code runs console.log(user1.email) or console.log(user2.email), V8 performs a much faster, direct memory access:

Check Hidden Class: V8 sees that both user1 and user2 are using Hidden Class C2.
Look up offset in the blueprint: It consults the C2 blueprint and sees that the email property is always at a fixed memory offset (e.g., offset: 1).
Direct Memory Access: It jumps directly to that memory address for the given object and retrieves the value.

There is no string comparison and no searching. It's as fast as accessing a property in a low-level, compiled language like C++. This optimization transforms the slow, dynamic lookup into a simple calculation: object_memory_address + property_offset.

What Breaks the Optimization?

This speed boost only works if objects share a Hidden Class. If you add or delete properties or change their order, V8 has to create a new blueprint and can't use the same optimized path.

const user1 = { name: "Jane", email: "jane@example.com" }; // Uses Hidden Class C2
const user2 = { email: "john@example.com", name: "John" }; // Different order -> New Hidden Class C3!

user1.age = 30; // This forces user1 to transition to yet another Hidden Class.

This is why a common performance tip for JavaScript is to always initialize your objects with the same structure and avoid adding or removing properties after creation.

The Express Lane in Action

The "Express Lane" optimization leverages this hidden class mechanism brilliantly. The process works as follows:

JSON.stringify is called on an array of user objects, all sharing the same hidden class (e.g., C2 from the example above).
When processing the first object in the array, the fast path performs its standard series of checks for each property key: confirm it's not a Symbol, ensure it's enumerable, and scan the key string for characters that require escaping.
If all keys pass these checks, V8 does something clever: it attaches a special flag to the object's hidden class (C2), marking it as "fast-json-iterable". Think of this as putting a "fast pass" sticker on the blueprint for this type of object.
When V8 moves to the second object, it first checks its hidden class. It sees that it's also C2 and that C2 has the "fast-json-iterable" flag.
This is the magic moment. Because of that flag, V8 can now completely skip all the property key checks. It already knows the keys "id" and "name" are safe and require no special handling. It can copy them directly to the output string buffer at maximum speed.
This process repeats for every subsequent object in the array that shares the same flagged hidden class.

This optimization creates a powerful feedback loop that rewards a performance (friendly coding pattern known as monomorphism - creating objects with consistent, predictable shapes). By structuring data consistently (e.g., always returning {id, name, email} from an API endpoint), developers automatically unlock this massive performance boost, not just in JSON.stringify but across many other parts of the V8 engine that rely on hidden classes for optimization.

3. Hardware-Level Acceleration

The V8 team did not stop at high-level architectural and algorithmic improvements; they pushed all the way down to the hardware level, leveraging special features of modern CPUs to accelerate the most fundamental operations: handling strings and numbers.

Parallel Processing in a Single Core: SIMD and SWAR

One of the most powerful features of modern processors is SIMD (Single Instruction, Multiple Data). In essence, SIMD allows a single CPU instruction to perform the same operation on multiple pieces of data simultaneously. A helpful analogy is applying a brightness filter in a photo editor. A traditional (scalar) approach would adjust the brightness of each pixel one by one. A SIMD-capable processor can adjust a whole block of pixels (i.e. say, 8 or 16 of them) in a single operation, dramatically speeding up the process.

V8 applies this same principle to string serialization. When stringifying a value, the engine must scan the string for any characters that require special escaping, such as a double quote (") or a backslash (\). Instead of checking one character at a time, V8 uses SIMD to load a large chunk of the string into a wide register and check multiple bytes at once with just a few instructions.

This strategy is further refined with a two-tiered approach:

For longer strings, V8 uses dedicated hardware SIMD instructions (like NEON on ARM CPUs or AVX2 on x86 CPUs), which are highly efficient for large blocks of data.
For shorter strings, where the overhead of setting up hardware SIMD would be too high, V8 uses a technique called SWAR (SIMD Within A Register). This approach uses clever bitwise logic on standard CPU registers to process multiple characters at once with very low overhead.

If a chunk is scanned and found to contain no special characters (which is the most common case) the entire chunk can be copied directly to the output buffer, making the process incredibly efficient.

Here’s a summary of where you can find CPUs that support SIMD instructions - AVX2 or NEON—across AWS, GCP, and laptops:

Platform	SIMD Support	Example Instances / Notes
AWS (x86 EC2)	AVX2, AVX-512	C5/C5d, M5, T3 (Intel Skylake/Cascade Lake)
AWS (ARM EC2)	NEON	Graviton2 (2×128-bit NEON): M6g, C6g, etc.; Graviton3 (4×128-bit NEON + SVE): C7g, M7g, etc.
GCP (Compute Engine)	AVX2 / AVX-512	Use “min CPU platform” to ensure Cascade Lake/Ice Lake (AVX2/possibly AVX-512)
Laptops (Intel)	AVX2/AVX-512	Recent-gen Intel Core i5/i7/i9 mostly supports AVX2; newer Ice Lake+ may include AVX-512
Laptops (ARM)	NEON	Apple M-series or ARM-based laptops include NEON SIMD

A Faster Number-to-String Algorithm: Dragonbox

Converting a floating-point number into its shortest, most accurate string representation is a notoriously complex computer science problem. For this task, V8 upgraded its core DoubleToString algorithm, replacing the long-serving Grisu3 algorithm with a state-of-the-art implementation called Dragonbox.

While this change was driven by profiling JSON.stringify, its benefits extend far beyond it. This is a "rising tide lifts all boats" improvement (general growth helps everyone). The new Dragonbox implementation benefits all calls to Number.prototype.toString() throughout the entire V8 engine. This means any JavaScript code that converts numbers to strings, not just JSON serialization, automatically receives this performance boost for free. This is a hallmark of efficient engineering: solving a specific problem by improving a shared, foundational component, thereby creating widespread, positive ripple effects across the platform.

4. Smart Memory Management

When building a very large JSON string, which can sometimes be hundreds of megabytes in size, memory management becomes a critical performance factor. The previous implementation of JSON.stringify faced a significant bottleneck related to how it handled its temporary output buffer.

🐌 The Old Way...

Previously, the stringifier built its output in a single, contiguous block of memory on the C++ heap. Imagine writing a very long document in a single notebook. As the JSON string grew, this memory block would eventually run out of space. When that happened, V8 had to perform a costly sequence of operations:

Allocate a new, larger block of memory (like getting a bigger notebook).
Copy the entire existing content from the old, full buffer to the new, larger one.
Deallocate the old buffer.

For very large JSON objects, this cycle of re-allocation and copying became a major performance bottleneck. Copying hundreds of megabytes of data is a slow, resource-intensive operation.

🚀 The New Way...

The V8 engineers had a crucial insight: the temporary buffer only needs to be a single, contiguous string at the very end of the process. While the string is being built, it can exist in pieces.

With this in mind, they replaced the old system with a Segmented Buffer. Instead of one large, growing block, the new stringifier uses a list of smaller, fixed-size buffers, or "segments" — much like using a series of small sticky notes instead of one giant page. When one segment is full, V8 simply allocates a new one and continues writing there. This completely eliminates the expensive copy operations.

This is vastly more efficient because you have eliminated all the intermediate copying steps. The expensive "joining" operation is only performed once, right at the end.

Old Way (Contiguous Buffer)	New Way (Segmented Buffer)
Analogy: One single, growing scroll.	Analogy: A stack of sticky notes.
Process: Write, run out of space, copy everything to a bigger scroll, repeat.	Process: Write on a note, grab a new one when full, repeat.
Bottleneck: The slow, repeated copying of large amounts of data.	Benefit: No intermediate copying. The expensive "join" happens only once at the end.

These segments are allocated in V8's Zone memory, a special memory pool optimized for very fast, short-lived allocations, which further reduces management overhead. At the very end, when the entire object has been processed, all these smaller segments are efficiently joined together to form the final, complete JSON string. This change in the intermediate data structure is a classic example of a performance engineering trade-off: the logic to manage a list of buffers is slightly more complex, but it eliminates a major performance cliff, making it a worthwhile investment for a critical function like JSON.stringify.

How to Stay on the Fast Path (and When You Can't)

These incredible performance improvements are available automatically in V8 version 13.8 (found in Chrome 138) and later.

Node.js
As of Node.js 24, the V8 engine version included is 13.6, not 13.8. Thus, no stable or current Node.js release is using V8 13.8 as of mid‑August 2025

Google Chrome
Performance improvements (like faster JSON.stringify) are confirmed to be available starting in Chrome 138, which uses V8 13.8

Summary

The following table provides a quick-reference guide for developers aiming to maximize JSON.stringify performance.

Feature / Condition	Consequence	Rationale for Fallback
`replacer` function provided	Falls back to general serializer.	V8 cannot make assumptions about arbitrary user code. The replacer could introduce side effects or complex logic that the fast path is not designed to handle.
`space` argument provided	Falls back to general serializer.	The logic for pretty-printing (inserting spaces, newlines) is separate from the core task of fast serialization and is handled by the more versatile general path.
Object has a `.toJSON()` method	Falls back to general serializer.	This invokes a user-defined method during serialization, which is considered a potential side effect. V8 must execute this code, so it uses the general path.
Array of objects with inconsistent shapes	Stays on fast path, but disables the "Express Lane."	The core fast path can still be used, but V8 cannot reuse the hidden class information. It must individually check the properties of each differently-shaped object, losing the major speedup of the "Express Lane."
Object with array-like indexed properties	Falls back to general serializer.	Objects with numeric keys (e.g., '0', '1') are handled differently internally than objects with string keys, particularly regarding property ordering. This requires the more complex logic of the general path.
Object contains Symbol-keyed properties	Property is ignored (standard behavior).	The fast path must still check for Symbols on the first object of a given shape. The "Express Lane" then assumes no Symbols exist for subsequent objects of the same shape.

Reference: https://v8.dev/blog/json-stringify

Forem: Figsy

Elixir Comprehensions: Learn Enough to be Dangerous

1. Simple Comprehension (like a simple Enum.map)

2. Adding Filters

3. Adding Options

4. Adding Filters + Options

Example 4.1.

Example 4.2.

Example 4.3.

Example 4.4.

5. The Complex Chain

6. How Elixir Decodes the Syntax (The Clues)?

7. Execution Flow

Example 7.1. Finding valid mixed colors from RGB channels

Example 7.2. Finding senior staff on high-performing teams at profitable companies.

Is the Internet a Junkyard?

The Internet Starts to Eat Itself (c. 2022-Present)

AI slop

Model Collapse

Human Creativity in the Age of AI

AI as a Creative Partner

The New Value of Authenticity

Conclusion

The Story So Far

A New Solution?

The Future of a More Trustworthy Internet

Anatomy of a Supply Chain Heist: The Day 'chalk' and 'debug' Became Crypto-Thieves

The Attack: 🤔 How One Phishing Email Compromised Billions of Downloads?

🎯 The Target: A Respected Developer

🧲 The Lure

🪄 Bypassing 2FA

Rapid Detection and Response

The Weapon: A Deep Dive into the Crypto-Clipper Malware

🥷 What is a Crypto-Clipper? The Digital Pickpocket Analogy

Under the Hood: Browser Hooking and API Interception

Levenshtein Distance

Hiding in Plain Sight: Code Obfuscation

The Pattern: This Has Happened Before, and It Will Happen Again

The New Perimeter: Why Attackers Love Open Source

A Rogues' Gallery of Recent npm Attacks

True Costs and the Lingering Threat in Your Nexus Cache

Pennies Stolen, Millions Wasted

How Sonatype Nexus Amplifies the Threat

A Step-by-Step Guide to Recovery and Resilience

Part A: Immediate Triage for Your Projects (For Every Developer)

Step 1: Audit Your Dependencies

Step 2: Manually Inspect Your Lockfiles (beyond npm ls, npm explain)

Step 3: Search for Indicators of Compromise (IoCs)

Step 4: Perform a Clean Reinstall

Part B: Purging the Poison from Your Nexus Repository (For System Administrators)

Option 1: The Surgical Approach (Component Deletion)

Option 2: The Aggressive Approach (Cleanup Policies)

Mandatory Final Step: Compact the Blob Store

Part C: Hardening Your Defenses for the Future

For Developers:

For Organizations:

The Price of Trust

V8, the engine behind Chrome & Node.js, just made JSON.stringify more than twice as fast! This is a huge win for web performance.

The Invisible Optimization That Sped Up the Web: How V8 Supercharged JSON.stringify

The Invisible Optimization That Sped Up the Web: How V8 Supercharged JSON.stringify

What Does Actually Do?

The Big Improvements and How They Work

1. The "Super Highway" for Clean Data (Side-Effect-Free Fast Path)

Iteration over Recursion

2. The "Express Lane" for Similar Data (A huge win for API responses!)

A Primer on V8's Hidden Classes

The Express Lane in Action

3. Hardware-Level Acceleration

Parallel Processing in a Single Core: SIMD and SWAR

A Faster Number-to-String Algorithm: Dragonbox

4. Smart Memory Management

How to Stay on the Fast Path (and When You Can't)

Summary

1. Simple Comprehension (like a simple `Enum.map`)

Step 2: Manually Inspect Your Lockfiles (beyond `npm ls`, `npm explain`)