Skip to content

Suppress self-analysis tracker false positives (fixes #3)#6

Open
adamXbot wants to merge 1 commit into
mainfrom
fix/3-self-analysis-tracker-fp
Open

Suppress self-analysis tracker false positives (fixes #3)#6
adamXbot wants to merge 1 commit into
mainfrom
fix/3-self-analysis-tracker-fp

Conversation

@adamXbot

Copy link
Copy Markdown
Collaborator

Problem (fixes #3)

SDKFingerprintDatabase — the tracker SDK signatures privacycommand ships (URLs like app-measurement.com, symbols like FIRApp, domains like firebaseio.com) — is compiled into privacycommand's own binary. So when privacycommand statically analyzes itself, the binary string scanner matches those signatures and falsely reports trackers/analytics in our own app.

Root cause

The detector treats four signal sources as evidence of an SDK: linked frameworks, framework/helper bundle IDs, hard-coded URLs/domains, and binary symbols. The last two are string-table signals. For our own bundle, those strings are present only because they're the detection data we ship — not trackers we embed.

Fix

In SDKFingerprintDetector.detect(in:extraSymbols:), compute isSelfAnalysis = report.bundle.bundleID == analyzerBundleID (where analyzerBundleID = "org.privacykey.privacycommand", privacycommand's own CFBundleIdentifier). When analyzing ourselves, skip the string-derived evidence loops (urlPatterns / domains / symbolPatterns).

Framework- and bundle-ID evidence are left intact: those require a real linked dependency, so a genuine third-party tracker ever added to privacycommand would still be reported. The change is deliberately scoped to privacycommand's own bundle ID by design — every other app is analyzed exactly as before.

Tests

New SDKFingerprintDetectorTests:

  • testSelfAnalysisSuppressesStringOnlyTrackerHits — self-scan with Firebase URL/domain/symbol artefacts yields no hits.
  • testOtherAppStillFlaggedFromSameArtefacts — the same artefacts in a third-party app still flag firebase-analytics and a tracker-like hit.
  • testSelfAnalysisStillCatchesLinkedFramework — a genuinely linked FirebaseAnalytics.framework still surfaces under self-analysis, with no suppressed .url(...) evidence.

TestFixtures.swift is extended with bundle(bundleID:) and report(bundle:frameworks:hardcodedURLs:hardcodedDomains:) parameters (existing call sites preserved via defaults).

Verification

swift build + DEVELOPER_DIR=/Applications/Xcode.app/Contents/Developer swift test — full suite green (12 tests, 0 failures).

🤖 Generated with Claude Code

The SDK fingerprint database (tracker URLs like "app-measurement.com",
symbols like "FIRApp") is compiled into privacycommand's own binary. When
privacycommand statically analyzes itself, the binary string scanner matches
those signatures and falsely reports trackers/analytics in our own app.

Fix: in SDKFingerprintDetector.detect(in:extraSymbols:), when the bundle
under inspection is privacycommand itself (bundle ID
org.privacykey.privacycommand), suppress the string-derived signals
(urlPatterns / domains / symbolPatterns). Those strings are detection DATA we
ship, not trackers we use. Framework- and bundle-ID evidence is still honored
because it requires a real linked dependency, so a genuine future tracker
added to privacycommand would still surface.

The fix is deliberately scoped to privacycommand's own CFBundleIdentifier;
every other app is analyzed exactly as before.

Tests (privacycommandCoreTests/SDKFingerprintDetectorTests):
- self-analysis suppresses string-only tracker hits
- the same artefacts in another app are still flagged
- a genuinely linked tracker framework still surfaces under self-analysis,
  with no URL/string evidence

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[FP]: privacycommand on itself reports trackers

1 participant