Not a vulnerabilityA fault in a measurement. Nothing is exploited and the package may be entirely innocent of what the finding says; the evidence simply does not reach as far as the conclusion.
What it is
Analysis of a package finds the strings, classes or endpoints of a collecting component and the finding reports that the product sends data to that party. Packages routinely carry code that is never reached: pulled in through a dependency, kept for a build variant for another market, or left behind after a feature was removed. Presence establishes what could run, not what did.
Why it is a separate entry
Naming a recipient that never received anything is the mistake that ends an investigation. It is also the mistake that makes the genuine findings in the same report unusable, because a single overreach lets everything else be dismissed as the same kind of claim.
How it arises
a string or class match reported as a data flow
a component present for a build variant distributed in another region
an endpoint constant compiled in with no code path that reaches it
a dependency that arrived through another dependency and is never initialised
Not to be confused with
A component that does transmit on its own account is Bundled component collection, a fault of the system. This entry is the step before it: the evidence shows presence and the claim asserts sending.
How to establish it
The finding rests on static analysis alone, and a dynamic capture of the running product shows no request to the component's endpoints during a run that exercises the relevant functionality. Presence in the package with no observed traffic is the fault in the claim.
method static-sourceQoD 85
Requirements on the measurement
label every finding by evidence level, keeping present-in-package strictly apart from observed-sending
record the package version and its source, since components differ per build variant and per market
run the dynamic check from a cold start on a clean device, since much of it fires only at first launch
state what the dynamic check could not see, including traffic that pinning or a protected channel kept out of view
What would refute it
by handA dynamic capture shows requests to the component's endpoints.The finding then stands as an observed transmission and should be reported as one.finding falls
by handThe finding already states that it establishes presence only.Presence is a legitimate finding when labelled as such. This entry is about the leap, not about static analysis.finding falls
by handA code path is shown to reach the component under conditions the capture did not cover, such as a login or a region.weakens
not from the captureThe component transmits over a channel the capture could not observe.Absence of observed traffic is then not evidence of absence, and the finding has to say so.weakens
Where this plugs into existing processes
The one question that surfaces itDid you see this component send anything, or did you see that it is in the package?
In a DPIA, verify this
Verify whether a supporting analysis established transmission or only presence, and treat the two as different statements.
As a procurement clause
Findings delivered by a supplier label each one as observed transmission or as presence in the package, with the method that established it.
With a complaint, hand over
The package version, the static evidence, and a dynamic capture of a cold start with a statement of what it could not observe.
Reproduction
METHOD.md · by hand · no dedicated reproduction exists yet; follow the general method and the indicator above
Legal framing
eu-gdpr-5-2
Objections, and the answer
“The library is in there, so it does something.”
Packages carry code that is never reached. What it does is a question for a capture, and until then the finding is about the package rather than about a transmission.
“Dynamic measurement is too hard for this product.”
Then report presence as presence. A weaker finding that holds is worth more than a strong one that is withdrawn.
“Other researchers report it the same way.”
The party you name will not accept that, and neither will a supervisory authority reading a report where one claim is over-reached.
What this does not establish
harm; the catalogue standardises a finding so it can be referred to, it does not weigh it
severity; there is no score here, by design. Weighing belongs to whoever applies the entry to a concrete case
unlawfulness; that is for a supervisory authority or a court
intent; a fault is usually a build decision, not a plan
absence: not finding it in one capture is not evidence that it is not there
DPE Catalogue. DPE-2026-0028: Presence in a binary taken for sending. Schema 2.0, entry status active. Retrieved from https://totaledigitalewaarborging.nl/register/DPE-2026-0028
Measurement
When you publish a finding, cite the method version alongside the entry: “DPE-2026-0028, established under DPE Measurement Method 1.0”
Identifiers are permanent and are never
reused. An entry that is deprecated keeps its number and its address, with the reason attached, because
references to it exist elsewhere.