Research third-party products by observation
State: open/active
Summary
Section titled “Summary”- Research a third-party product by running it and recording what it does. Never unpack, decompile or read its shipped source, and never commit reproduced source into this repo.
Findings about a third-party product are established by observing the running product. Drive the application against a known input, record what comes out, and cite that observation as the evidence. Do not unpack an application bundle, disassemble a binary, or read minified or generated source to establish a finding. Source obtained that way is never committed to this repo, in any form — not as a quotation, not as a paraphrase presented as a quotation, and not in a fixture.
Published documentation and public APIs are fair to cite directly, and a type declaration the vendor ships for third-party use is documentation, not internals.
Two independent reasons, either sufficient on its own.
Observation is the stronger evidence. A behaviour table built from running the product describes what the product actually does. A claim read out of its source describes what one build appears to intend, which is a weaker claim about a narrower thing, and it goes stale on the next release.
Reverse engineering is commonly a licence violation, and the ban reaches further than copyright does. A typical end-user agreement forbids deriving “the underlying structure, ideas or algorithms” of the software. Copyright does not protect an idea or an algorithm, so the interoperability precedent that permits intermediate copying does not answer the contract term. That obligation is accepted by using the product, so it binds anyone who installed it — no separate agreement is needed. Carve-outs for plugin development are often conditioned on non-commercial use, so they stop sheltering the work the moment a commercial product is in view.
How to apply
Section titled “How to apply”Keep a fixture the finding can be reproduced against, so a reader with a copy of the product can
check it. packages/rust/wikilink/tests/fixtures/vault/ is the worked example for vault
behaviour.
Write findings as input to output. State what was fed in, what came back, and which version of the product produced it. Where the product’s behaviour is ambiguous or undocumented, say so and record the observation that settles it rather than reasoning from internals.
If a claim can only be made by reading the product’s source, drop the claim. A finding that cannot be observed is not one this repo can carry.
Anti-examples
Section titled “Anti-examples”Asserting a fact from a source literal when the running process already proves it. An earlier
research note claimed Node integration in the renderer from a webPreferences literal read out of
the bundle, while the next sentence proved the same thing from the running process arguments. The
observation was always the stronger claim and the bundle added nothing but exposure.
Restating a decompiled implementation as prose. Removing the quotation marks does not change how the finding was learned; the provenance problem survives the paraphrase.
The standing rule here is settled. Two questions from
B-5ISD-obsidian-research-provenance-and-commercial-use are not, and this standard does not
decide them: whether a competing-product clause reaches a product built alongside such research,
and whether source already removed from HEAD should also be scrubbed from history.