Startup Lab · Build 004 · Technical build case study
Build Log 004: Web Evidence Inspector
Building a bounded browser evidence tool for one controlled public page load.
Many website checks compress a browser session into a score, then leave the reader to guess what that score actually saw. The Web Evidence Inspector takes a narrower route. It runs one controlled visit to one public HTTP or HTTPS URL, keeps the observed layers distinguishable, and presents a limited public result rather than a verdict about a whole website.
This is not a complete security scan. It reflects one controlled page load only.
What the Web Evidence Inspector is
The Inspector is a bounded browser-evidence tool. A person supplies one public URL. A controlled Chromium session loads that page once. The system records a defined set of observations, produces findings from those observations, and returns a deliberately reduced public summary.
- It accepts one public HTTP or HTTPS URL within its input policy.
- It performs one controlled browser page load, rather than a site-wide crawl.
- It turns recorded observations into explainable inspection findings.
- It exposes a sanitised public result while keeping raw evidence private.
That boundary is the point. The project is not trying to make a browser visit sound more conclusive than it is. It is trying to preserve useful evidence from a specific, repeatable moment without pretending that one moment describes every route, user state, device, consent choice, or future version of a site.
Why I built it
Startup Lab is where Darja Rihla tests whether a useful idea can survive contact with real technical constraints. Here, the engineering question was not “How do we produce a bigger score?” It was: can one browser visit create a small record that a person can inspect, explain and keep in proportion?
The resulting design favours understandable output, strict boundaries and reproducible behaviour. An observation can be useful without becoming an accusation. A missing header, a failed request or a third-party domain may deserve review; none of those observations alone proves that a website is secure, insecure, compliant or non-compliant.
What one controlled visit can observe
For the bounded page load, the implementation can record the request sequence and redirects, first-party and third-party domains, main-document security-header observations, tracker-rule matches, cookie metadata, browser-storage indicators, console observations and failed requests. It can then present public counts, categories and finding labels derived from that run.
The distinction between observation and interpretation is kept deliberately visible. A public result states that something was observed during this bounded inspection. It does not publish the private evidence bundle, and it does not turn an absence of observation into proof that the underlying behaviour does not exist.
What the public result does not expose
The public result is designed to omit raw evidence and sensitive details. The implementation uses a separate public-result schema and stores raw evidence and assessment artifacts privately for a limited period. Public URLs are sanitised before they are returned.
The boundary around the browser
The local Build 004 candidate separates the public entry point, the Inspector and outbound network access:
Public request → ingress gateway → Inspector → controlled egress proxy → public internet
The Inspector does not own a direct public-internet route or a direct LAN route. The ingress gateway is the entry point. The Inspector requires its browser traffic to use the egress proxy; without that proxy, the interactive runner fails closed.
The input and egress layers reject local and private destinations. At the egress boundary, DNS A and AAAA results are validated and non-global destinations are rejected before the proxy connects to the approved address. This is designed to keep a public URL field from becoming a route into local services or private networks. Redirects and subresources travel through that same controlled egress boundary rather than receiving a separate unrestricted path.
The local container candidate also runs the Inspector as a non-root user, leaves Chromium’s sandbox enabled, avoids privileged mode and host networking, and configures a project-scoped seccomp profile for the Inspector service. These are engineering controls, not a claim that the tool eliminates all risk.
Public output, private evidence
A useful public interface should not quietly become an evidence leak. Build 004 assigns opaque run IDs, limits the queue, applies rate limiting and gives runs an expiry time. The browser-facing API returns a sanitised result; raw evidence and assessment artifacts are not public API routes.
That separation gives the public result an appropriate role: it is a compact record of what the bounded inspection observed. Any deeper interpretation still needs the right context and, where appropriate, human review.
A harmless example, not a scorecard
The validated local candidate successfully completed an inspection of https://example.com through the ingress gateway and controlled egress proxy. That run is useful as a harmless proof of the local workflow. It is not presented here as a security assessment of example.com, and this article does not invent a set of metrics from it.
In a public result, a reader can expect a limited summary such as observed request counts, domain categories, header states, redirect steps, storage or cookie counts, console and failed-request counts, and bounded finding labels. The exact values belong to the specific run, not to this article.
Limits that stay visible
- It observes one controlled page load, not a complete crawl of a website.
- It is not a full vulnerability scan or a penetration test.
- Its observations are evidence from a defined session, not absolute proof about a website.
- Dynamic behaviour can differ between sessions, devices, regions, consent states and user interactions.
- The absence of an observation is not necessarily the absence of the underlying behaviour.
The tool does not log in, submit forms or explore a site as a human user might. A review that needs those things needs a different scope and a different method.
What was validated locally
The Build 004 implementation handoff records a validated local candidate, not a public deployment. Its test suite was rerun with 74 passing tests and 0 failures. The local browser workflow was exercised successfully, the isolated service topology was checked, and the public-result boundary was mechanically checked for safe fields and the absence of raw private markers.
The same local acceptance record reports that an https://example.com inspection succeeded through the ingress gateway and egress proxy. It also records the limits of that validation: controlled public-origin browser integrations for a redirect to a private destination and a private-IP subresource had not been run. Keeping that distinction in the record is part of the project’s evidence-first discipline.
An evidence-first iteration
Build 004 is an engineering project in motion. The useful outcome is not a grand claim about automation; it is a narrower, inspectable path from one controlled browser visit to an explainable record. The next question is not whether to blur that boundary. It is whether the bounded result helps a real person ask better questions, while keeping the limits intact.
