Privacy monitoring

The monitoring register at /privacy/monitoring lists watched URLs, latest grade, scan status, and recent history. Add a URL to schedule an initial scan; later scans can be scheduled or requested manually. URLs are normalized to HTTP(S), with an HTTPS scheme added when missing, so equivalent root URLs do not create duplicate monitors.

What a scan observes

Depending on execution and page behavior, a scan can record:

• consent-banner presence and accept/reject controls
• whether refusal appears alongside acceptance and how many actions it requires
• cookies before consent, after reject, and after accept
• local/session storage, IndexedDB, cache storage, and frame visibility where supported
• tracker hosts and consent-related classification
• HTTPS/HSTS and selected transport signals
• Global Privacy Control test results
• linked privacy-policy resolution and bounded content/reachability evidence when enabled
• screenshots, recommendations, issue lifecycle, execution profile, and collection limitations

Grades summarize the latest comparable result. Use them to prioritize investigation, not to claim legal compliance. A scan is one automated browser observation from a declared execution profile and may differ by region, device, authentication, A/B test, language, geolocation, or consent platform state.

Register and monitor detail

Filter by status and grade, search by site, and sort by recent scan, worst grade, or name. Status can be active, scanning, failed, paused, or awaiting the first scan.

The monitor route /privacy/monitoring/[monitorId] redirects to the newest completed scan when one exists; otherwise it shows the pending monitor state. Scan detail at /privacy/monitoring/[monitorId]/scans/[scanId] contains score, issues, recommendations, evidence, cookies, storage, trackers, consent behavior, policy evidence, and a compatibility-safe timeline.

Comparisons and issue lifecycle

Noru compares scans only when execution profiles are compatible. A changed model/profile can start a new baseline segment rather than implying improvement or regression. Older-window baselines and legacy scans are labelled so users do not compare unlike observations.

Repeated scans can move issue observations through awaiting-repeat, observed-again, resolution-awaiting- repeat, and resolved states. Require repeat evidence before treating a one-off absence as a durable fix.

Recommended workflow

1. Monitor every public domain and important regional/brand variant in scope.
2. Configure regulations and data-subject regions before interpreting results.
3. Review failed, incomplete, unmanaged, or non-comparable scans before using the grade.
4. Inspect the raw evidence behind each issue and reproduce it in the relevant user context.
5. Assign remediation through your normal engineering/risk process.
6. Re-scan after the change and require repeat observations for closure.
7. Retain scan history to explain when behavior changed and under which execution profile.