I Read Honey's Source Code

The video examines the Honey browser extension scandal by analyzing its publicly available Chrome extension source code. The creator explains their ability to trace changes over time to determine if bad behaviors were deliberate engineering decisions or accidental technical debt. They reference allegations from recent YouTube videos about Honey's practices and plan to verify these claims through code analysis. The video will include a three-minute excerpt from a recent Honey expose video before diving into the minified code examination and revealing surprising findings about the extension's intent and evolution.

This section presents the core fraud allegation: Honey selectively applies affiliate network stand-down policies. Affiliate networks enforce stand-down rules to prevent coupon extensions from stealing commissions from content creators under the 'last click wins' policy. A demonstration shows that Honey correctly stands down (disables itself) when a new user clicks an affiliate link for Newegg, but the same affiliate link triggers different behavior with two accounts side by side. The account with zero cashback points stands down properly, while an account with accumulated cashback points does not stand down, allowing Honey to steal the commission. This reveals Honey's selective enforcement based on user account status rather than consistent rule application.

The creator explains their analysis approach using multiple Honey versions from February 2019 (version 11) through present day 2024 (version 19.01). They leverage AI to search through minified code efficiently to answer whether the user-points-based stand-down behavior exists and whether it changed over time. The investigation distinguishes between legacy code that persists through neglect versus code that receives active maintenance and improvement. The creator references their experience at large companies where old code often remains unchanged for years, setting up the key question: did Honey's questionable stand-down logic simply persist unchanged, or did engineers actively refine and improve it over the five-year period?

Analysis of version 11 from 2019 reveals the original stand-down implementation used hard-coded switch statements and explicit provider checks. The code contained suspicious logic like checking if user emails contained the word 'test' to always stand down for testing accounts, effectively avoiding detection by affiliate network testers. The system had provider-specific logic with hardcoded checks like 'if provider equals LS (LinkShare), apply these exact rules.' A for-loop would evaluate each rule, and if any failed, the extension would stand down. The stand-down duration was notably short according to other investigations. This implementation pattern is common in early-stage projects with one or two providers, where developers use expedient hard-coded solutions before scaling requires more sophisticated architecture.

Between versions 11 through 14, spanning from 2019 to 2022, the code remained essentially unchanged with only minor edits and no significant modifications to the stand-down logic. This three-year period of stagnation could potentially support an argument that the questionable behavior was legacy code left unmaintained. However, this plateau period sets up a dramatic contrast with what happens next in 2024, when the engineering team undertakes a major refactoring effort. The minimal changes during this period suggest the system was working as intended for Honey's purposes, requiring no adjustments despite the underlying ethical issues with selectively enforcing affiliate rules.

Starting in version 16 (2024), Honey implemented a sophisticated refactor replacing hard-coded if statements with a dynamic JSON-driven configuration system. The new architecture uses endpoint-delivered objects with base values, provider-specific overrides, and store-specific rules under an 'X' namespace. Instead of hard-coded provider checks, the system now spreads configuration objects: base values are established, then provider-specific values are merged, then store-specific values are layered on top. For example, a non-logged-in user has a base requirement of 65,000 user points to bypass stand-down, but LinkShare reduces this to 5,001 points through provider overrides. This represents proper software engineering best practices—moving from brittle hard-coded logic to maintainable, data-driven configuration. The deliberate modernization demonstrates active maintenance and improvement of the stand-down system rather than neglected legacy code.

The creator concludes that the evolution from hard-coded logic to robust dynamic configuration demonstrates clear engineering intent to maintain and improve the stand-down system. This wasn't technical debt or abandoned code—it was actively developed to be more scalable and sophisticated. While the creator explicitly states they cannot determine if the behavior is legally fraudulent (that's for others to decide), they can definitively say the engineering decisions show deliberate effort to make the system 'better' at what it does. Given the general perception that selectively enforcing stand-down rules based on user points is shady behavior, Honey's engineering team spent resources making their 'pretty shady system much, much better' through professional software development practices.

The investigation uncovered something even more unusual: a complete JavaScript interpreter running inside Honey's JavaScript code. The system uses Acorn (a JavaScript parser that produces Abstract Syntax Trees) to evaluate JavaScript and feed it into a 'VIM' engine—not the text editor, but a Virtual Instance Manager. The code references 'cartOpsRetrievalJS' and 'productOpsRetrievalJS' objects that sometimes contain actual executable JavaScript code. While the creator couldn't trigger this code execution despite setting breakpoints, the infrastructure exists to execute remote code fetched from Honey's servers in a highly obfuscated manner. This JavaScript-in-JavaScript virtual machine represents an extreme level of code obfuscation, far beyond typical Chrome extension architecture.

The JavaScript interpreter appears designed to circumvent Chrome's Manifest V3 restrictions, which explicitly prohibit using JavaScript eval() to execute remote code. Honey technically complies by hard-coding stringified functions that ship with the extension rather than fetching truly remote code, but then uses an entire JavaScript virtual machine to execute them in an obfuscated way. Chrome's additional requirements seem to directly address this technique, warning against 'building an interpreter to run complex commands fetch from a remote source.' The claimed justification is that ad blockers might block Honey's direct function calls, but running them through an interpreter somehow evades detection. The creator finds no legitimate reason for this architecture and calls it 'some obfuscation, some weird stuff' representing perhaps the most complex Rube Goldberg-level contraption they've encountered in their career.

The creator summarizes the findings: Honey's stand-down system has been deliberately engineered to be robust and dynamic, controlled via JSON on a per-store, per-provider, and per-user basis, with whatever purpose it serves (fraudulent or not) being intentionally maintained and improved. They acknowledge collaboration with MegaLag (the original investigator) and recommend watching his comprehensive video series. The creator asks viewers for feedback on this reverse-engineering format, noting it's new content created during a live stream. They express surprise at enjoying reverse engineering despite not being formally trained in it, and marvel at the unusual engineering decisions discovered. The video concludes with a humorous sponsored segment about ordering coffee via SSH terminal, playing on the developer/hacker aesthetic of the content.