A no-network test needs a request that makes it fail

A browser-local CSV comparison prototype developed and tested with AI assistance needed a test for network activity after file selection. Its saved records show that the first test failed because it counted local Blob worker loads as HTTP traffic. This article examines the implementation and those records to explain how an unwanted request can check the monitor itself.

The general rule of breaking a check to verify that it fails appears in an earlier article. Here the focus is specific to browser observation: a local Blob load that was counted as traffic, and a fetch attempt that CSP blocked.

A count of zero looks the same when the application is quiet and when the monitor misses everything. An intentional request provided a check on the monitor itself.

AI assisted the development, validation, and writing. This article is based on the implementation and saved validation records; the tests were not rerun for the article.

An HTTP origin inside a Blob URL is not an HTTP request

The prototype loads static assets at startup, then parses and compares CSV files in a Worker. The test treats startup asset loading separately from activity after file selection.

The observation log also contained local Worker loads using Blob URLs. Their text includes the creator's origin. Blob URLs represent resources in memory, so an HTTP origin appearing inside one does not establish a server request. MDN's Blob URL reference

The test counted the prototype's same-origin Blob loads separately. It kept HTTP, HTTPS, and unexpected URLs subject to the original checks. This excerpt shows the classification idea:

function classify(raw: string, appOrigin: string) {
  const url = new URL(raw);
  if (url.protocol === "blob:" && url.origin === appOrigin) {
    return "local-blob";
  }
  if (url.protocol === "http:" || url.protocol === "https:") {
    return "http";
  }
  return "unexpected";
}

Classification is only one part of observation. It does not establish privacy by itself.

A blocked call is still an attempt

Counting successful requests alone can miss an API call blocked by Content Security Policy. The connect-src directive controls connections made through interfaces such as fetch, XHR, and WebSocket. MDN's connect-src reference

The prototype's requirement was zero HTTP requests after CSV selection and zero observed network or storage API attempts. The test therefore combined request events with API-call observations and CSP violation events. Its request observations used Playwright's BrowserContext events. Playwright documentation

An intentional fetch made the test fail

A temporary fetch('/privacy-probe', ...) was inserted into the comparison path. It used a fixed synthetic string and the local test server. It did not use real CSV data or an external destination.

CSP blocked the call. The monitor still recorded fetch attempts and CSP violations, and the zero-attempt assertion failed. The test was capable of rejecting that blocked call.

After removing the temporary code and rebuilding production assets, the saved observation record contained:

The workflow covered file selection, comparison, report download, configuration changes, cancellation, reruns, and reset. The intentional failure and the normal build's success were recorded separately.

One mutation does not establish coverage of every path

The evidence establishes detection of the fetch inserted for this check. It does not establish detection of every API or a call made immediately after Worker initialization. Hook timing and observation coverage need their own checks as the monitored paths expand.

These are Chrome validation records using synthetic data. They do not establish the safety of browser extensions or the operating system, or secure erasure of browser memory.

For a no-network requirement, keep the evidence that made the monitor fail alongside its zero-count result.