Technology Fingerprinting and Privacy: Detection Without Personal Data
"Fingerprinting" means two different things on the web. One identifies a website's software; the other identifies a person's browser. This guide explains the difference, how technology detection works, and the questions to ask before installing any detector.
Two kinds of fingerprinting
The word is overloaded, and the confusion makes people nervous about tools that are harmless in design.
- Technology fingerprinting identifies the software behind a website: which CMS, framework, CDN or analytics library it uses. The subject is the site. The input is what the site's server sends to every visitor.
- Browser or device fingerprinting identifies a visitor by combining attributes of their browser and device, such as fonts, screen size, canvas rendering and installed plugins, to recognise them across sites without cookies. The subject is the person. Browser vendors and regulators treat this as a privacy problem.
A technology detector does not need any attribute of the visitor. It does not need the page's text, the user's identity or their history. The question it answers is "what is this page built with?", and the answer is a list of software names. That is the basis of the design described below.
What a detector reads
Detection works by matching patterns against signals the page already exposes:
| Signal | Example | Personal data risk |
|---|---|---|
| Response headers | Server, X-Powered-By, cf-ray | Low: set by the server, same for all visitors |
| Meta tags | generator, og:type | Low: public markup |
| Script and stylesheet URLs | cdn.shopify.com, /_next/static/ | Low, but URLs can contain tokens, so only host and path patterns should be used |
| HTML sample | Class names, data attributes | Higher: the page may contain personal content, so it must be processed locally and discarded |
| Cookie names | _ga, __cf_bm | Names are low risk, values are identifiers and must not be read or sent |
| JavaScript globals | jQuery.fn.jquery, Shopify | Low if limited to version strings and presence |
| DOM selectors | div#__next | Low: only yes or no is needed |
The riskiest input is the page HTML, and the safe design is the standard one: match locally, keep only the matches. The patterns run inside the browser; the page is never uploaded. That decision determines almost everything else about the privacy of a detector, and is the first thing to verify.
The design behind Lens
The TLDlive Lens extension separates three stages and treats them differently:
- Detection, local. Patterns from a bundled catalogue are matched against the signals above, in your browser. The popup works with no account and no network call for the detection itself. The HTML sample is capped in size, is used only for matching, and is not stored or sent.
- Purpose classification, local. A guessed category for the site, such as ecommerce or blog, comes from schema.org types, generator meta, detected technologies and keyword heuristics on the title and meta description. Those two strings are read locally and never sent.
- Optional sharing, opt-in. If you turn sharing on, the extension sends a small domain-level record, not a page. Only technology names from the catalogue, the purpose label, language, schema.org type names, four yes/no signals, the registrable domain and host, and some technical metadata are included. The full list and the exclusions are in the privacy policy.
The structure achieves data minimisation: collect only what the stated purpose needs. The purpose is statistics about technology adoption; for that, a page title, a URL path or the visitor's identity is useless, so they are excluded by design and not just by policy.
What must never be collected
When assessing any detection tool, these are the lines to look for:
- Full URLs, paths and query strings. They routinely contain account identifiers, search terms, document names and reset tokens.
- Page content, form values and cookie values.
- Browsing history in the sense of a sequence of pages linked to one person. Domain-level observation, once per day, is far less revealing than a stream of URLs.
- Activity in private or incognito windows.
- Sensitive categories. A well-designed tool excludes banking, health and webmail sites, and local or private-network addresses, from any upload.
Anonymous is not the same as unlinkable
"Anonymous" claims deserve scrutiny. A random install identifier lets a server group observations from one installation, which is useful for deduplication and abuse limits but could, in theory, become a profile of the installation's browsing. Mitigations: generate the identifier randomly and never derive it from the user; store only a keyed hash on the server; deduplicate per domain and day so that the stream is sparse; drop raw events after a retention period; publish aggregates only. Country should be coarse and derived on the server from the connection, not collected from the user. TLDlive Lens follows these practices, and the retention periods are stated in the policy.
Domain-level data about browsing is still sensitive in some contexts. Someone's visits to a particular clinic's website say something even without a path. That is the reason for opt-in consent, a user-controlled denylist and the exclusion of sensitive categories, rather than treating the domain as harmless.
Regulatory frame, in brief
Several rules apply to browser extensions that send data. The Chrome Web Store User Data Policy requires disclosure of what is collected and limits its use to the extension's single purpose; its Limited Use requirements forbid selling the data or using it for advertising. In the European Union, the GDPR applies where data relates to an identifiable person, and pseudonymous identifiers such as an install ID count as personal data in many readings. This is general information and not legal advice; a data-processing review is advisable for any product that operates at scale.
Questions to ask any detector
Examples of what such tools find are in detecting Next.js and React and analytics and tag managers.
- Does detection run locally, or does the tool send the page or its URL to a server?
- Which fields are transmitted, and is the list published?
- Is sharing opt-in or opt-out, and is there a visible toggle?
- Can I exclude sites, and does it ignore private windows and sensitive categories?
- How long are raw events kept, and what is published or sold?
- Is the permission set proportionate? Reading response headers needs a specific permission; broad host access should have a stated reason.
If the answers are vague, treat the tool as an advertising product wearing a developer-tool label.
How the statistics stay non-personal
The numbers shown on /technologies are aggregates over distinct domains: how many observed domains run a technology, per extension and per day. They are derived from the domain-level events and published without any installation identifiers. Methodology and sampling limits are explained in what newly registered domains run. The domain data these statistics are joined to comes from public sources, namely zone files, described in zone files and CZDS.
Sources
- Chrome Web Store, User Data Policy and Limited Use requirements: developer.chrome.com
- Chrome for Developers, Manifest V3 permissions and the webRequest API: developer.chrome.com
- W3C, Mitigating Browser Fingerprinting in Web Specifications: w3.org
- Regulation (EU) 2016/679 (GDPR), Article 5 on data minimisation: eur-lex.europa.eu
Frequently asked questions
Is technology fingerprinting the same as browser fingerprinting?
No. Technology fingerprinting identifies the software a website uses, from signals every visitor receives. Browser fingerprinting identifies a person's browser or device. A technology detector does not need any visitor attribute.
Can a technology detector see my passwords or form data?
A well-designed one does not read form values at all. TLDlive Lens only checks whether a login form or shop cart exists, as a yes or no, and never collects field contents, cookie values or page text.
Is it safe to use a detector on internal or private sites?
Local detection does not upload anything. For sharing, a good tool excludes private network addresses, local hosts and incognito windows, and lets you add your own denylist.
What is a random install ID used for?
To deduplicate observations and apply rate limits without accounts. It should be random, not derived from you, and stored hashed on the server.