Boundaries, ethics & the participant disclosure
A site teaching people to record a web application's traffic in a live session needs to state its position rather than leave it implied. Anyone reading this site as a scraping guide has been given the wrong document — read this page before the code.
A narrow and defensible instrument
This is an instrument for observing your own session and your own data, on an account you hold, recording only what the service already sent to your browser. It originates no requests, transmits nothing, and captures no message content in any mode. That is a narrow and defensible thing, and stating the narrowness is what keeps it defensible. The four invariants in guide 02 §1 exist not just as ethics but as what makes the tool safe to run:
- Never originates a request.
- Never blocks, delays or alters a response.
- Never throws into the page.
- Never transmits.
See the read-content closure (U2) for why this narrowness matters: accepting that an extension can read page content quietly means it can act on your behalf on every site you are logged into, and connecting an agent turns prompt injection from that content into an actor taking attacker instructions. The invariants above are the mitigation for exactly that closure.
The target is never named
The guides are deliberately generic — the target appears as "the target" and "the API" throughout. This is kept without exception, and it is a legal and ethical position, not a stylistic one. The tool records a real logged-in session on a third-party service; naming it converts a methodology document into something that reads as a guide to extracting data from that specific company, which changes how the site is received by that company's legal team, by search engines, and by anyone deciding whether to trust this project.
This constrains editing: a well-meaning edit adding "(for example, on <the obvious candidate>)" to make a passage concrete would undo the decision in a single word. It is enforced in CI with a term blocklist over the whole tree (admin/build/validate.js) rather than by review — the failure mode is a well-meaning editor adding a helpful example, not a hostile one.
What may not be published, ever
| Category | Rule |
|---|---|
| Capture data — verbatim payloads, real names, identifiers | Never. It lives in the private data vault; guide 04's whole architecture exists to keep it there |
| Real captures as test fixtures | Never. Fixtures are hand-authored and synthetic with obviously fake identities |
| The target's name, domain, endpoint paths, query ids | Never |
| Vault keys, share tokens, access tokens | Never. CI greps for key-shaped strings as a build step |
| Parsers specific to the target's payloads | Publish the technique, not the pattern that only makes sense against one site |
The skeleton export format (guide 02 §10) is the model for what can be shared: structure preserved, values replaced, taxonomy kept — shipped with a redaction verifier that counts what it checked, so "0 leaks" means something.
What this site does not cover
The guides are written from one extension: a passive recorder that never originates a request. Nothing here covers extensions that modify pages, inject UI into a target, use declarativeNetRequest, ship to the Chrome Web Store, handle OAuth, or run content scripts across many origins. A guidance site implying broader coverage than its evidence supports fails its own rule.
Licensing
Site text, the rubric, the diagrams and the four guides: CC BY 4.0, attributed to Dinis Cruz with AI co-authorship. Code fragments published as examples carry an explicit permissive licence instead — CC0 or MIT — because CC BY is a poor fit for code people will paste. Third-party names (Chrome, Manifest V3, fake-indexeddb, node:assert) are referenced factually; Chrome's documentation is Google's — link and cite, never reproduce. Quoted platform constants are facts about an API, carrying their read-date per the claim-state discipline (see the ladder).
Who is writing this
This site is published by the sgit project, which also builds the vault platform that U6 proposes as an extension's storage layer. So this is a participant publishing guidance that recommends its own publisher's product as one candidate storage answer — stated here, upfront, not in a footer.
The treatment, visible rather than buried:
- State who is writing it. Done, on this page and in every footer.
- Date and state the evidence level of every claim. Recalled · read · measured, per the arc — including the fact that no extension in this corpus has yet fetched a vault (U6's own claim-state note).
- Publish where the recommendation is unproven. U6 is a design position, not a shipped integration. The open design details (cross-origin access, bundled crypto, offline/conflict behaviour) are listed on its own page rather than smoothed over.