Source URL: https://simonwillison.net/2025/Aug/11/the-rule-of-2/
Source: Simon Willison’s Weblog
Title: Chromium Docs: The Rule Of 2
Feedly Summary: Chromium Docs: The Rule Of 2
Alex Russell pointed me to this principle in the Chromium security documentation as similar to my description of the lethal trifecta. First added in 2019, the Chromium guideline states:
When you write code to parse, evaluate, or otherwise handle untrustworthy inputs from the Internet — which is almost everything we do in a web browser! — we like to follow a simple rule to make sure it’s safe enough to do so. The Rule Of 2 is: Pick no more than 2 of
untrustworthy inputs;
unsafe implementation language; and
high privilege.
Chromium uses this design pattern to help try to avoid the high severity memory safety bugs that come when untrustworthy inputs are handled by code running at high privilege.
Chrome Security Team will generally not approve landing a CL or new feature that involves all 3 of untrustworthy inputs, unsafe language, and high privilege. To solve this problem, you need to get rid of at least 1 of those 3 things.
Tags: browsers, chrome, security, lethal-trifecta
AI Summary and Description: Yes
Summary: The text discusses the “Rule of 2” from Chromium’s security documentation, emphasizing a design principle aimed at enhancing security when handling untrusted inputs in web applications. This principle is particularly relevant for professionals focused on software security, browser development, and secure coding practices.
Detailed Description:
The “Rule of 2” is a guideline established in Chromium’s security framework to mitigate risks associated with using untrusted inputs in web browsers. This principle is particularly important considering the source of numerous vulnerabilities that can arise from web applications.
Key insights from the text include:
– **Risk Management**: The Rule of 2 emphasizes reducing risk by limiting exposure to three critical components:
– **Untrustworthy Inputs**: Any data or commands that cannot be fully trusted, which is common in web interactions.
– **Unsafe Implementation Language**: Programming languages that do not inherently enforce memory safety or have known vulnerabilities.
– **High Privilege**: Code that runs with elevated permissions, which can lead to severe impacts if exploited.
– **Guiding Philosophy**: The Chrome Security Team utilizes this principle to evaluate new features and changes. They generally reject submissions that involve all three components, indicating a strong risk aversion philosophy.
– **Practical Applications**: By adhering to the Rule of 2, developers can create safer code by:
– Ensuring that at least one of the risk factors is addressed and minimized.
– Encouraging better coding practices, notably in terms of input validation and the use of safe programming languages.
– **Security Implications**: This approach reinforces the importance of secure coding practices in web development, aiming to prevent high-severity memory safety bugs.
In summary, the Rule of 2 serves as a practical guideline for developers to enhance the security posture of their web applications by consciously managing risk through design decisions. This principle is especially significant for security professionals in software security and browser development, as it outlines a proactive approach to handling common vulnerabilities associated with web technologies.