How BUIzz Turns Interaction Into Evidence

With the browser UI made executable, BUIzz still needs a defensible way to say what happened. This chapter follows BUIzz's control loop: it observes a policy-bearing page before an interaction, applies a browser UI scenario, observes the relevant security outcome afterward, and treats an unexplained weakening as a candidate enforcement bug. It also shows how the study uses existing test pages and bounded interaction combinations to make that comparison large enough to be useful without confusing test scale with real-world prevalence.

The detector compares a controlled before and after

The central experiment is a paired observation. BUIzz first visits a test page in the browser under test and records the enforcement outcome in that initial state. That visit is the baseline. It establishes what the browser does before the special interaction changes the page's navigation or rendering context.

The simulator then applies a scenario. A scenario can contain one navigation-related browser UI interaction, such as opening a link in another context or reopening a tab, or a two-interaction combination. After the browser completes the transition, BUIzz observes the same kind of security outcome again. The Detector compares the two observations rather than asking whether the page merely looks similar.

This is a control experiment in a practical sense. The page, policy, and browser implementation are held as constant as the test can hold them. The interaction is the perturbation. If the initial state blocks an action and the post-interaction state allows it, the change is evidence that the transition deserves investigation. If the outcome remains protected, the tested path has not produced a detectable weakening. The comparison does not prove that the browser is correct in every respect, but it isolates a question that a simple page visit cannot ask.

The detector must observe the protected behavior itself. BUIzz uses JavaScript execution as the signal for CSP's XSS-mitigation and sandbox cases. It inspects the Cookie header for SameSite behavior, because the security question is whether a cookie accompanies a request. It watches for a feature request when testing Permissions Policy, checks opener status for COOP, and examines the URL scheme for HSTS. Frame loading supplies the signal for framing controls, while the Referer header supplies the signal for Referrer-Policy. These channels are different because the policies protect different operations.

A generic success signal would hide those distinctions. Suppose a page loads successfully after a drag-and-drop action. That fact says little about whether the browser carried the right CSP into the destination, whether a SameSite cookie was attached, or whether the destination retained an opener relationship. The destination can render normally while a security-relevant request or capability is wrong. BUIzz therefore observes the policy's intended effect, not just the existence of a page.

The observation is also tied to the transition that produced it. A CSP test can ask whether a nonce-less script ran only after the link was moved through a browser UI path. A SameSite test can ask whether the cookie appeared only after a particular open-in-view action. A COOP test can ask whether an opener exists in the split-view result. The interaction, the destination, and the protected operation form one causal chain. Without retaining that chain, a tester might detect a difference but lose the information needed to reproduce or explain it.