Since this is very heated discussion and very right one, I asked for independent analysis… I will park it here and probably not continue in the discussion 
Reviewing the discussion from a GDPR and ePrivacy perspective, there are several important legal distinctions worth clarifying.
First, collecting telemetry is not inherently illegal under GDPR, and GDPR does not universally require opt-in consent for every form of diagnostic data collection. Under Article 6(1)(f), legitimate interests may provide a lawful basis for certain limited operational telemetry, provided the processing is necessary, proportionate, transparent, and supported by a proper balancing assessment.
However, GDPR is not the only legislation that matters here.
Article 5(3) of the ePrivacy Directive, as implemented in national law, also regulates storing information on or accessing information from users’ terminal equipment. This can apply even when the information itself is not personal data. For optional analytics or installation tracking, prior consent may therefore be required unless a specific exemption applies.
A few observations regarding the implementation described in this thread:
-
Random installation UUIDs are not automatically anonymous. A persistent identifier that allows one installation to be recognized and tracked over time may constitute personal data, particularly when combined with IP addresses, diagnostic information, or other reasonably available data. Random generation and the absence of a user’s name do not, by themselves, make such information anonymous. See GDPR Article 4(1), Article 4(5), and Recital 26.
-
IP address processing matters even if the IP is not permanently stored. Sending an IP address to an external GeoIP service involves processing and potentially disclosure to a third party. Retaining only the resulting country information does not eliminate the legal implications of the preceding processing.
-
Transparency is mandatory. Where personal data is collected directly from users, GDPR Articles 12–13 require appropriate information about the controller, purposes, lawful basis, recipients, retention, and data-subject rights. Publishing a privacy policy is an important step, but a privacy policy alone does not establish a lawful basis for processing.
-
Default-on telemetry is not automatically compliant simply because an opt-out exists. An opt-out may be compatible with certain processing based on legitimate interests under GDPR, but it does not replace prior consent where ePrivacy rules require it.
-
The distinction between necessary functionality and optional telemetry is particularly relevant. The developer has stated that the applications function without the telemetry service. This does not automatically make the telemetry unlawful, but it makes it more difficult to argue that all the described tracking is strictly necessary to provide the service requested by the user.
-
Responsibility cannot simply be transferred to Athom. An independent community developer deciding why and how telemetry is collected will generally be a data controller for that processing. Athom’s own privacy policy does not automatically cover independent telemetry infrastructure operated by third-party developers. Depending on their actual roles, external service providers may also have separate obligations under GDPR.
Regarding the proposed replacement using WebSocket connections and installation identifiers: removing GeoIP lookups is a positive data-minimization measure, but it does not automatically resolve the remaining legal questions. Persistent identifiers, connection metadata, targeted messaging, and error reporting still require appropriate assessment.
Both extreme positions are legally inaccurate: it is incorrect to claim that GDPR prohibits telemetry without explicit consent in every situation, but it is equally incorrect to assume that randomly generated UUIDs, a lack of directly identifying details, or the mere installation of an app automatically make telemetry lawful.
For optional community-app telemetry, the legally safer approach would be to:
-
Provide a clear and accessible privacy notice before personal data collection begins.
-
Collect only what is genuinely necessary for clearly defined purposes.
-
Avoid persistent identifiers where anonymous or aggregated statistics would be sufficient.
-
Document the applicable lawful basis and perform a legitimate interests assessment where relevant.
-
Assess whether ePrivacy rules require prior consent, rather than assuming that legitimate interests under GDPR are sufficient.
-
Provide genuine opt-in consent where legally required, together with an effective withdrawal mechanism.
-
Ensure that declining optional telemetry does not unnecessarily affect the application’s core functionality.
-
Define appropriate retention periods and clarify the responsibilities of any external service providers.
For reference:
Ultimately, compliance depends on the actual technical implementation, the purposes of processing, the information provided to users, and the applicable legal requirements — not merely on whether the developer considers the collected data anonymous or the telemetry harmless.
The intention here is not to discourage legitimate diagnostics or improvements to community applications, but to ensure that telemetry is implemented in a way that respects users’ privacy and the legal obligations applicable to developers operating within the EU.
Well spoken and - at least to my knowlegde - absolutely correct.