Have any third‑party security firms (e.g., FossID or similar) publicly reported on telemetry or network audits for desktop/mobile input software?
Executive summary
Third‑party security firms routinely publish audits of mobile and desktop applications and of third‑party SDKs, and several vendors publicly disclose audit reports and summaries; examples include a public Mullvad app audit performed by X41 D‑Sec [1] and vendor statements that they commission annual external audits (Bitwarden) or offer continuous SDK monitoring (Privado) [1] [2] [3]. However, among the sources provided there is no clear, public third‑party report that specifically labels a “telemetry” or “network audit” for standalone desktop/mobile input software (for example, keyboard drivers or input‑method editors) — the available reporting focuses more broadly on app security, SDK data flows, and conventional penetration testing [1] [3] [2].
1. What the term likely means and why it matters
“Telemetry or network audits for desktop/mobile input software” would imply an independent review that inspects what keystroke data, usage telemetry, or network endpoints an input component sends off‑device, and tests whether those flows violate privacy or security expectations; third‑party audits are an established vehicle for that kind of assurance because external auditors can examine code, run dynamic tests, and review network traffic to find unexpected data exfiltration (industry guidance and how‑to pieces establish this practice) [4] [5] [6].
2. Public examples of third‑party audits of apps and SDKs
There are concrete, public examples where independent firms reviewed client software and published findings: Mullvad commissioned X41 D‑Sec to perform a source‑code audit and penetration test across desktop and Android clients and published a report describing technical findings and fixes [1]. Bitwarden publicly states it performs annual third‑party security audits that include penetration tests and post‑audit analyses [2]. These reports demonstrate the market practice of hiring external specialists and making results available to customers and the community [1] [2].
3. SDK governance and telemetry concerns are being discussed publicly
Security and privacy vendors are explicitly marketing continuous monitoring for SDKs and third‑party libraries because misplaced or misconfigured SDKs have led to enforcement actions: Privado promotes tools to continuously audit app SDKs and cites a California Attorney General settlement involving Tilting Point and misconfigured SDKs that caused unauthorized data sharing, illustrating why telemetry and data‑flow audits of SDKs are commercially tasked and publicly discussed [3]. That example ties audits directly to telemetry risk but is framed as SDK governance rather than as a dedicated “input‑software telemetry audit” [3].
4. Limits of the public record in the supplied reporting
The supplied sources broadly cover third‑party audits, best practices, and examples of vendors publishing audit results, but they do not provide a documented, named instance where a third‑party security firm publicly released a dedicated telemetry or network audit focused exclusively on desktop or mobile input software (such as keyboard apps, IMEs, or low‑level input drivers) [1] [3] [2] [7]. That absence in the available reporting does not prove such audits never exist; it only means the provided corpus lacks a direct example.
5. What can be inferred and what remains unanswered
It is well supported that third‑party auditors perform and publish app and SDK security audits, including source‑code reviews and penetration tests that can and do include network and telemetry analysis as part of their scope [1] [5] [4]. What cannot be confidently asserted from these sources is that a named security firm has publicly released a standalone telemetry/network audit specifically targeted at desktop/mobile input software — the provided materials show the capability and the incentives (regulatory enforcement, vendor reputational risk) but stop short of producing such a report [3] [1] [2].
6. Practical next steps for researchers seeking such audits
Researchers should search vendor pages and security‑firm publication feeds for keywords like “keyboard,” “input method,” “IME,” “telemetry,” and “network traffic analysis,” and examine audit repositories and Git logs where organizations like Mullvad publish detailed findings; industry writeups and academic surveys on third‑party vendor risk can guide scope and methodology for locating telemetry‑focused work [1] [8] [4]. The sources show a precedent for making audits public, so a targeted search beyond this corpus could reveal telemetry audits not captured here [1] [2].