Scope & tools

What this site does, and what it doesn’t

This page is the operator-facing summary: what the tools here do at the network level, and how to get in touch if something looks off. If anything below is contradicted by the code, the code wins and this page is wrong — please email [email protected] and I’ll fix it.

For the per-check technical detail of the beacon scanner, see /methodology. For editorial standards on writing about real organisations, see /research-ethics.

Last reviewed 6 May 2026.

What this site hosts

Four categories.

Writing. Research notes and essays. Reporting on public information. Not advice of any kind.
In-browser tools. PDF Changer and vault run entirely in your browser. No file you process is uploaded. The Content-Security-Policy on those pages blocks outbound network access from inside the tool.
Hosted analysers. Two endpoints make outbound network requests on your behalf: the /api/analyse endpoint (the Bitcoin address visualiser for ε-tx) and beacon.giuseppegiona.com (the website security scanner). Each is described below.
Open source. Project pages link to repositories on GitHub. The code there is distributed under the LICENSE file in each repo. Nothing on this site grants any further licence.

/api/analyse — Bitcoin address visualiser

You submit a Bitcoin address. The endpoint reads transaction history for that address from the public Blockstream Esplora API. It doesn’t contact the address owner, any wallet, any exchange, or any system that could be characterised as not public. Data on the Bitcoin blockchain is, by design, world-readable.

The result is a graph and a set of information-theoretic estimates of how much identifying information the transaction pattern leaks. There’s no attempt to deanonymise any specific person; the output is bounded uncertainty, in bits.

Network footprint: HTTPS GET to blockstream.info and a small set of public bridge APIs. Rate-limited at one analysis per 30 seconds per IP. Inputs and one cached result are held for up to one hour to limit duplicate calls to upstream APIs.

beacon.giuseppegiona.com — website security scanner

beacon is the only tool on this site that sends network requests to a third-party domain you choose. Each check is described below, with what it does and what it doesn’t.

The seven checks

TLS: Opens a TCP connection on port 443, performs a TLS handshake, reads the certificate chain and negotiated parameters. No application-layer request.
Headers: Issues a single unauthenticated HTTPS GET to the root path. Reads response headers (CSP, X-Frame-Options, Referrer-Policy, Permissions-Policy, HSTS). Doesn’t follow redirects beyond the canonical host.
Email auth: Resolves DNS records: TXT for SPF and DMARC, TXT under 18 common DKIM selectors, the MX record, and DNSSEC chain state. DNS lookups, no email is sent.
Exposed paths: Issues unauthenticated HTTPS GETs to a fixed list of 25 paths that, when present, indicate a known misconfiguration (e.g. /.git/HEAD, /.env, /backup.sql). The path list is the same one used by every defensive scanner. Each response is validated against a body-shape check; a 200 with a generic SPA shell isn’t flagged. No credentials, no payload, no file is downloaded beyond the leading bytes needed to validate type. This is the only check that requests paths the operator hasn’t pre-confirmed the target intends to expose; if you don’t own the domain or have written authorisation from the owner, don’t run beacon against it. See Authorisation.
Third-party tracking: Parses the HTML returned by the root-path GET. Looks for hostnames belonging to a fixed list of 20 known trackers (analytics, session-recording, ad networks). No script is executed; only static HTML.
Forms: Parses the HTML for <form> elements. Reports the action target and method. Doesn’t submit anything.
Cookies: Reads Set-Cookie headers from the same root-path GET. Reports flags (HttpOnly, Secure, SameSite). Doesn’t store, replay, or use cookies.

beacon is also available as an open-source CLI at github.com/Giuseppe552/beacon. The CLI sends the same requests as the hosted version. If you run the CLI, you’re the one making the network requests, and the authorisation rule applies to you.

What “passive” means here

The word is overloaded across the security industry. Here, passive means all of the following at once.

No authentication is attempted, even with empty or default credentials.
No payload that could change behaviour is submitted: no SQL, no JavaScript, no shell metacharacters, no oversized inputs, no malformed framing.
No attempt to bypass an authorisation control, including by enumerating identifiers or guessing tokens.
No request is built to test rate limits, exhaust resources, or fingerprint a CVE.
Each scanner makes, at most, a single request per check per host. The exposed-paths scanner is the only one that issues more than one HTTP request, and the total stays well below any reasonable rate-limit threshold.

Out of scope, always

None of the tools on this site, in any version, do any of the following.

Exploitation of any vulnerability, known or otherwise.
Authentication bypass, credential testing, brute force, or session fixation.
SQL injection, command injection, XSS, SSRF, deserialisation attacks, or template injection.
Probing of authenticated endpoints, admin paths, internal IPs, or RFC 1918 ranges.
Denial of service, resource exhaustion, or rate-limit testing.
Lateral movement, persistence, or exfiltration of any kind.

Authorisation

Run beacon (hosted or CLI) against domains you own, or domains for which you have written authorisation from the owner. The same applies to any other tool on this site that issues network requests to a third party.

The Computer Misuse Act 1990 takes unauthorised access seriously. The methodology above is set up so that the normal operation of each scanner sits firmly inside reasonable use. If you point a scanner at someone else’s domain without authorisation, that’s a choice you made, not a feature of the tool.

Found a security issue

If you think a tool, page, or piece of writing on this site has a security issue, a privacy issue, or makes a factual claim that’s wrong:

Email [email protected].
I respond within one calendar month, usually faster. Where the report is correct, a fix or correction ships.
I won’t pursue legal action against anyone who reports a genuine issue in good faith and doesn’t access data they don’t have permission to access.

A machine-readable contact lives at /.well-known/security.txt (RFC 9116).

If a post mentions you

Some posts here discuss real organisations, named or anonymised, in the context of public-interest reporting on information-security practices. If you represent an organisation referenced in a post and you think a finding is wrong, email [email protected] with the URL, the specific claim you dispute, and the evidence you’d like considered.

I respond within one calendar month, usually faster. Where a claim is wrong on the facts, the post is corrected with a dated note at the top. Where the disagreement is about interpretation, your wording can be added inline. Your statutory rights are unaffected. The fuller editorial standards live at /research-ethics.