Data, Privacy & Security

1. Where your data lives

Everything Octopus Scanner keeps is stored on this device, in the application's data folder unless stated: ~/Library/Application Support/Octopus Scanner on macOS and %LocalAppData%\OctopusScanner on Windows. The full details are under Locally stored data and Data persistence and removal.

---

2. This website

What this website does when you visit it. The rest of this page describes the application.

• No tracking cookies or analytics: The website contains no analytics, advertising, tracking pixels or third-party scripts.
• Nothing loads from other sites: Fonts, icons and styles are served by this website itself, and every page carries a security policy that blocks content from anywhere else. Links to other sites, such as Buy Me a Coffee or the legacy itch.io page, only contact them if you choose to follow them.
• A few preferences are saved in your browser: If you change the theme, choose Windows or macOS in the Install Guide or close a note on the homepage, that choice is saved in your browser's local storage so the site remembers it. It never leaves your device, and clearing this site's data in your browser removes it.
• Pages are saved for offline reading: After your first visit, your browser keeps a small copy of this website's styles and home page, and a copy of each page you open, so the pages you have read open without an internet connection.
  • Nothing extra is downloaded when your device is set to save data.
  • The copy stays in your browser and is replaced when the site is updated.
  • Clearing this site's data removes it.
• Checking a download stays on your computer: Check the file, in the thank-you message that appears when you download, works out the file's SHA-256 hash inside your browser. The file is not uploaded anywhere.
• Downloads: Installers are served by this website, with a SHA-256 hash published beside each one so you can check the file you received.
• Server logs: Like most websites, the web host may keep standard access logs, such as the address a request came from and the page requested, for security and reliability. Octopus Scanner does not use them to track or profile visitors.

Stored in your browser

Everything this website saves in your browser is listed below. None of it is sent anywhere or used to identify you. To remove all of it, clear this site's data in your browser's settings.

• Theme: Remembers Light, Dark or Auto if you change it with the theme button. Kept until you change it or clear this site's data.
• Windows or macOS: Remembers the system you choose in the Install Guide, so the instructions and examples match it. Kept until you change it or clear this site's data.
• Closed seasonal messages: Keeps a seasonal message hidden after you close it, for that occasion only. Kept until you clear this site's data, and has no effect after the occasion.
• Offline copy of pages: Lets the pages you have read open without an internet connection. Replaced each time the website is updated, and removed when you clear this site's data.

---

3. Your data is your responsibility

This application has no cloud, no account and no server that holds your data. That keeps you in control, and it also means the safekeeping of what a scan produces rests with you.

• Everything is stored in plain, unencrypted form: Reports, embedded screenshots, operational logs, settings, saved configurations and any recorded journeys they contain, the optional achievements file, any downloaded engine and the persistent Chrome profile are all written to ordinary files under your user account. The application does not encrypt them.
• Why it is stored this way: Reports are meant to be opened, moved, emailed, attached to tickets and handed to colleagues and clients.
  • Keeping them as ordinary, unencrypted files means they open anywhere, on any machine, with no password, key or this application required, so a report you produce today is still readable years from now by whoever you send it to.
  • Application-level encryption would work against that purpose and would give a false sense of protection once a file has been shared.
  • Confidentiality is therefore handled by the security of the device the files live on and the care you take when sharing them.
• Anyone with access to the device or its backups can read them: A report or screenshot folder copied to another location, synced to cloud storage or included in a machine backup carries the same page content with it. Protecting those files, through full-disk encryption such as FileVault or BitLocker, account passwords and sensible storage choices, is your responsibility, not the application's.
• Deletion is manual and permanent: The application never deletes a report for you.
  • Apart from its own temporary and housekeeping files, such as old log copies, crash files beyond the five most recent and a Persistent Session profile unused for 30 days (reset the next time Octopus Scanner starts), the only report files it removes itself are the unfinished pieces of a report that failed to generate and screenshots of failed user journeys (JOURNEY_FAIL files in the Reports folder), which are deleted after a week or once there are more than the five most recent.
  • Removing a report removes it; there is no copy held elsewhere to recover it from.
• Sharing a file shares its contents: Reports are designed to be shared, but once a report leaves your device you control neither where it travels nor who reads it. Review Considerations when sharing reports before sending one on.

---

4. Personal data in what you scan

Accessibility audits often cover pages that contain real people's details. This explains where that leaves you.

• The pages you scan may contain personal data: Names, email addresses, account details and anything else shown on a page can end up in a report, most obviously in screenshots, and in the page structure captured alongside each finding.
• It is processed only on your device: The developer never receives it, and no part of it is sent to any service operated by this application. There is no account, no server and no copy held anywhere else.
• Responsibility for that data remains yours: You decide what to scan, how long to keep the reports and who to share them with. The same duties apply to those reports as to any other document holding real content. Under data protection law such as the UK GDPR, this application is a tool you run rather than a service that processes data on your behalf.
• Ways to avoid capturing it: Set Screenshot Mode to Disabled to capture no images at all, or scan a staging environment with test data. Both produce a complete audit without real content in the report.

---

5. Privacy at a glance

A short summary of the privacy position. The detailed accounting further down states exactly what is stored and what is transmitted.

• No account, ever: There is no sign-up, no sign-in and no user profile. The application does not ask who you are and has no way to know.
• No tracking identifiers: No user IDs, device fingerprints, install IDs or hardware identifiers are generated, stored or transmitted. The application does create two random values for its own use, and neither leaves the device: a secret created fresh at every launch to protect the local engine, and a marker that tells the scanning interface to clear its saved data after Reset Data.
• No telemetry or analytics: Nothing about how you use the application is sent to the developer or to any analytics service.
  • Every request the application itself makes is listed under Outbound traffic for software updates: version checks on launch, the component safety check, an engine download you approve, and, only if you choose to use them, component update checks and downloads.
  • None of these carries an account, an identifier, scan data or usage data, and Offline Mode turns all of them off.
• Scan content stays on the device unless you enable Local LLM Review: Page content, findings, DOM data and screenshots are analysed locally and are never uploaded by this application to the developer or to any other service.
  • The only exception is the optional, experimental Local LLM Review, which is off by default.
  • Only when you enable it, page details are sent to the LLM server you configured on your computer or your local network, as described under Outbound traffic for Local LLM Review.
• Third-party trackers are blocked by default: While a scan is running, requests to known advertising and analytics trackers are blocked before they load, so the sites you audit are not fed signals that you visited them from this tool. This is controlled by Block Analytics Trackers, which is on by default and can be turned off if a scan needs it.
• Opt-in achievements only: The optional achievements feature is disabled until you enable it on a consent screen, keeps a small set of tallies in a single local file purely to award achievements on this device, and transmits nothing. Disabling it stops all recording.
• Sign-ins and recorded journeys stay on your device, and passwords are never saved: To reach pages that sit behind a sign-in, the scanner can pause and let you sign in yourself in the browser window, and it can replay a user journey you have recorded, a saved sequence of steps such as clicking, selecting and typing.
  • Anything involved is used only to drive the scan on this device. Anything typed into a password field while recording is marked as a Sensitive Value, and you can mark any other step the same way. Sensitive Values are hidden on screen and are never written to a saved configuration, an exported configuration file or a report, so you enter them again before each scan.
  • Other typed values, such as usernames or search terms, are saved in plain text with the configuration so the journey can be replayed, so treat saved configurations that contain a sign-in journey as sensitive.
  • Addresses you enter, including a website or proxy address containing a username and password, are also kept exactly as typed in saved configurations. Exported configuration files leave out usernames, passwords and common sign-in tokens in addresses, so you enter them again after importing.
• Bug reports contain only what you choose to send: Report Bug, then Open email, opens your own email client with a draft that includes the application version, platform, the interface's browser version string and, if a scan has run, its scan ID.
  • Nothing is attached and nothing is sent until you send it, and you can edit or remove any of it.
  • The application does not read or send your logs or scan results.
  • Reports offer an Export Bug Data button that saves a diagnostic file to your device, which you can choose to attach yourself.
  • It contains the scanned address with common credentials removed, scan counts, the viewports scanned and page layout measurements with element tags, IDs and class names, and no page text or system information.

---

6. Security

The measures below exist to protect you, your network, your credentials and the integrity of what runs on your machine. Where a measure has limits, they are stated.

Isolation and the browser sandbox

• Your own copy of Google Chrome does the scanning: The application does not bundle its own browser. It uses the Google Chrome installed in its standard location, which means scans run on a browser kept current by Chrome's own automatic updates rather than a frozen copy shipped inside this application. If Chrome is not installed in its standard location, scanning cannot start.
• The browser runs sandboxed and isolated: Chrome's operating-system sandbox and its site isolation, which places each website in its own process, both stay on, so a hostile or compromised page is kept away from your files, other processes, other sites and the rest of your system.
  • The sandbox stays on unless it is deliberately turned off.
  • It is turned off only when the scanner runs as the root (administrator) user on macOS, or when the sandbox has been deliberately turned off on your computer.
  • The app never turns it off itself.
  • When the sandbox is off, scanned pages are less isolated from your system, and a warning appears in the scan progress and the log.
• Scanned pages' own content policies are bypassed: So the scanner can inject its accessibility checks, the start page's Content Security Policy is always bypassed inside the scanning browser, and other scanned pages' policies are bypassed while Handle Trusted Types is on, which it is by default. This affects only the scanning browser, not the site or your own browser.
• Downloads are refused: Every browser the scanner launches, including the window used to record a sign-in or user journey, is set to refuse file downloads. If a scanned page, or an advert or script running on it, tries to download a file, the download is cancelled and nothing is written to disk.
• Browser options are controlled: Options entered in Custom Browser Launch Arguments are checked against a fixed allow-list, and anything not on it, such as turning off the sandbox, is dropped.
  • The allow-list does include an option to turn off site isolation, which is only applied if you add it yourself.
  • The scanner also applies its own fixed options: hiding the signs of browser automation, keeping Chrome away from your system keychain, and Chrome's standard automation defaults, which turn off background networking, sync, component updates, crash reporting and client-side phishing detection.
• Disposable, isolated sessions: By default each scan runs in a temporary Chrome profile that is discarded when it finishes, so nothing carries over between scans.
  • The optional Persistent Session profile is kept separate from any browser you use personally, is reset the next time Octopus Scanner starts once it has not been used for 30 days, and can be cleared at any time with Clear Session.
  • Entering a Login URL switches Persistent Session on, so a sign-in can be reused across the scan.
  • You can turn it off again before scanning, and each scan then starts signed out.
• Reduced fingerprinting: With Stealth Mode on, which is the default, the scanner hides automation signals and presents itself as an ordinary copy of Chrome on your computer, so scans are harder to single out.
  • Like any browser, it reports your computer's real language, time zone and type of device rather than invented ones, tells each website which of its pages linked to the next, and never changes the pages it scans.
  • If you turn Stealth Mode off, it stays off: Adaptive Networking, which slows a scan down when a site pushes back, never turns it on for you, and suggests turning it on yourself if a site keeps blocking the scan.

The local engine is locked down

The scanning engine runs as a small local service on your machine and is defended as if it were exposed.

• It is not reachable from your network: The service listens on this device's loopback address only. Other machines on your network cannot connect to it.
• Requests must prove they are genuine: On launch the application generates a fresh, random, 256-bit secret and passes it privately to the engine.
  • Apart from a status check and public resources such as the app icons, every request must carry it, through a strict, same-site cookie that page scripts cannot read or a request header. The interface's start page only hands out that cookie when it is opened through Open Interface, which uses a link signed with the secret that works once and expires after two minutes.
  • The secret itself never appears in a web address, so it cannot end up in browsing history. It is compared in constant time.
  • Requests must also address the service by its local address (localhost, 127.0.0.1 or ::1), which blocks DNS rebinding attacks.
• What this does and does not stop: Websites open in any browser cannot drive the scanner, and typing the interface's address into a browser shows a page asking you to open it from the application instead. Other software already running under your user account can no longer obtain the secret by loading the start page, though software in that position could still read your files directly.
• Cross-site request forgery is blocked: Any request that changes something, such as starting a scan, saving settings, deleting a report or opening a page in the application, must come from the application's own interface. Requests claiming to come from anywhere else are refused.
• Origin control and rate limiting: The engine accepts cross-origin requests only from its own interface, and each state-changing action is limited to 30 requests a minute, so it cannot be driven in bulk.
• Hardened responses: Interface pages carry a Content-Security-Policy with a fresh, single-use nonce for scripts, cannot be embedded in a frame (guarding against clickjacking), and can only connect back to the engine. Server-identifying headers are suppressed, every response is marked to stop MIME-sniffing, and request sizes are capped at 256 KB for settings and deletions and 10 MB otherwise.
• The apps are locked down: On macOS the application runs with the hardened runtime, keeps the Node.js project's own signature on its bundled runtime, and its data folder can only be read by your user account.
  • On both platforms, settings in your environment that change how Node.js or system libraries load are not passed to the scanner.
  • On Windows the interface window refuses camera, microphone and location requests, only loads frames and downloads from Octopus Scanner itself, and limits how many tabs or windows a page can open at once.
• Reports from elsewhere open in a safe mode: The application keeps a private record of the reports it creates.
  • A report it didn't create, such as one copied into the Reports folder from another computer, opens in a restricted mode: it is shown normally, but it cannot reach the scanner, start a scan, read results or change your settings.
  • Reports that were already in the folder when you installed this version are treated as your own.
• Reports are served safely: Report files are served read-only from the reports folder only, so no other part of your disk can be reached through the interface, and referrer information is withheld. The report list only shows files named as reports.

Traffic is protected in transit

• Encrypted connections are trusted only when valid: Update checks, the engine download and component updates use HTTPS with certificate validation left intact. The scanning browser rejects invalid certificates. No setting anywhere in the application disables certificate checking. An invalid, expired or mismatched certificate causes the connection to be refused.
• The built-in viewer refuses bad certificates: Where the application displays web content in its own window, a certificate error cancels the navigation instead of letting you continue past it.
• The scanner's own requests cannot be turned inward: Requests the scanner makes itself, such as fetching robots.txt and sitemaps, are validated first: only HTTP and HTTPS are allowed, the hostname is resolved and addresses in private, loopback or link-local ranges are refused, unless the scan itself starts on a private or local address.
  • A site name that points to both public and private addresses counts as public.
  • The connection is pinned to the checked address so it cannot be swapped for an internal one (DNS rebinding), each of up to five redirects is re-validated, and response sizes are capped.
  • This prevents Server-Side Request Forgery through those requests.
  • When a proxy is configured, these requests go through it and the proxy looks up the address, so the scanner itself refuses private addresses and local network names instead.
• Public scans stay out of your local network: When a scan starts on a public website, Chrome is blocked from loading anything on your local network (private, loopback and link-local addresses), and each blocked address is noted in the activity log.
  • The scanning browser also connects through a small built-in address check on your own computer, which looks up each site's address itself and connects only to the address it checked, so a site cannot reach your local network by changing what its name points to (DNS rebinding). If you have set a proxy, the check sits in front of it: local addresses and local network names are refused before anything reaches the proxy, and with a SOCKS proxy the checked address is the one used.
  • When a scan starts on your own computer, a local file or an internal address, this block is off, so internal and development sites can be audited normally. A start address whose name points to any public address is treated as public, so a site cannot switch the block off by also listing an internal address.
  • When a scan does start on an internal address by name, the scanning browser stays on the address that name had when the scan started, so the site cannot be swapped for another server part-way through. The same protection applies to Interactive Mode and to the browser that opens when you record a journey.
  • Local network names, such as single-word names and names ending in .local, .lan or .internal, are treated as local addresses, and WebRTC in the scanning browser can't send traffic directly to your network. Only point the scanner at sites you intend to scan.

The engine and the reports it produces are kept trustworthy

• The application verifies its own code before running it: The scanner's core is shipped encrypted.
  • Before it is decrypted, the application checks an HMAC-SHA256 authentication tag in constant time, and after decryption it checks the version recorded inside, refusing copies meant for a different version.
  • If either check fails, the scanner will not run.
  • The key used for this check ships inside the application, so it protects against corruption and casual tampering, not against someone who already has full control of your machine.
• Verified, consent-gated engine updates: An engine update is only downloaded after you approve it, and it is verified before it is used.
  • The downloaded file must match the SHA-256 checksum jsDelivr publishes for it, and it is then cross-checked against the official npm registry: the package is fetched, its integrity confirmed and the engine inside it must be byte-for-byte identical to the downloaded copy.
  • If any check fails, the download is discarded and the bundled engine keeps running.
• Captured content is neutralised in reports: A scanned page's text, headings, link addresses and code are treated as untrusted and escaped before they are written into a report, so content captured from a site cannot run as code when the report is opened.
  • Results that come back from a scanned page are also checked before they are used: rule names are cleaned, text fields must be text, and the number and length of results are limited, so a hostile page cannot break the report or fill your disk.
  • As a second layer, each report carries its own content policy with a random value unique to that report: only the report's own scripts carry it, inline event handlers are not allowed, and nothing can be loaded from other addresses, so even content that slipped past escaping could not run.
  • If this hardening step cannot be applied, the report falls back to a looser policy and the activity log says so.
  • A report opens read-only, editing is only switched on through its Enable Editing control and a report changed this way is flagged as edited.
• CSV exports cannot smuggle in spreadsheet formulas: Values that a spreadsheet could treat as a formula, those starting with =, +, -, @, a tab or a carriage return, are neutralised before they are written to the CSV export, so they are always read as plain text. Instance lists downloaded from a report's tickets are neutralised in the same way.
• Opening a report makes no outbound requests: A report loads only its own embedded data, styles, fonts and screenshots, or screenshots from its own folder, so opening one cannot signal that it was opened, when or by whom. Links inside a report, such as to scanned pages or WCAG guidance, only open when you select them, and links to external pages are opened so the destination cannot control the report window or see the report's address.
• Secrets are stripped from logs before they are written, on a best-effort basis: URLs recorded in logs pass through a redaction step that replaces common credential, token and session values with a marker and removes any username or password embedded in the address. The redaction is pattern-based, so it cannot be guaranteed and can miss an unusual value.
• Nothing updates silently: Application, engine and component updates are checked, but only applied with your explicit consent. The exact headers each check sends are listed under Outbound traffic for software updates.
• A deliberately small attack surface: With no account system, no identifiers and no server holding your data, there is no credential store to breach and no central database to compromise. All analysis is performed locally.

Component updates are verified, isolated and reversible

Separately from the engine update above, the application can update the software it is built on, its dependencies and its Node.js runtime, between releases. This is how the application is maintained each month, bringing security fixes, bug fixes and renewed compatibility with newer browsers without waiting for the next version. Notifications about these updates are on by default, and the protections below apply whenever they are used. How the application stays up to date is summarised in the Install Guide.

• Nothing is installed without deliberate decisions: Notifications about newer components are shown only while Component Update Notifications is turned on, and nothing is downloaded or installed until you review the updates on a screen that sets out what will be installed and choose to go ahead. Updating is refused while a scan is running.
• You decide how new and how much: An Update Level limits which versions are offered: Patch for bug and security fixes only, Minor to also include new features that stay compatible, or Major to also include major versions, which is where the risk of changed behaviour is highest. Minor is the default. You can switch off any individual component. Components left off stay at the version already installed.
• A waiting period guards against compromised releases: Dependency and Node.js runtime updates are only offered once they have been public for at least the waiting period, which can be set to 7, 14 or 30 days.
  • The default, and the recommended setting, is 14 days.
  • A compromised release is usually found and withdrawn within days, so waiting gives the wider community time to catch it before it reaches you.
  • The waiting period applies to the components you choose, to the Node.js runtime and to their update notifications. axe-core engine updates are not held: they are offered as soon as they are released, and are checked against their checksum and confirmed with the npm registry before they are installed.
  • Where npm allows it, the libraries those components depend on are also limited to versions published before the waiting period began; if this cannot be applied, the result screen says so.
• The shipped copy is never modified: Updated components are installed into a separate folder, and the copy that shipped with the application is left untouched.
  • Reverting deletes the new folder and the components the application shipped with are used again; nothing is downloaded and nothing has to be repaired.
  • Because the set of components is rebuilt from what the scanner actually requires, anything the newer versions no longer depend on is left out, which is why an update can report a substantial number of removals alongside its additions.
• Downloads are pinned to their official source: Dependency downloads are restricted to the official npm registry over HTTPS with certificate validation intact, and every package is checked against the integrity hash the registry publishes for it. Any npm configuration on the machine that would redirect those downloads elsewhere is ignored.
• Registry signatures must be valid: After installation, every package is checked against the signatures the npm registry publishes for it. If any signature is invalid or missing, the whole update is discarded and nothing changes.
• Package install scripts are disabled: Packages may declare scripts that run automatically at install time, the most common route by which a compromised package runs code on a machine. Every install this application performs refuses to run them.
• A new runtime must prove who signed it: A Node.js runtime is downloaded only from nodejs.org over HTTPS, must match the SHA-256 checksum published for that exact release, and must carry a valid code signature from the Node.js project, published as OpenJS Foundation on Windows and as Node.js Foundation on macOS.
  • Only long-term support releases that are past the waiting period are offered.
  • If any check fails, the download is discarded and nothing is installed.
  • The signature is checked again each time the scanner starts, and if it no longer passes, the runtime that ships with the application is used instead.
• The tool that installs components is kept in step: npm unpacks downloaded packages, so a stale copy of it would matter more than most. When a runtime update is installed, the npm published with that exact release is taken from the same verified download.
• It must load the scanner before it is kept: After downloading, the application loads every component the scanner requires using the new files. Only if all of them load is the update kept; otherwise it is thrown away and nothing changes. This proves the scanner starts, not that scans behave the same.
• A runtime that cannot start the scanner removes itself: If the scanner fails to start twice in a row on an updated runtime, that runtime is discarded automatically and the one that shipped with the application is used again.
• Updating the application clears them: Installing a new version of Octopus Scanner removes any updated components, because that version ships and is tested with its own. The screen confirming the update tells you this has happened. Updated components are also removed at startup whenever the installed copy already includes newer versions of them, and the activity log says so.
• Updated components are recorded: The application keeps a record of which components have been updated, so that they can be reverted at any time. Updating components does not change how the installation is supported.
• Honest limits: These checks prove that a package arrived intact from its official source. They cannot prove it is trustworthy, and they cannot prove the newer versions behave exactly the way the versions they replace did. If scans behave differently after an update, Revert returns to the components the application shipped with.

Installed components are checked against known malware

Every time the application starts, and once a day while it stays open, the components the scanner runs on are checked against osv.dev, a free public vulnerability database run by Google that includes the OpenSSF list of malicious packages. This is on by default and can be turned off with Component Safety Check, on the Security & Privacy screen or in Preferences under Options > Advanced.

• What is checked: Every component in use, including the libraries they depend on: those that ship with the application, any installed through Dependency Patching, and any downloaded engine.
• If a component is reported as malicious: The scanner is stopped straight away and will not start while the component is in use. A screen names each component, where it came from and a link to its report, with a way to fix it: a downloaded engine can be removed, Dependency Patching can be reverted with a restart, and a component that ships with the application points you to the Download page on this website for a fixed version.
• If a component has a security advisory: High and critical advisories, which are not malware, are shown once at startup, and you can continue scanning. An advisory you have seen is not shown again. Lower severity advisories are not shown.
• Turning it off: Component Safety Check can be turned off at any time, which stops components being checked and lets the scanner start even if a component has been reported as malicious. This exists in case a report turns out to be wrong.
• Honest limits: The check only recognises packages that have already been reported. It does not inspect what a component does, a newly compromised release may not be listed yet, and it is not a substitute for antivirus software. If osv.dev cannot be reached, components are not checked and the scanner starts as normal.

Hostile input is treated as hostile

A scanned site is never assumed to be well-behaved, so what it returns is checked and bounded before the scanner relies on it.

• Untrusted site data is sanitised before use: Structured data pulled from a scanned site, such as its sitemaps, is cleaned before it is processed, with dangerous internal keys stripped out so a crafted response cannot corrupt the application's own data structures.
• Saved scan settings are validated: When the scanner loads its saved settings file, only a fixed set of known settings is accepted and any address it contains is re-validated. Unrecognised entries are ignored.
• Built-in limits prevent exhaustion: Crawls are bounded by page limits, the scanner reads at most 500 sitemap files, each fetched file is capped at 25 MB, compressed sitemaps are capped at 20 MB when expanded (guarding against decompression bombs), and individual operations have timeouts.

Kept current

• Monthly maintenance: The application is maintained on a monthly cadence through the component updates described above: its dependencies, the Node.js long-term support runtime, and the axe-core engine.
  • Known vulnerabilities in the components the scanner is built on are addressed through these routine updates.
  • A new version of the application itself is released only to fix a security issue or bug, or to add a feature, when the monthly component updates cannot, and everything shipped in a release is tested together before release.
• A cooling-off period for releases: Official releases only include component versions that have been public for at least 14 days, giving the wider community time to find and withdraw a compromised release before it is shipped.
• The same principle between releases: Component updates between releases apply the same principle through their waiting period, and each one can be reverted at any time.

No software is flawless, and this application is no exception. The measures above reduce risk and keep you in control; they cannot eliminate it. Log redaction is best effort and pattern-based, and may miss an unusual value. The component safety check only knows about packages that have already been reported. Screenshots capture whatever the page was showing at the time. Sandboxing, site isolation and validation reduce exposure but do not make any browser or crawler invulnerable. Component updates you choose to install are verified on arrival and must load the scanner before they are kept, but this cannot prove that every scan behaves exactly as before. A waiting period lowers the chance of receiving a compromised release but cannot rule it out. Ultimately, the safety of the files a scan produces depends on the security of the machine they are stored on. Treat reports, logs and saved configurations as sensitive, keep the application updated and apply the same care you would to any other document containing real content.

---

7. Locally stored data

All output produced by a scan is written to this device. No element of a scan is uploaded by this application, except the page details sent to your own LLM server if you enable Local LLM Review.

• Update downloads: An update downloaded with Download Update is kept in an Updates folder inside the application's data folder and deleted automatically after seven days.
• Where it lives: On macOS, everything the application writes, including reports, logs, settings, achievements, the persistent Chrome profile, temporary screenshot files, a downloaded engine and updated components, is kept in ~/Library/Application Support/Octopus Scanner, except the window position, the scanning interface's zoom level and an update-failure counter, which macOS keeps in its standard preferences, the scanning interface window's browser storage, which WebKit keeps in its own data folder for the application, and the system's own web cache used by update checks.
  • Nothing is written inside the application itself.
  • On Windows, application data is kept in %LocalAppData%\OctopusScanner, with preferences in the Windows registry, and the scanning interface window's browser storage is kept by Microsoft Edge WebView2 in %LocalAppData%\OctopusScanner\WebView2.
  • Saved configurations are kept in the scanning interface window's own browser storage on both platforms, or in your default browser if Windows opens the interface there instead.
• Reports: Each scan produces a report in the selected format (HTML, CSV or JSON) in the Reports folder. HTML reports embed captured screenshots, or keep them in a folder beside the report on very large scans, and come with a companion CSV; CSV and JSON contain findings only. Reports are kept until you delete them.
• Screenshots: Captured locally during scanning and embedded in the HTML report. When a scan produces a large number or total size of screenshots, they are written to a folder next to the report instead. The temporary working folder used during capture is deleted when the scan completes, and any left behind are removed the next time the scanner starts.
• Persistent Session: Off by default, though entering a Login URL switches it on until you turn it off again.
  • When on, cookies, localStorage entries and any sign-ins persist between scans in a dedicated Chrome profile, separate from any browser you use personally.
  • Once it has not been used for 30 days, Octopus Scanner resets it the next time it starts, and it can be cleared at any time.
  • When off, each scan uses a temporary profile that is discarded when it finishes.
• Settings and saved configurations: Application preferences, including the Update Level, Waiting Period, Offline Mode, Component Safety Check and the identifiers of security advisories you have already been shown, are stored locally.
  • The scanner keeps its last-used scan settings in a file that does not include recorded journeys.
  • Saved configurations are kept in the scanning interface's local storage and include recorded journeys, with Sensitive Values such as passwords left out.
  • They also include the Local LLM Review settings, but never the API key, which is kept in its own file that only your user account can read.
  • Nothing is synced or backed up remotely.
• Achievements (optional, off by default): When enabled on the consent screen, a single file on this device records which achievements you have unlocked and when, local tallies used to award them (such as scans run, pages scanned and launches), and a short hash of the hostname of each of up to 256 recently scanned sites, never the address itself.
  • The hash is short and not cryptographic, so someone who guesses a site's hostname could confirm it was scanned.
  • This data is never transmitted, stops being recorded when the feature is disabled, and is cleared by Reset Data.
• Downloaded engine (optional): If you approve an engine update, the downloaded axe-core file is cached locally and used in place of the bundled copy. No scan or account data is stored with it.
• Updated components (optional): If you choose to update the software the application is built on, the new files are written to their own folders in the application's data folder, separate from the copy that shipped with it: roughly 100 MB for dependencies and roughly 120 MB for a Node.js runtime and the npm published with it, along with a small download cache, a list of the licences of the installed components, and a record of which version is in use.
  • No scan or account data is stored with them.
  • Using Revert returns the application to the components it shipped with.
• Operational logs: On macOS, the activity log is written continuously to session.log, which is rotated at 10 MB with one previous copy kept, and if the scanner crashes a crash file containing recent log lines is saved, with the five most recent kept, and details of application errors are appended to logs/crash.log, which is rotated at 1 MB.
  • On Windows, the activity log is kept in memory and only saved when you use Export Activity Logs, and details of application errors are appended to logs\crash.log, which is rotated at 1 MB.
  • URLs in log lines pass through the pattern-based redaction described above.
  • Review logs before sharing them in a support request.
• Scan results while a scan runs: As each page finishes, its results are written to a temporary file in a folder for that scan inside the application's data folder, and the report is built from these files rather than from memory.
  • The folder is deleted once the report is finished.
  • If a scan is cancelled or the application stops unexpectedly, any folder left behind is removed the next time the scanner starts.

---

8. Outbound traffic to the site being scanned

To produce an accessibility audit, the scanner must load the pages you nominate. That traffic goes from this device to the site being scanned.

• Page and resource requests: Standard HTTP and HTTPS requests for each scanned URL and the assets it references (scripts, stylesheets, images, fonts).
• Allowlist Header: Only if you set one, the header and its value are sent to the website you're scanning, and to no other website. The value is kept in the app while it's open and isn't saved with your settings, configurations, logs or reports.
• User Agent header: The scanner never identifies itself as Octopus Scanner in its requests. With Stealth Mode on (the default), it sends a standard Chrome User Agent for your computer, with matching browser hints. With Stealth Mode off, it sends Chrome's own User Agent, or your custom one if set. User Agent substitution may conflict with the Terms of Service of some sites.
• robots.txt: By default the scanner fetches the site's robots.txt and honours the rules it declares for all crawlers, along with any rules written for OctopusScanner. This matching happens on your device, so the scanner still doesn't name itself in its requests. This stays on unless Respect robots.txt is turned off.
• Sitemap files: By default the scanner reads sitemaps declared in robots.txt to find URLs before the crawl. An explicit sitemap URL, if provided, is fetched as well. Sitemaps declared in robots.txt are skipped when Respect robots.txt is off or Ignore Sitemaps Discovered In robots.txt is on.
• Connection checks: While a scan is running with Connection Recovery on (the default), the scanner periodically looks up a hostname through your system's DNS resolver to detect when the connection drops: the scanned site's, or the proxy's when a proxy is configured. Local and private addresses are not checked.
• Proxy routing: If a proxy server is configured, all traffic to the scanned site goes through it: the pages loaded by the scanning browser and the scanner's own robots.txt and sitemap requests.
  • HTTP, HTTPS, SOCKS4 and SOCKS5 proxies are supported, including a username and password, which is used for the scanner's own requests and, on scans of public websites, for the scanning browser.
  • HTTPS stays encrypted end to end and certificates are still checked.
  • When a list of proxies is used, the scanner's own requests go through the first one.
• Safety measure: When a scan starts on a public website, the scanner's own robots.txt and sitemap requests refuse private, loopback and link-local addresses and re-validate redirects, and pages are blocked from loading anything on your local network, as described under Security.
• Local files, when you choose them: If you point the scanner at a local file, it audits that file directly on this device and makes no network request for the file itself. Anything the file references on the web, such as images or scripts, is loaded as normal.

---

9. Outbound traffic for software updates

Checks so application, engine and security updates are not missed, and so known malicious components are caught. Every update is applied only with your consent.

• Offline Mode: Turning on Offline Mode, on the Security & Privacy screen or in Preferences under Options > Advanced, stops every request in this section: version checks, the component safety check and component update checks. Dependency Patching and Node Runtime updates are unavailable while it is on. Scans still load the sites you choose to scan.
• Application version check: One HTTPS GET to a small file on this website (octopusscanner.com/latest.json), issued on launch, that contains the latest version number and the details of its installers. If this website cannot be reached, the application checks the legacy itch.io page instead, retrying up to twice if that fails.
• Application update download: Only when you select Download Update: one HTTPS GET for the signed release information on this website (octopusscanner.com/latest.json and its signature), then one HTTPS GET for the installer from downloads.octopusscanner.com. The application refuses any release information that is not signed with the developer's key, and any file whose size or SHA-256 checksum does not match, and deletes it. No cookies or identifiers are sent.
• Engine version check: One HTTPS GET to the public npm registry (registry.npmjs.org) to read the latest published version number of the axe-core engine, issued on launch.
• Component safety check: On launch, and once a day while the application is open, one HTTPS POST to the osv.dev API (api.osv.dev) containing the name and version number of each component in use, followed by an HTTPS GET for the details of each advisory that matches, up to 400. Nothing else is sent. The check runs unless Component Safety Check or Offline Mode turns it off.
• Dependency Patching check: Before Dependency Patching downloads anything, one HTTPS POST to the osv.dev API (api.osv.dev) containing the name and version number of each component it plans to install, and, if the download contains anything not on that list, a second check for those components. The update is refused if osv.dev cannot be reached.
• Headers: No request carries an account, machine identifier, scan data or usage metric.
  • On macOS, requests use the system's default User Agent, which names the application and its version along with the versions of the macOS networking components.
  • On Windows, the version checks, the signed release information and the osv.dev checks send a standard desktop Chrome User Agent, the application and engine downloads send "OctopusScanner", and component update checks and Node.js downloads send no User Agent.
• Response handling: The website's version file, or the legacy itch.io page, and the registry response are read for version numbers and compared with the installed versions. If a newer version exists, a prompt is shown. The decision to update remains yours.
• Engine download: Only if you accept the engine update prompt, the new axe-core engine is downloaded over HTTPS from jsDelivr (cdn.jsdelivr.net), and its published SHA-256 checksum is read from data.jsdelivr.com.
  • The file must match that checksum, and it is then cross-checked against the official npm registry (registry.npmjs.org): the package is fetched, its integrity verified and the engine inside it must be byte-for-byte identical to the downloaded copy.
  • If any check fails, the download is discarded and nothing is installed.
  • If you decline, or the download does not complete, the bundled engine continues to be used.
• Component update check (optional, on by default): Only while Component Update Notifications is turned on, or when you open the Dependency Patching or Node Runtime screens, the application reads the published release list from nodejs.org and, from the npm registry, the published versions and publication dates of each component the scanner requires. These are read-only requests for public information, and no component is downloaded by the check itself.
• Component download (optional): Only if you choose to install them on the Dependency Patching screen, the versions of the components you selected, within your Update Level and Waiting Period, are downloaded over HTTPS from the official npm registry, with each package checked against its published integrity hash and install scripts disabled throughout. They are installed alongside, never over, the copy that shipped with the application.
• What npm sends during a component download: The download is carried out by npm, which adds its standard request headers: the npm and Node.js versions, the operating system and processor type, and the name of the npm command being run.
  • To apply security fixes, npm also sends the names and version numbers of the scanner's components, and of the libraries they depend on, to the npm registry's public security advisory service.
  • To verify signatures, it fetches the registry's public signing keys.
  • No account, identifier, scan data or information about you is included.
• Runtime download (optional): Only if you choose to install it on the Node Runtime screen, a Node.js long-term support release that is past your Waiting Period is downloaded over HTTPS from nodejs.org, checked against the SHA-256 checksum published for that release, and required to carry a valid Node.js project code signature before it is used.
  • The npm published with that release is taken from the same download.
  • If any check fails, the download is discarded.

---

10. Outbound traffic for Local LLM Review

An optional feature that asks a large language model (LLM) you run yourself to review scan findings. Octopus Scanner uses no AI unless you turn it on, and your scan data stays on your computer.

• Local LLM Review (optional, off by default):
  • Where requests go: Only when you enable it, the application sends requests to the LLM server you configured, which must be on your computer or your local network. Internet addresses are refused, and a server name is accepted only if every address it resolves to is on your computer or a private network.
  • Test Connection: Sends one request to the server to list its models.
  • Page details sent during a scan: The page title, language and address without its query, the heading outline, images (accessible name or alternative text, role, file name and nearby text), links and buttons (accessible name, link path and surrounding text), form field labels, placeholders and descriptions, the HTML of elements with axe-core findings and their failure summaries, any custom instructions you entered, and, while Include Screenshots is on, screenshots of reviewed pages and issues.
  • Depending on the categories you turn on: Short passages of page text with the language they are marked with, the text that follows each heading, the words shown on controls where they differ from the accessible name, video and audio details, the order of content in the code and on screen, navigation links compared across pages and measured contrast ratios.
  • Focus Visible and Form Errors: With Focus Visible on, it sends each keyboard focus stop's name and focus styling, and, while Include Screenshots is on, small crops of focus stops with no visible change. With Form Errors on, it sends each checked field's validation rules, the browser's built-in validation message, and how error messages are linked to the field, but no input values; password, file and payment card fields are left out.
  • Screenshots: Include Screenshots is on by default when you enable the review, and screenshots stop being sent if the model can't read images.
  • Never sent: Form values, passwords and Sensitive Values are never sent. Nothing is sent to a cloud AI provider or to the developer, and these requests do not go through a proxy configured for the scan. HTTPS certificates are always checked.
  • Your API key: The optional API key is sent only to the server it was saved for. It is stored in a file only your user account can read, without encryption, and is never included in saved or exported configurations. Select Forget Saved Key to remove it. Use a key made only for your LLM server.
  • Logs and clean-up: Prompts, the model's full responses, page content and the key are not logged; only short progress lines are, such as the issue type and page checked, whether the model confirmed it and how sure it was, skipped requests, counts, timings and errors. Screenshots taken for the review are deleted when it finishes.
  • Your server: You choose and operate the LLM server and model, and how that server handles what it receives is governed by its own software and settings. See Local LLM Review.
• Finding LLM servers (only on request): Nothing is searched for unless you select Find Servers or Search Local Network in the Local LLM Review settings.
  • Find Servers contacts only this computer. Search Local Network first asks you to confirm, then, for up to about 20 seconds, contacts the devices on this computer's own private local network, and never public or internet addresses.
  • Both try a few ports that LLM servers commonly use, and where something answers, request its list of models over HTTP or HTTPS, using any Trusted Certificate you have added to check HTTPS servers. Nothing else is sent: no API key, page details, scan data or identifier.
  • Some workplace networks treat this kind of search as network scanning. The servers found are shown to you and are used only if you select Use.

---

11. Software Octopus Scanner relies on

Some of the software this application uses is made by others and follows its makers' own privacy terms.

• Google Chrome: Scans run in your installed copy of Google Chrome. The scanner launches it with background networking, sync, component updates and crash reporting turned off, but Chrome remains Google software governed by Google's terms.
• The interface window: The scanning interface is displayed using the system web view: Apple's WebKit on macOS and Microsoft Edge WebView2 on Windows. These components are governed by Apple's and Microsoft's terms respectively, including any diagnostic data settings on your system.
• Links you open: Links to guides, release notes and other pages open in your default browser only when you select them.

---

12. On-device analysis

So findings are reproducible and no page content is exposed beyond the scanning device, all analysis is performed locally.

• Engine: Findings are produced by axe-core, an open-source accessibility rules engine maintained by Deque Systems. A copy is bundled with the application. A newer version can be downloaded, but only after you approve the update prompt; once downloaded it is stored and run locally exactly as the bundled copy is. The engine is never updated silently.
• Execution: The engine, whether the bundled copy or an approved downloaded version, is injected into each page and into every frame embedded in it, including frames from other sites, and runs inside Chrome on this device, evaluating them against WCAG and best-practice rules. The results from each frame are combined on this device.
• Supplementary checks: Every supplementary check the scanner performs, such as PDF checks, link discovery, multiple viewport rescans and dark mode rescans, runs locally in the same way.
• No content leaves the device: Page content, finding data, DOM extracts and screenshots are not transmitted to any external service. The only exception is the optional Local LLM Review, which, only when you enable it, sends page details to the LLM server you configured on your computer or your local network.
• Work or school organisation check (Windows): Only if you start it yourself and accept the screen that explains it, the Windows app asks Windows for the Microsoft Entra ID tenant ID of the work or school organisation your computer is joined to.
  • The ID is converted to a SHA-256 fingerprint and compared on your computer.
  • It is never sent anywhere and never saved.
  • It is never read on macOS, or on Windows unless you start the check.

---

13. Excluded practices

Stated explicitly so what is absent cannot be assumed to be present.

• No telemetry, analytics or usage metrics are transmitted. The optional, opt-in achievements feature keeps usage tallies in a local file purely to award achievements on this device; these are never sent anywhere, and nothing is recorded while the feature is disabled.
• No integrated crash reporting service. Errors and crash details are written to local files only.
• No user account is required or supported. No user or device identifiers (UUIDs, hardware fingerprints, install IDs) are generated, stored or transmitted.
• No user data is shared with any third party.
  • The only requests the application makes for itself are the update checks described above, the component safety check, which sends component names and versions to osv.dev, the engine download if you approve it, and, if you choose to use them, the optional component checks and downloads, including the security advisory lookup npm performs.
  • None of these carries account, identifier, scan or usage data.
  • The optional Local LLM Review, only when you enable it, sends page details to the LLM server you configured on your computer or your local network, and never to a cloud AI provider.
  • Its Find Servers and Search Local Network buttons, only when you select them, contact this computer or devices on your local network to find LLM servers, and send nothing but requests for a list of models.
• When you submit a bug report, no logs or scan results are attached or sent by the application; it is composed in your own email client, pre-filled with the application version, platform, browser version string and last scan ID, which you can edit before sending.
  • While updated dependencies are installed, any bug report email opened from the application is marked as coming from an installation with updated components, with a marker in the subject and a line in the message saying so.
  • They carry nothing else.

---

14. Considerations when sharing reports

Reports are intended to be shared. The following points are worth understanding before doing so.

• Screenshots reflect the page at the moment of scanning: If the page displayed real customer names, email addresses, account details or other confidential content during the scan, that content will appear in the screenshots. Setting Screenshot Mode to Disabled prevents any screenshots from being captured or written to the report. Scanning a non-production environment achieves the same outcome.
• Reports are normally self-contained: HTML reports embed their screenshots, so anyone with the file has every screenshot it contains. When screenshots are written to a folder next to the report instead, that folder holds the same captured content and should be shared with the same care.
• Reports include the scan settings used: HTML reports embed the settings the scan ran with, so a recipient can see how it was produced. This includes the scanned address, the Login URL and any proxy address, with common credentials removed, and any recorded journey steps, with Sensitive Values and anything typed into fields that look like password fields removed, but other typed values, such as usernames, kept.
• Reports include diagnostic data: HTML reports contain the diagnostic data used by Export Bug Data: the scanned address with common credentials removed, scan counts, the viewports scanned and page layout measurements with element tags, IDs and class names.
• Stamping: If Stamp Screenshot is enabled, the rule ID, rule description, primary recommendation and the failing HTML snippet are overlaid on each screenshot. Review before distributing externally.
• Reports record the version that produced them: Every HTML report shows the version of the application that produced it, so a recipient knows how it was generated.
• Sign-in values in addresses are hidden: In HTML reports, CSV and JSON files, the values of address parameters commonly used for sign-in, such as token, session, code, key and password, are replaced with [REDACTED], and any user name or password written into an address is removed.
  • Pages whose addresses differ only in those values are listed as a single page.
  • The redaction is pattern-based, so check addresses before sharing a report.

---

15. Data persistence and removal

What data persists, where and what is required to remove it.

• Reports: Kept in the Reports folder until you delete them; the application never deletes a report automatically. Reports you delete from the interface are removed together with their screenshot folders and screenshot ZIP files. When an HTML report has a companion CSV, the application asks whether to delete the companion CSV too.
• The Persistent Session profile: Holds cookies, localStorage entries and sign-ins from scans run with Persistent Session on. It can be cleared with Clear Session at any time except while a scan is running, and is reset the next time Octopus Scanner starts once it has not been used for 30 days.
• An authenticated scan leaves a live session on disk: If you sign in during a scan while Persistent Session is on, which entering a Login URL does by default, the cookies and tokens that keep you signed in are written into that Chrome profile and stay there between scans.
  • Until they expire or are cleared, anyone with access to this device and profile could use them to reach the account you signed in to, without needing your password.
  • If you have scanned something sensitive under a login on a shared or temporary machine, clear the session, or leave Persistent Session off so each scan starts signed out.
• Saved configurations: Kept in the scanning interface's local storage until you delete them or use Reset Data. Those containing sign-in journeys hold typed values such as usernames, but never Sensitive Values such as passwords.
• Downloaded engine: If an engine update has been approved, the downloaded axe-core file is cached in the application's data folder and persists until deleted. Removing it returns scans to the bundled engine.
• Updated components: If installed, they persist in their own folders in the application's data folder until removed. Revert removes them and returns the application to the components it shipped with, taking effect the next time it starts. Installing a new version of the application removes them automatically.
• Achievements: If the feature has been used, its file is kept in the application's data folder until removed. Reset Data clears it; disabling achievements stops any further data being written.
• Reset Data: Clears the activity log, accepted agreements, achievements and all settings, including update preferences, and returns the application to its initial setup.
  • It also clears everything the scanning interface has saved, including the setup walkthrough, saved configurations and any recorded journeys they contain, the theme, the Show All Settings choice, and Local LLM Review settings including any API key.
  • It also deletes the activity and crash log files. The last-used scan settings file is deleted the next time the scanner starts. It does not delete reports, the persistent Chrome profile or a downloaded engine.
  • It also removes updated components, including an updated Node.js runtime, the npm download cache and downloaded app updates, unless an app update is downloading or ready to install.
• Uninstalling on macOS: Moving the application to the Trash removes the program only. Reports, logs, settings, achievements, the persistent Chrome profile, a downloaded engine and updated components remain in ~/Library/Application Support/Octopus Scanner until you delete that folder, and saved configurations remain in the interface's storage unless cleared first with Reset Data.
• Uninstalling on Windows: Uninstalling from Installed apps removes the program, its downloaded components, caches and logs, the Persistent Session profile and any sign-ins it holds and the Open At Login entry.
  • It then asks whether to keep your scan reports and settings, including saved configurations, which are kept in %LocalAppData%\OctopusScanner and the Windows registry.
  • Choosing to delete them removes both.
  • Keeping them is the default, and a silent uninstall always keeps them.
  • If you keep them, delete that folder at any time to remove them.

---

16. Who is responsible and your rights

• Who is responsible: Octopus Scanner and this website are developed and published by Lachlan Thompson, in Scotland, who is responsible for any personal data described in this document, such as emails you send to support.
• Your rights: Under UK data protection law you can ask for a copy of the personal data held about you, and ask for it to be corrected or deleted, or object to how it is used. Email support@octopusscanner.com. Most of what this document describes stays on your own device and is never sent to us, so there is often nothing held about you.
• Complaints: If you are unhappy with how your data has been handled, you can complain to the Information Commissioner's Office at ico.org.uk.

---

17. Questions and reporting a problem

• Questions about this document can be sent to support@octopusscanner.com, or raised through Report Bug in the application, which opens your own email client with nothing attached.
• Security issues: If you believe you have found a security problem, please report it privately to support@octopusscanner.com, with enough detail to reproduce it, rather than posting it publicly. Issues in Octopus Scanner itself are fixed in a new release, and issues in the components it runs on are fixed through component updates. The Security Policy explains what to include and what happens next.
• Changes to this document are published with the release that changes the behaviour, so this document always matches the application it describes.

---