Summary
Linthra is a local-first, privacy-focused music player. Our current privacy policy says that Linthra does not use third-party advertising trackers, does not operate a cloud account system, and does not send personal data to TheZupZup or to a Linthra-owned server.
A recent independent APK analysis from Apptizo found no known tracking SDKs and no permissions they classify as sensitive:
https://apptizo.com/app/linthra/
That is great to see, but their report correctly points out one limitation: not finding a known tracking SDK does not prove that an app could not perform custom tracking with its own network code.
I want us to take that seriously.
I don't want users to only trust what we say in PRIVACY.md. I want Linthra's repository, CI and release process to provide technical evidence that contributors and third parties can reproduce.
Linthra should not just say that it does not track users. We should make that claim auditable.
Why this matters
Linthra can access local music, self-hosted server addresses, authentication sessions, playback state and other personal library information. Unexpected telemetry would therefore be a serious privacy regression, even if it came from an accidental dependency update.
Open source lets anyone inspect the code, but users should not need to manually audit thousands of lines before installing Linthra.
The project should help do that automatically.
What we should add
1. Dependency / tracker check
Add a CI check for production dependencies and packaged libraries.
It should flag known analytics, advertising and telemetry systems such as Firebase Analytics, Crashlytics, Sentry, Mixpanel, Amplitude, Adjust, AppsFlyer, Meta/Facebook analytics, Google Analytics and similar services.
A new match should fail CI unless it is intentionally reviewed and documented.
2. Fixed network destination audit
Scan production code and relevant configuration for hard-coded domains, URLs and IP addresses.
Expected fixed destinations should be documented with a reason. User-configured Jellyfin, Plex or Navidrome/Subsonic addresses remain dynamic and do not need to be hard-coded in an allowlist.
The goal is not to block networking. The goal is to make any new fixed external destination obvious during review.
3. Android permission / manifest regression check
Audit the final merged Android manifest and detect newly introduced permissions, exported components, intent filters or security configuration changes.
Linthra already documents its Android permissions carefully. This would make that policy enforceable in CI.
4. Final APK privacy report
Audit the actual APK users install, not only the source tree.
The release report should include where practical:
- APK SHA-256
- version and package ID
- signing certificate fingerprint
- effective permissions
- packaged native libraries
- detected SDKs of interest
- suspicious fixed network strings/domains
This ties the privacy audit to one exact release binary.
5. Runtime network smoke test
This is the most important part for answering the limitation in the Apptizo report.
Run Linthra in a controlled environment and observe its outbound traffic.
Clean install, no server configured: Linthra should not contact analytics, telemetry or Linthra-operated endpoints.
Controlled Jellyfin/Navidrome server configured: Linthra should communicate with the server the user configured, without unrelated external telemetry traffic.
Legitimate features such as Chromecast discovery/session traffic should have explicit expectations so they are not confused with tracking.
The test can use an emulator, proxy, controlled DNS, packet capture or another repeatable method.
6. Public privacy audit document
Add something like PRIVACY_AUDIT.md with the current status and links to the checks.
For example:
Advertising SDKs: none
Analytics SDKs: none
Known tracking SDKs: none
Automatic third-party crash reporting: none
Linthra-operated telemetry endpoint: none
Runtime outbound-network smoke test: passing
The document should also explain the limits of the checks. We should never claim that automation can mathematically prove that software is harmless.
Optional later improvement
A future in-app privacy/network page could show the services Linthra currently knows about, for example:
192.168.1.50:8096
Jellyfin
Configured by you
This would not be a packet sniffer. It would simply make configured network access easier for users to understand.
Definition of done
Why I want this for Linthra
I want people to be able to trust Linthra without having to trust me personally.
If someone asks whether Linthra tracks them, the strongest answer should not be "the maintainer says no."
It should be: the source is public, the final binary is audited, the runtime network behaviour is tested, and you can reproduce the checks yourself.
Reference third-party analysis: https://apptizo.com/app/linthra/
Summary
Linthra is a local-first, privacy-focused music player. Our current privacy policy says that Linthra does not use third-party advertising trackers, does not operate a cloud account system, and does not send personal data to TheZupZup or to a Linthra-owned server.
A recent independent APK analysis from Apptizo found no known tracking SDKs and no permissions they classify as sensitive:
https://apptizo.com/app/linthra/
That is great to see, but their report correctly points out one limitation: not finding a known tracking SDK does not prove that an app could not perform custom tracking with its own network code.
I want us to take that seriously.
I don't want users to only trust what we say in
PRIVACY.md. I want Linthra's repository, CI and release process to provide technical evidence that contributors and third parties can reproduce.Why this matters
Linthra can access local music, self-hosted server addresses, authentication sessions, playback state and other personal library information. Unexpected telemetry would therefore be a serious privacy regression, even if it came from an accidental dependency update.
Open source lets anyone inspect the code, but users should not need to manually audit thousands of lines before installing Linthra.
The project should help do that automatically.
What we should add
1. Dependency / tracker check
Add a CI check for production dependencies and packaged libraries.
It should flag known analytics, advertising and telemetry systems such as Firebase Analytics, Crashlytics, Sentry, Mixpanel, Amplitude, Adjust, AppsFlyer, Meta/Facebook analytics, Google Analytics and similar services.
A new match should fail CI unless it is intentionally reviewed and documented.
2. Fixed network destination audit
Scan production code and relevant configuration for hard-coded domains, URLs and IP addresses.
Expected fixed destinations should be documented with a reason. User-configured Jellyfin, Plex or Navidrome/Subsonic addresses remain dynamic and do not need to be hard-coded in an allowlist.
The goal is not to block networking. The goal is to make any new fixed external destination obvious during review.
3. Android permission / manifest regression check
Audit the final merged Android manifest and detect newly introduced permissions, exported components, intent filters or security configuration changes.
Linthra already documents its Android permissions carefully. This would make that policy enforceable in CI.
4. Final APK privacy report
Audit the actual APK users install, not only the source tree.
The release report should include where practical:
This ties the privacy audit to one exact release binary.
5. Runtime network smoke test
This is the most important part for answering the limitation in the Apptizo report.
Run Linthra in a controlled environment and observe its outbound traffic.
Clean install, no server configured: Linthra should not contact analytics, telemetry or Linthra-operated endpoints.
Controlled Jellyfin/Navidrome server configured: Linthra should communicate with the server the user configured, without unrelated external telemetry traffic.
Legitimate features such as Chromecast discovery/session traffic should have explicit expectations so they are not confused with tracking.
The test can use an emulator, proxy, controlled DNS, packet capture or another repeatable method.
6. Public privacy audit document
Add something like
PRIVACY_AUDIT.mdwith the current status and links to the checks.For example:
The document should also explain the limits of the checks. We should never claim that automation can mathematically prove that software is harmless.
Optional later improvement
A future in-app privacy/network page could show the services Linthra currently knows about, for example:
This would not be a packet sniffer. It would simply make configured network access easier for users to understand.
Definition of done
Why I want this for Linthra
I want people to be able to trust Linthra without having to trust me personally.
If someone asks whether Linthra tracks them, the strongest answer should not be "the maintainer says no."
It should be: the source is public, the final binary is audited, the runtime network behaviour is tested, and you can reproduce the checks yourself.
Reference third-party analysis: https://apptizo.com/app/linthra/