Scheduled CT-log queries to crt.sh and Certspotter are undisclosed and cannot be turned off — the same listing claims #546 fixed are still false

[monkopedia-coder]

Raised by a second F-Droid reviewer (@munzzyy) on fdroiddata!42096, note 3805230215, from source
and binary only. Verified against v1.0.9 before filing.

The finding

The security self-check queries public Certificate Transparency logs on a schedule, and nothing in
the app or the listing says so.

• HttpCtLogFetcher.kt — DEFAULT_CRT_SH_URL = "https://crt.sh/"
• CertspotterCtLogFetcher.kt — the Certspotter endpoint, used as fallback when crt.sh flaps
  (AppModule.kt:436 records why)
• Both strings are in the shipped classes.dex, not only in source — the reviewer confirmed with
  strings -a on the release asset the Binaries: line points at.
• The query value is this device's own subdomain. CtLogMonitor's KDoc states it: "Monitors
  Certificate Transparency logs via crt.sh to detect unauthorized certificate issuance for this
  device's subdomain."
• There is no off switch. SecurityCheckIntervalOption offers HOURS_6, HOURS_12,
  HOURS_24 — cadence only, no "never".

Why this is the same class as #546, and in one way larger

#546 was about outbound network traffic the listing denied. Two shipped surfaces say:

surface	wording
full_description.txt	"data never leaves the device except through a live, user-approved session"
rousecontext.com/privacy	"There is no background upload, no analytics, no telemetry"

A scheduled CT query is a background upload, and no live session is involved. It also fires far
more often than crash reporting did — every 6 to 24 hours, forever, on every install, where ACRA
only fired on a crash. #546 is fixed; this one is not, and the same two sentences are still not
true because of it.

The honest mitigations, which are real

• It is a security feature, not a data grab. It exists to detect mis-issued certificates for
  your device — protective, and the opposite of extractive.
• The hostname is not secret. Your device's certificate is already in public CT logs; that is
  what CT is. The query does not disclose a name the logs do not already carry.
• What the query adds is liveness: crt.sh and Certspotter learn that someone is checking this
  subdomain, and roughly how often. That is a weaker disclosure than the payload sounds, and it is
  still a third party learning something about a device on a schedule.

The decision

Not "is this bad" — it is a good feature. The question is what the listing should say and what the
user should control:

1. Disclose it and leave it always-on. Cheapest. Fix full_description.txt and the privacy
   page, and add a line to the Trust Status section naming crt.sh and Certspotter. Argues that a
   security check is part of the product, not an optional extra.
2. Disclose it and add an "Off" to SecurityCheckIntervalOption. Consistent with the FOSS build sends crash reports by default, contradicting the F-Droid listing's privacy claims #546
   posture, but it lets a user silently disable a protection — worth deciding deliberately rather
   than by symmetry with crash reporting.
3. Disclose it and make the endpoints configurable, so a self-hoster can point at their own CT
   monitor. Interacts with the relay-pinning question filed alongside this.

The reviewer's own read: "This reads like the same disclosure question already open for ACRA rather
than a new one, so it probably belongs in that decision instead of a separate label." #546 is now
closed, so it needs its own home — this issue.

Whatever is chosen, the two listing sentences above need to become true, exactly as they did for
#546. That part is not a judgement call.