Selected finding
Probable browser/device fingerprinting review signal
This is rare in the calibration set and uses a higher evidence bar than a single device-signal observation. When present, it indicates a stronger multi-signal cluster that may warrant focused fingerprinting review.
Benchmark frequency is directional market context only. It is not a compliance benchmark, legal conclusion, or severity score. Rare findings may be top-ranked only when retained evidence is strong; common findings may remain medium when evidence is automated or context-dependent. Rarity is not severity, and prevalence is not compliance risk.
Observed
Retained runtime evidence showed a clustered high-entropy browser/device signal pattern that may warrant probable fingerprinting review.
Why this matters
Clusters of high-entropy browser or device signals can support fingerprinting review because they may help distinguish browsers or devices without relying only on cookies. For review teams, this signal can help prioritize purpose, necessity, consent state, security or fraud-prevention context, and minimization review.
Detection methodology
CertScore clusters retained runtime evidence for high-entropy browser and device signals, including canvas or WebGL behavior, audio or media characteristics, storage probes, font or plugin signals, screen or locale attributes, script/request context, identifier-like context, and coverage signals where available. The finding is surfaced when retained evidence includes a stronger multi-signal cluster than a single generic device observation. CertScore treats probable fingerprinting as a review signal, not proof of identity, identity resolution, persistent fingerprint creation, user singling-out, legal status, consent validity, or compliance status. A security, fraud-prevention, bot-detection, or abuse-prevention purpose may explain collection, but does not automatically exempt terminal-equipment access or personal-data processing from applicable review. Reviewers should consider purpose, necessity, security or fraud-prevention use, consent state, vendor role, whether identifiers are linked, and whether retained evidence is sufficient for the intended review.
Confidence semantics: Good when retained runtime evidence includes a multi-signal high-entropy browser/device cluster, signal categories, script or request context, and enough detail for reviewer inspection; stronger when retained evidence also includes fingerprint tier context, artifact references, identity-like or cross-domain context, consent timing, repeated examples, and usable coverage. A security or fraud-prevention purpose may explain collection but does not automatically exempt terminal-equipment access or personal-data processing. Manual review is still needed for purpose, necessity, identity linkage, consent state, downstream use, and remediation quality.
Top-finding calibrationWhat must be retained to surface, top-rank, demote, or suppress this finding.
Minimum to surface
- Multi-signal high-entropy cluster.
High confidence requires
- Cluster plus script/request and tier/context.
Top ranking requires
- Cluster plus identifier, cross-domain, pre-consent, or adtech context.
Demote or suppress when
- Single common attribute.
- Vendor name only.
- Security script without retained cluster.
These rules describe ranking calibration for already-projected findings. They do not create findings from raw signals.
Finding relationship
This finding is the higher-tier fingerprinting/device-signal review signal. It is used when retained evidence shows a stronger clustered set of high-entropy browser or device signals, such as multiple signal categories or stronger corroboration, that may warrant probable fingerprinting review. A site may also show the related lower-tier fingerprinting signal when additional device-signal context is retained.
Example evidence
Probable fingerprinting cluster example
artifact=fingerprint_cluster_001role=finding_supporting_artifacturl=https://example.com/script_origin=https://signals.examplesignal_categories=canvas_or_webgl, audio, storage, screen_locale [raw_values_not_retained]fingerprint_tier=probable_review_signalrequest_path=/collect [query_redacted=true]identifier_linkage_context=manual_review_recommendedreview_caveat=manual review should confirm purpose, necessity, consent state, identity linkage, endpoint role, and security or fraud-prevention context
Review context
possible_source=security_fraud_or_identity_scriptcontexts_to_review=fraud_prevention, bot_detection, analytics, advertising, identity, compatibilitycross_domain_context=manual_review_recommendedraw_attribute_values_retained=falsemanual_review_needed=true
What should not count by itself
single_signal=timezone [insufficient_without_cluster]vendor_name=Example Fingerprint [insufficient_without_runtime_cluster]tag_manager_present=true [audit_only_without_signal_categories]raw_device_attributes [must_not_be_public_sample_evidence]
View redacted sample JSONHide redacted sample JSON
{
"findingId": "probable_fingerprinting",
"label": "Probable browser/device fingerprinting review signal",
"category": "Fingerprinting",
"criticality": "critical",
"evidenceConfidence": "review_signal",
"directVsInferred": "clustered_inference",
"evidence": {
"summary": "Retained runtime evidence showed a clustered high-entropy browser/device signal pattern that may warrant probable fingerprinting review.",
"examples": [
{
"title": "Probable fingerprinting cluster example",
"lines": [
"artifact=fingerprint_cluster_001",
"role=finding_supporting_artifact",
"url=https://example.com/",
"script_origin=https://signals.example",
"signal_categories=canvas_or_webgl, audio, storage, screen_locale [raw_values_not_retained]",
"fingerprint_tier=probable_review_signal",
"request_path=/collect [query_redacted=true]",
"identifier_linkage_context=manual_review_recommended",
"review_caveat=manual review should confirm purpose, necessity, consent state, identity linkage, endpoint role, and security or fraud-prevention context"
]
},
{
"title": "Review context",
"lines": [
"possible_source=security_fraud_or_identity_script",
"contexts_to_review=fraud_prevention, bot_detection, analytics, advertising, identity, compatibility",
"cross_domain_context=manual_review_recommended",
"raw_attribute_values_retained=false",
"manual_review_needed=true"
]
},
{
"title": "What should not count by itself",
"lines": [
"single_signal=timezone [insufficient_without_cluster]",
"vendor_name=Example Fingerprint [insufficient_without_runtime_cluster]",
"tag_manager_present=true [audit_only_without_signal_categories]",
"raw_device_attributes [must_not_be_public_sample_evidence]"
]
}
]
}
}Regulatory review context
Probable browser/device fingerprinting review
Retained runtime evidence showed a clustered high-entropy browser/device signal pattern that may warrant probable fingerprinting review. Purpose, disclosure, consent state, minimization, security or fraud-prevention context, and downstream use should be reviewed.
View applicability notes
Legal and regulatory frameworks
- ePrivacy Article 5(3) fingerprinting/device-access reviewRetained clustered browser/device signals may involve storing information on, or gaining access to information from, terminal equipment.
- GDPR online identifier and profiling reviewHigh-entropy browser/device signals may be relevant to online identifier, profiling, or identifiability review depending on linkage, purpose, and manual review.
- GDPR minimization and purpose reviewCollection may include high-entropy attributes that may warrant purpose, necessity, minimization, and default-setting review.
Jurisdictional contexts
- EU ePrivacy/GDPR fingerprinting reviewEU/EEA users and high-entropy device/browser signals may be in scope depending on terminal-equipment access, purpose, consent state, and manual review.
- UK PECR fingerprinting/similar-technology reviewUK users and non-cookie tracking, device access, or similar technology may be in scope depending on purpose, consent state, and manual review.
- CCPA/CPRA profiling, advertising, or sensitive-data reviewCalifornia users, cross-context advertising, sale/share, sensitive data, or profiling-related use context may be relevant depending on purpose, user region, and manual review.
- Security/fraud-prevention purpose reviewA security, fraud-prevention, bot-detection, or abuse-prevention purpose may explain collection, but does not automatically exempt terminal-equipment access or personal-data processing from applicable review.
This finding does not determine legal status, consent validity, persistent fingerprint creation, personal identity, identity resolution, user singling-out, complete identity graph, or compliance status. Probable fingerprinting review is inferred from clustered retained signals, and fraud-prevention or abuse-prevention use cases may explain some high-entropy collection without automatically exempting terminal-equipment access or personal-data processing from applicable review.
Evidence standard
Strong
- Retained runtime evidence includes a multi-signal browser/device cluster with high-entropy signal categories such as canvas, WebGL, audio, storage, font or plugin, screen, locale, timing, or similar environment attributes.
- Evidence includes page URL, script or request context, signal categories, timing or scan-state context where available, and redaction of raw values, identifiers, query strings, and payloads.
- Evidence includes stronger corroboration than a single generic device signal, such as repeated categories, retained fingerprint tier context, artifact references, identity-like context, or cross-domain request context where retained.
- Evidence distinguishes probable fingerprinting review from proof of personal identity, identity resolution, or a complete identity graph.
- Coverage context indicates the retained runtime observations were not materially blocked or unreliable.
Good
- Retained evidence shows a clustered high-entropy browser/device signal pattern, but purpose, identity linkage, downstream use, or endpoint role requires manual review.
- The retained example is enough for a reviewer to inspect signal categories, script or request context, vendor role, consent timing, and likely owner manually.
- The evidence is likely a probable fingerprinting review signal, but personal identity, persistent fingerprint creation, user singling-out, legal significance, and remediation quality require manual review.
Audit-only
- Multiple browser/device signals are suggested, but retained evidence lacks enough detail to confirm category count, runtime context, or corroboration.
- Known fingerprinting-capable vendor or script is present, but retained evidence does not show a multi-signal cluster.
- Policy text, vendor documentation, or static source reference suggests fingerprinting capability, but no retained runtime cluster supports the observed state.
Insufficient
- Single generic browser or device attribute without corroborating high-entropy context.
- Vendor name alone.
- Cookie, request, or tag-manager presence alone without retained browser/device signal evidence.
- Raw device attributes, raw identifiers, screenshots, or payload dumps as public evidence.
- Claims about personal identity, identity resolution, complete identity graph, legal status, consent validity, or compliance status based only on automated evidence.
Evidence levels explain how CertScore treats retained runtime artifacts. They are not legal conclusions.
Common causes
- Security or fraud SDKs collect multiple high-entropy attributes in the same page-load context.
- Adtech, identity, analytics, or measurement scripts combine device signals with identifiers or cross-domain request context.
- Canvas, WebGL, audio, storage, screen, locale, font, or plugin APIs are used together.
- Tag-manager sequencing loads fingerprinting-capable scripts before purpose, consent, or suppression rules are applied.
- Legacy vendor tags retain fingerprinting-style behavior after product or privacy requirements changed.
Common remediation approaches
- Teams commonly identify which script, SDK, or vendor owns the high-entropy signal cluster by reviewing initiator chains and retained request anchors.
- Fraud-prevention, bot-detection, security, analytics, and identity SDKs should be reviewed for purpose, necessity, and configuration options.
- Vendors may need to explain whether high-entropy browser or device attributes are necessary for the stated purpose and whether collection can be minimized.
- Teams should review whether consent gating or purpose-based suppression applies to the identified script or endpoint.
- Raw device attribute values, identifiers, and payloads should remain out of public evidence while preserving stable anchors for review.
Recommended review questions
- Which high-entropy browser or device signal categories co-occurred?
- Which retained runtime artifacts, request anchors, script contexts, or artifact references support the probable cluster?
- Was the cluster supported by canvas, WebGL, audio, storage, font, plugin, screen, locale, timing, or other environment signals?
- Was identifier-like, cross-domain, cookie-sync, adtech, analytics, or identity context also retained?
- Was the cluster observed before consent, after consent, after reject, or outside known consent context?
- Could the collection support security, fraud prevention, bot detection, compatibility, analytics, advertising, or another context-dependent purpose?
- Does retained evidence show enough detail to distinguish probable fingerprinting review from generic telemetry?
- Are query strings, identifiers, payloads, raw attribute values, and sensitive values redacted or avoided in public evidence?
- Should privacy, security, legal, and engineering teams manually confirm purpose, necessity, consent state, disclosure, minimization, and remediation quality?
Limitations and cautions
- This finding is an automated probable fingerprinting review signal, not a legal conclusion, certification, compliance determination, or determination of consent validity.
- Probable fingerprinting is inferred from clustered retained signals; it does not determine persistent fingerprint creation, personal identity, identity resolution, user singling-out, or a complete identity graph.
- Fraud-prevention, security, bot-detection, abuse-prevention, compatibility, or service-protection use cases may explain some high-entropy collection.
- Automated evidence may not fully determine purpose, necessity, downstream use, legal basis, consent state, vendor role, or whether signals are linked to identifiers.
- Manual review is needed to confirm purpose, necessity, consent state, disclosure, minimization, security context, data sharing, and remediation quality.
- CertScore redacts or avoids retaining raw device attributes, full query strings, identifiers, payloads, screenshots, and sensitive values while preserving stable anchors needed for review.
- Automated findings may contain errors and should be reviewed with the retained evidence.
- Not detected means not observed in the scan scope; it is not proof of absence.
- Findings are runtime evidence and public-surface observations for review, not legal conclusions.