How Plainsight checks a website

This document is the contract. If a report ever says something this document doesn't explain, that is a bug.

Principles

1. Evidence or silence. Every finding shows what was measured and how. If we can't measure something, the finding says "Couldn't check". We never guess quietly.
2. Read-only. Plainsight does what one visitor's phone does, plus reading public files every search engine reads. It never logs in, submits forms, guesses hidden paths, or tests for vulnerabilities.
3. No AI judges the site. Findings come from written rules in src/checks/ and src/profiles/. The same page always gets the same findings.
4. No overall score. A single number hides more than it shows and invites gaming. Reports count what's urgent, worth fixing and working.
5. Good news counts. What already works is reported too, so owners see an honest picture instead of a sales pitch.
6. Labelled confidence. Measured means read directly from the page, headers or network. Best guess means a pattern match (for example "is there a price on the page?") and can be wrong.
7. The report itself is private. It is a single file with a Content-Security-Policy that blocks all network access. No fonts, scripts, trackers or images load from anywhere.
8. The same for everyone. Findings don't change based on who ran the scan or whether anyone is selling anything. An optional "Prepared by" note sits at the end, clearly separate.

What one scan does

Every request to the site carries Plainsight/<version> (read-only website check) in its user agent.

When you use the website

The website runs the same checks, with a few extra rules because anyone can use it:

• No private networks. Every address the scan touches is looked up first: redirects, files and WebSocket connections the page makes, and our own requests. Private, loopback and cloud-metadata addresses are refused. The browser never saves downloads.
• A time limit. A check stops after two and a half minutes, whatever the page does.
• One site, one visit. If the same site was checked in the last 10 minutes, you see that result instead of a new visit. Results are kept in memory only for those 10 minutes, then discarded. Nothing is written to disk, and the server's logs never record which site was checked or who asked.
• What the site stores on your device. Only your light or dark choice, in your browser's local storage. No cookies.
• Fair use. Each visitor can run 6 checks per 10 minutes (on IPv6, per home network rather than per address). Checks run two at a time, with up to 20 waiting, and there's a ceiling of 2,000 fresh checks a day.
• Fair to the sites being checked. Each site gets at most 3 fresh checks an hour, however many people ask; anyone else sees the saved result. Changing the part of the address after "?" doesn't count as a different site.
• Owners can opt out. Add this to your site's robots.txt and Plainsight will never visit it:

User-agent: Plainsight then Disallow: /

This is read before any visit. A general User-agent: * rule doesn't stop a check, because it's meant for search engines indexing a site, not a single visit someone asked for.

• Only from our own page. Checks are accepted only from the Plainsight website itself, not from other sites or simple scripts.
• The report can't run code. It's shown in a sandboxed frame, and every page locks its scripts to exact fingerprints (hashes), so nothing else can run.
• The scanned address isn't in the page address. It's sent in the request body, so it doesn't end up in browser history or referrer headers.
• Help is optional and comes last. Below each report there's a way to contact Nilabh Studio. The report above it doesn't change either way.

The checks

Code and secrets (apps and websites)

• Leaked secrets: the JavaScript the homepage downloads from its own domain (up to 80 files, 15 MB), plus the page itself, matched against the published formats of Stripe secret and restricted keys, OpenAI, Anthropic, AWS, GitHub, Slack and SendGrid keys, private keys, database addresses with passwords, and Supabase service-role keys (recognised by what the key says about itself). Values are masked as soon as they're found; the full value is never stored or shown. Sample strings from library docs (user:password@localhost) are ignored. Google API keys and Supabase anon keys are noted, not counted: they're designed to be public.
• On the website, secrets are reported without their file name, so a report anyone can request can't serve as a map for an attacker. The command-line tool shows the file.
• Development mode: the Vite or webpack dev server, a Next.js development build, React or Vue development builds.
• localhost: requests to localhost, 127.0.0.1 or 0.0.0.0 during load (measured), or such addresses in the code (best guess).
• Public source maps: the map file named by sourceMappingURL answers 200.
• Errors on first load: uncaught JavaScript exceptions; console errors are counted alongside.
• Failing requests: data requests (fetch, XHR) that fail or answer 4xx/5xx. Analytics and ad services are left out, and 401/403 are noted separately because they're normal when an app checks for a signed-in user.

Getting in touch (local-business profiles only)

• First screen: are tap-to-call, WhatsApp or the profile's main action (Book, Book appointment, Contact) visible within the first 412×839 px without scrolling?
• Tap to call: tel: links; phone-number patterns in visible text that aren't links.
• WhatsApp: wa.me, api.whatsapp.com, web.whatsapp.com, whatsapp: links.
• Directions: Google Maps links or embedded map frames.

Speed on a phone (lab measurements; one run varies by about ±20%)

• Second load when borderline: if the first load's main content takes over 2 s, or the full load over 8 s, the page is loaded once more and the faster run is reported. Both numbers are shown. A slow result has to happen twice before it's called a problem.
• Main content: Largest Contentful Paint. Good ≤ 2.5 s, worth fixing above that, urgent above 8 s.
• Fully loaded: the load event, reported when it's over 10 s. It's steadier than Largest Contentful Paint on pages with sliders, where the "main content" element can change between runs.
• JavaScript: compressed bytes of every script. Under 350 KB is comfortable on phones; over 1 MB is heavy.
• Data used: compressed bytes transferred during load. Good ≤ 1.5 MB, urgent above 5 MB. The five largest files are listed.
• Oversized photos: visible images over 2.5× their displayed width and over 150 KB.
• Server response: time to first byte. Chrome's network simulation doesn't apply to this number, so it's the real server time from the machine running the scan. Good ≤ 0.8 s.
• Layout shift: Cumulative Layout Shift during load. Good ≤ 0.1.
• Real visitors (optional): Chrome User Experience Report 75th-percentile data via PageSpeed Insights.

Being found

• Hidden from Google: noindex in the robots meta tag or X-Robots-Tag, or robots.txt blocking Googlebot from the page. robots.txt is read the way Google reads it (RFC 9309): the most specific group applies, the longest matching rule wins, and on a tie Allow wins.
• Phone-ready: a viewport meta tag.
• Title (60–65 characters shown) and description.
• Link previews: og:title and og:image, whether the image loads, is a full https address and is under 5 MB, and whether the tags are in the HTML as first delivered. Preview bots (X, LinkedIn, Slack, WhatsApp) don't run JavaScript, so tags added by JavaScript are invisible to them.
• X card: twitter:card, ideally summary_large_image.
• Empty without JavaScript: under 150 characters of text before JavaScript runs, against a full page after.
• Google Discover: max-image-preview:large in the robots meta tag (a note).
• Icons: a favicon, and an apple-touch-icon for iPhone home screens.
• Structured data: JSON-LD types that fit the profile (for apps: Organization, SoftwareApplication, WebSite; for local businesses: LocalBusiness, LodgingBusiness, Dentist…).
• Sitemap: see the table above.

Visitor privacy (everything recorded on first load, with no clicks or consent)

• Advertising trackers and analytics: third-party requests matched by domain against src/data/thirdparties.js, which separates advertising, analytics, cookieless analytics, session replay, tag managers, embeds, fonts and CDNs.
• Cookies: every cookie in the browser after load. Names with a well-documented tracking purpose (_ga, _fbp, _gcl_au, _clck, ph_*…) are listed with that purpose. Others are listed as "purpose not identified", never guessed.
• Browser storage: localStorage keys, so cookieless tools that still identify visitors are visible.
• Session replay: Hotjar, Clarity, FullStory and similar tools.
• Privacy policy: a homepage link containing "privacy", checked when the site has a form or trackers.
• Google Fonts, standard YouTube embeds, forms posting to another domain: reported as "Good to know", not as problems.
• Cookie banner: a pinned, visible element mentioning cookies or consent. Best guess.

Security (passive only)

• HTTPS, http→https redirect, certificate validity and expiry.
• Six response headers: HSTS, X-Content-Type-Options, clickjacking protection (X-Frame-Options or CSP frame-ancestors), Content-Security-Policy, Referrer-Policy, Permissions-Policy.
• Version disclosure in Server, X-Powered-By and generator tags. PHP below 8.2 is flagged as out of security support (php.net/supported-versions).
• Mixed content, and forms that post over http://.
• Login-style cookies from the site's own domain (names like session, token, auth) that aren't HttpOnly and Secure.
• Known-compromised code hosts: any request to polyfill.io or its sister domains (bootcss.com, bootcdn.net, staticfile.org, staticfile.net), which served malware after a 2024 takeover.
• Libraries with known vulnerabilities: the version jQuery, Bootstrap, lodash, AngularJS and Vue report about themselves, compared with published advisories (for example jQuery below 3.5.0, CVE-2020-11022) and end-of-life dates.
• Server software past end of life: PHP, nginx and Apache versions from the server's own headers, compared with endoflife.date. The data is refreshed into the code with npm run refresh-data, so scans don't depend on that site.
• CDN scripts without integrity: scripts from public CDNs (cdnjs, jsDelivr, unpkg) without an integrity hash. Tag managers and analytics can't use one, so they aren't flagged.
• Short HSTS: a Strict-Transport-Security max-age under six months.
• Error traces: Python, Django, Laravel, PHP, Java or Next.js error output visible on the page.
• security.txt: the standard /.well-known/security.txt file (RFC 9116) with a Contact line, so researchers can report problems privately.
• WordPress: the version comes only from WordPress's own generator tag or files that ship with core (wp-emoji-release.min.js, block-library styles). Bundled libraries are never used. The theme and plugins come from /wp-content/ paths already in the page, so plugins that add no files to the homepage aren't visible. The latest version comes from api.wordpress.org.

Upkeep

• Footer copyright year more than a year old.
• Broken links (up to 20 checked), files on the site's own domain that return 4xx/5xx, JavaScript errors.
• Images without an alt attribute (alt="" counts as intentional), buttons and links with no accessible name (icon-only), form fields without a label, disabled zoom, missing lang.

How rules are added

Every rule lives in src/rules/registry.js with a name, the most serious result it can give, a source, the date it was added and a version. The rule catalogue below is generated from it. A new rule:

1. comes with tests that must match and tests that must not;
2. starts as beta: shown one level softer and marked "New check";
3. runs on the golden corpus (fixed test sites with known problems, plus real sites compared against an approved baseline), and any new finding there is reviewed by a person;
4. becomes stable after a few weeks without a false alarm.

Changing what a rule matches bumps its version, and every finding in a report shows the rule and version that produced it.

Profiles

A profile adds checks for one kind of site and decides which problems go to "Start here". It never changes the core checks.

• app (the default, and the only one on the website for now): apps, SaaS products, side projects and launch pages. Adds a clear call to action on the first screen, privacy policy and terms links (Stripe, Google sign-in and app stores ask for both), and a way for users to reach you.
• homestay, clinic, general (command line only for now): local businesses. Add tap-to-call, WhatsApp, directions, and checks for their kind of business: direct booking and prices for homestays, timings and qualifications for clinics.

"Start here" picks three problems: urgent first, then the ones weighted highest for the profile, then ones the owner can fix themselves. Problems that block every visitor (a leaked secret key, an invalid certificate, no HTTPS, hidden from Google, not phone-ready) always outrank the rest.

Rule catalogue

All 101 rules, generated from the code. 19 are new (beta): they're shown one level softer and marked "New check" until they've run on our test corpus for a few weeks without a false alarm. "Fix now" is the most serious result a rule can give. End-of-life data from endoflife.date, refreshed 2026-10-21.

Code and secrets

Security

Speed

Being found and shared

Visitor privacy

Polish

Apps

Local businesses

Homestays

Clinics