← back to v152 · suspicious-site-warnings
conformance · v152
v152 · suspicious-site-warnings — conformance probe
6 assertions drawn from the spec. Each is a single contract the spec text makes. Pass/fail reflects what this browser executed; blocked means the contract was not run because it needs user mediation, hardware, or another unavailable precondition. Open the page in Chrome stable / canary / Firefox / Safari to compare.
0
pass
0
fail
0
blocked
6
total
| id | contract | kind | verdict | detail |
|---|---|---|---|---|
no-api-exposes-a-safe-browsing-verdict |
The central contract of this feature, stated as an assertion so it stays true: no plausible surface exposes a safety verdict to a page. A detectable warning would be a defeatable one — a page could behave differently when it knew it was being judged. spec ↗ | script | … | |
the-absence-check-itself-works |
The control that makes the assertion above worth anything: the same technique must find something that exists and miss something that does not. Without it, a broken probe and a genuine absence are the same result. spec ↗ | script | … | |
the-reporting-mechanisms-that-exist-report-your-own-page |
ReportingObserver and CSP violation events are real, and are regularly mistaken for a safety channel. They carry information outward from your page to you, which is the opposite direction — asserted so the distinction the demo draws rests on something checkable. spec ↗ | script | … | |
markup-can-be-parsed-without-executing-it |
The audit tool parses pasted markup with DOMParser, which builds a document without running scripts or loading subresources. Anything else would make a tool for auditing suspicious markup dangerous to use. spec ↗ | script | … | |
url-parsing-alone-does-not-validate-a-hostname |
The trap the links page fell into: new URL() accepts nonsense and percent-encodes it into a hostname rather than throwing. A tool that builds links from user input has to check the hostname shape separately. spec ↗ | script | … | |
a-relative-url-inherits-the-page-scheme |
Why the insecure-subresource check looks only at absolute http:// URLs. On a plain-http development server every relative path resolves to http, which made this page report three findings against itself until the check was narrowed. spec ↗ | script | … |