Interpreting fingerprints
Read a fingerprint as a description of behavior with supporting context.
1. Identify the scheme
Check the scheme ID and revision before comparing values. Similar names do not guarantee the same normalization, input encoding, or hash. Read the current scheme notes.
2. Separate a value from a label
A fingerprint value describes selected protocol features. A software association is a separate claim. Useful supporting evidence includes a known application version, platform, repeatable capture procedure, and observation date.
3. Check where it was observed
A proxy, TLS terminator, or different capture layer can change which peer's behavior is visible. Record the collection setup and what it can actually observe. Missing evidence must remain unavailable rather than becoming an invented fingerprint.
4. Keep uncertainty visible
Two applications can share a value. One application can produce multiple values across versions or settings. A supplied user-agent label and a honeypot source are observations, not verified identity or maliciousness.
5. Compare reproducible records
Use the same scheme revision and compatible inputs, preserve collection context, and document conflicting results. Published databases will need their own limitations and counting rules.
6. Link related observations carefully
Combining TCP, TLS, and HTTP observations can add context when there is reliable evidence that they describe the same connection or client context. Record each scheme and revision, the capture point, and the evidence supporting that link. A shared IP address alone does not establish a shared client.
Proxies and TLS terminators can make observations at different layers describe different systems. Several hashes of one TLS handshake describe overlapping inputs rather than independent evidence. This project does not implement a combined fingerprint identifier; related observations still need their own provenance and uncertainty.