Google Analytics in firmware – privacy / consent considerations

[limpkin]

Hi,

While building and flashing this firmware, I noticed that it appears to send usage statistics to Google Analytics.

I could only find a mention of this on the MoonLight documentation page here:
https://moonmodules.org/MoonLight/network/sta/#moonlight-analytics

However, I did not see this mentioned in the main repository README or on the firmware’s welcome page / UI.

Because this is firmware running on a physical device (not just a website), this may raise privacy and regulatory questions in some jurisdictions, particularly under regulations like the GDPR and the Swiss FADP, where sending analytics data (especially to third-party services such as Google) can require transparency and sometimes user consent.

For users compiling or distributing this firmware (for example in DIY projects or commercial hardware), silent telemetry could potentially create legal or compliance issues if it is enabled by default and not clearly disclosed.

It might be worth considering one or more of the following:

documenting the analytics behavior clearly in the repository README and/or firmware UI

specifying exactly what data is sent

providing a compile-time option to disable analytics

disabling analytics by default

optionally allowing self-hosted telemetry instead of Google Analytics

This would help users who integrate this firmware into their own devices understand the privacy implications and stay compliant with local regulations.

Thanks for the project — it’s very useful.

[ewowi]

@coderabbitai, please investigate above concerns and come with a proposal to better address this in the documentation (/docs)

regarding :

providing a compile-time option to disable analytics
disabling analytics by default

I would like to avoid that as I see this as part of the agreement in using MoonLight - with the option to opt-out - please check this against privacy and regulatory questions in general and in particular jurisdictions, particularly under regulations like the GDPR and the Swiss FADP and come with doc proposals which covers this

[coderabbitai]

Coding Plan

Summary

• Change the runtime default from opt-in to opt-out by modifying the server-side default value
• Make the existing FT_ANALYTICS compile-time flag functional by adding preprocessor guards around all analytics code
• Change the compile-time default to disabled (FT_ANALYTICS=0) for privacy-by-default builds
• Add transparency through README documentation and a brief notice on the welcome page linking to settings

Design Choices

Design Choice 1: Compile-time flag implementation scope

Options Considered:

1. Add #if FT_ENABLED(FT_ANALYTICS) guards around the sendAnalytics() function and related field handling
2. Remove the existing unused flag and document that runtime toggle is the only option

Chosen Option: 1

Rationale: Add proper compile-time guards to make the existing flag functional, matching the established FT_* pattern for other features.

Design Choice 2: Self-hosted telemetry option

Options Considered:

1. Implement configurable analytics endpoint
2. Defer self-hosted telemetry as a future enhancement

Chosen Option: 2

Rationale: This is a significant feature addition beyond the core privacy concerns. The immediate ticket goals are transparency and opt-out default—self-hosted telemetry can be a separate future ticket.

💡 User Tips

Regenerate the plan with different choices with @coderabbitai <feedback>.

Implementation Steps

Phase 1: Backend Privacy Defaults and Compile-Time Guards

This phase addresses the core technical changes needed to make analytics opt-out by default and properly respect the existing compile-time feature flag.

Task 1: Change Server-Side Default to Opt-Out

Change the default value for trackAnalytics from true to false so analytics is disabled by default on fresh installations.

• Update lib/framework/WiFiSettingsService.h line 135: change the ternary default from true to false in the deserialize logic
• This ensures new devices or factory-reset devices have analytics disabled until the user explicitly enables it

Task 2: Add Compile-Time Feature Guards

Wrap the analytics code with FT_ANALYTICS preprocessor guards so the feature can be completely compiled out when disabled.

• In lib/framework/WiFiSettingsService.cpp: wrap the sendAnalytics() function definition (lines 198-260) with #if FT_ENABLED(FT_ANALYTICS) / #endif
• In lib/framework/WiFiSettingsService.cpp: wrap the analytics call in loop() (lines 280-285) with the same guard
• In lib/framework/WiFiSettingsService.h: wrap the trackAnalytics field declaration (line 87) and its serialization/deserialization (lines 96, 135) with the guard
• Wrap the _analyticsSent member variable declaration similarly
• This follows the established pattern of other FT_* guarded features in the codebase

Task 3: Update Default Flag Value in features.ini

Change the default compile-time flag to disabled for privacy-by-default.

• Update features.ini line 10: change FT_ANALYTICS=1 to FT_ANALYTICS=0
• Add an inline comment explaining users can enable it if desired
• This ensures that default builds have analytics completely compiled out

🤖 Prompt for AI agents

Implement backend privacy defaults and compile-time guards for Google Analytics
in the firmware. The goal is to make analytics opt-out by default and ensure the
existing `FT_ANALYTICS` compile-time flag actually guards all analytics code.

**Task 1: Change the runtime default to opt-out**
- In `lib/framework/WiFiSettingsService.h` (line 135), update the ternary
default for `trackAnalytics` from `true` to `false` in the deserialize logic

**Task 2: Add compile-time `FT_ANALYTICS` preprocessor guards**
- In `lib/framework/WiFiSettingsService.cpp`:
- Wrap the `sendAnalytics()` function definition (lines 198–260) with `#if
FT_ENABLED(FT_ANALYTICS)` / `#endif`
- Wrap the analytics call in `loop()` (lines 280–285) with the same `#if
FT_ENABLED(FT_ANALYTICS)` / `#endif` guard
- In `lib/framework/WiFiSettingsService.h`:
- Wrap the `trackAnalytics` field declaration (line 87) with `#if
FT_ENABLED(FT_ANALYTICS)` / `#endif`
- Wrap its serialization and deserialization (lines 96 and 135) with the same
guard
  - Wrap the `_analyticsSent` member variable declaration with the same guard
- Follow the established `FT_*` pattern used by other guarded features in the
codebase

**Task 3: Update the compile-time default in `features.ini`**
- Change line 10 from `FT_ANALYTICS=1` to `FT_ANALYTICS=0`
- Add an inline comment explaining that users can re-enable it if desired

Phase 2: Documentation and UI Disclosure

This phase adds the required transparency by documenting analytics in the README and adding a notice to the firmware welcome page.

Task 1: Add Privacy Section to README

Add a dedicated privacy/analytics section to the README documenting the analytics behavior.

• Add a new ## 🔒 Privacy & Analytics section in README.md before the ⚠️ Disclaimer section (around line 245)
• Document what data is collected: country, firmware type, board model, version
• Document when data is sent: on device restart
• State that a random anonymous client ID is generated each boot (no persistent tracking)
• State that Google Analytics is the recipient
• Explain the opt-out mechanism: runtime toggle in WiFi settings
• Explain the compile-time option: FT_ANALYTICS=0 to exclude entirely
• Link to the detailed documentation at docs/network/sta.md

Task 2: Add Analytics Notice to Welcome Page

Add a brief, non-intrusive analytics disclosure to the firmware's welcome/landing page.

• Update interface/src/routes/+page.svelte to add a small text notice after the community links section (before closing card-body div)
• Use subdued styling (e.g., text-xs text-base-content/60) to keep it unobtrusive
• Include brief text: "ℹ️ MoonLight can send anonymous analytics on restart."
• Add a link to the WiFi settings page (/wifi/sta) with text "Settings" or "Learn more / opt out"
• This provides immediate visibility without disrupting the welcome flow

🤖 Prompt for AI agents

Add transparency documentation and a UI disclosure notice for the analytics
feature. The goal is to inform users about analytics behavior in both the README
and the firmware welcome page.

**Task 1: Add a Privacy & Analytics section to `README.md`**
- Insert a new `## 🔒 Privacy & Analytics` section before the ⚠️ Disclaimer
section (around line 245)
- The section must cover:
  - What data is collected: country, firmware type, board model, version
  - When data is sent: on device restart
- That a random anonymous client ID is generated each boot (no persistent
tracking)
  - That Google Analytics is the recipient
  - The opt-out mechanism: runtime toggle in WiFi settings
- The compile-time option: setting `FT_ANALYTICS=0` to exclude analytics
entirely from the build
  - A link to `docs/network/sta.md` for detailed documentation

**Task 2: Add an analytics notice to the welcome page in
`interface/src/routes/+page.svelte`**
- After the community links section and before the closing card-body div, add a
small text notice
- Use subdued styling such as `text-xs text-base-content/60` to keep it
unobtrusive
- Display the text: "ℹ️ MoonLight can send anonymous analytics on restart."
- Include a link to `/wifi/sta` with text "Settings" or "Learn more / opt out"

Research

The firmware includes a Google Analytics 4 implementation in lib/framework/WiFiSettingsService.cpp that sends anonymous usage data (country, firmware type, board model, version) on device restart. A runtime toggle trackAnalytics exists in the WiFi settings UI, and a compile-time flag FT_ANALYTICS=1 is defined in features.ini. However, the server-side default is currently true (opt-in), the compile-time flag doesn't actually guard the analytics code, the README has no privacy disclosure, and the welcome page lacks any mention of analytics.

---

🚀 Next Steps

🤖 All AI agent prompts combined

Task: 1

Implement backend privacy defaults and compile-time guards for Google Analytics
in the firmware. The goal is to make analytics opt-out by default and ensure the
existing `FT_ANALYTICS` compile-time flag actually guards all analytics code.

**Task 1: Change the runtime default to opt-out**
- In `lib/framework/WiFiSettingsService.h` (line 135), update the ternary
default for `trackAnalytics` from `true` to `false` in the deserialize logic

**Task 2: Add compile-time `FT_ANALYTICS` preprocessor guards**
- In `lib/framework/WiFiSettingsService.cpp`:
- Wrap the `sendAnalytics()` function definition (lines 198–260) with `#if
FT_ENABLED(FT_ANALYTICS)` / `#endif`
- Wrap the analytics call in `loop()` (lines 280–285) with the same `#if
FT_ENABLED(FT_ANALYTICS)` / `#endif` guard
- In `lib/framework/WiFiSettingsService.h`:
- Wrap the `trackAnalytics` field declaration (line 87) with `#if
FT_ENABLED(FT_ANALYTICS)` / `#endif`
- Wrap its serialization and deserialization (lines 96 and 135) with the same
guard
  - Wrap the `_analyticsSent` member variable declaration with the same guard
- Follow the established `FT_*` pattern used by other guarded features in the
codebase

**Task 3: Update the compile-time default in `features.ini`**
- Change line 10 from `FT_ANALYTICS=1` to `FT_ANALYTICS=0`
- Add an inline comment explaining that users can re-enable it if desired
===============================================================================

Task: 2

Add transparency documentation and a UI disclosure notice for the analytics
feature. The goal is to inform users about analytics behavior in both the README
and the firmware welcome page.

**Task 1: Add a Privacy & Analytics section to `README.md`**
- Insert a new `## 🔒 Privacy & Analytics` section before the ⚠️ Disclaimer
section (around line 245)
- The section must cover:
  - What data is collected: country, firmware type, board model, version
  - When data is sent: on device restart
- That a random anonymous client ID is generated each boot (no persistent
tracking)
  - That Google Analytics is the recipient
  - The opt-out mechanism: runtime toggle in WiFi settings
- The compile-time option: setting `FT_ANALYTICS=0` to exclude analytics
entirely from the build
  - A link to `docs/network/sta.md` for detailed documentation

**Task 2: Add an analytics notice to the welcome page in
`interface/src/routes/+page.svelte`**
- After the community links section and before the closing card-body div, add a
small text notice
- Use subdued styling such as `text-xs text-base-content/60` to keep it
unobtrusive
- Display the text: "ℹ️ MoonLight can send anonymous analytics on restart."
- Include a link to `/wifi/sta` with text "Settings" or "Learn more / opt out"

💡 Iterate on the plan with: @coderabbitai <feedback>

Example Feedback
- `@coderabbitai` You can skip phase 3. Add a simple unit test case for phase 2.
- `@coderabbitai` For design choice 1 go ahead with option 3 and replan.

---

💬 Have feedback or questions? Drop into our discord!

[ewowi]

@coderabbitai, I don't see this issue as a coding exercise at the moment but a documentation task. So thanks for the plan, but assuming we keep the opt-out approach please come with concrete text proposals to add in README.md and other places in order to inform end users. And take into account legislation so to opt-out option will hold legally (I investigated this before and it was okay, but do a recheck)

[coderabbitai]

🧩 Analysis chain

🏁 Script executed:

#!/bin/bash
# Look at existing docs/network/sta.md
fd "sta.md" --type f
cat docs/network/sta.md 2>/dev/null || echo "File not found"
echo "---"
# Look at README around line 230-260
sed -n '230,270p' README.md 2>/dev/null || echo "README.md not found at those lines"
echo "---"
# Check if there's a privacy or analytics doc already
fd "privacy" --type f
fd "analytics" --type f
echo "---"
# Look at the full README structure (headings only)
grep -n "^#" README.md | head -60

Length of output: 3594

---

@ewowi, here is a thorough legal recheck and concrete documentation proposals.

---

⚖️ Legal Recheck: Is Opt-Out Viable?

Short answer: Yes — opt-out is defensible for MoonLight, but the existing docs/network/sta.md text contains one inaccuracy that needs fixing.

Why Opt-Out Works for MoonLight

The standard concern about opt-out analytics under GDPR relates to the ePrivacy Directive (the "cookie law"), which requires opt-in consent for storing/reading data on a user's terminal device (browser cookies). Due to the ePrivacy Directive, you can't rely on legitimate interests for using non-necessary cookies — meaning you can't enable analytics first and then invite users to opt out. However, MoonLight is not a website/browser — it is embedded IoT firmware sending a single HTTP event on restart. The ePrivacy Directive's cookie rules do not apply.

For firmware-level analytics, the applicable framework is GDPR Art. 6(1)(f) Legitimate Interests, which allows processing without opt-in consent as long as a balancing test is passed. Your business can process personal data without obtaining explicit opt-in consent from consumers only if you have a genuine and justifiable reason and no other legal basis can be applied for the given processing activity. MoonLight passes this test because:

• Purpose is genuine (firmware improvement, understanding hardware adoption)
• Data is minimal (country, firmware type, board, version)
• People have the "right to object" to processing based on legitimate interests — this enables them to "opt out" of the processing.
• The opt-out toggle in WiFi settings fulfils this right to object.

For Swiss FADP, the situation is even more permissive: The FADP does not require a legal basis to process personal data according to the general principle of the law, which maintains that data processing activity is lawful in principle and a legal basis is only required should the data controller need to justify processing. Transparency and user information are vital under FADP, even when consent isn't mandatory.

One Real Risk: US Data Transfers

By mid-2025, six national DPA enforcement cases against GA4 have been published; the summary is that there is no adequate protection of EU residents' data, along with illegal transfer of their data to US-based services. Google LLC has been certified under the EU-US Data Privacy Framework (DPF) since August 2023, but multiple NGOs (e.g., NOYB) have filed challenges; the CJEU is expected to review the DPF's validity by 2026. Similarly, the Swiss-US Data Privacy Framework was approved in August 2024, but organisations often still implement backup solutions such as EU Standard Contractual Clauses with the necessary Swiss Finish to ensure compliance in case the DPF is invalidated.

These concerns are primarily targeted at companies operating websites for EU consumers. MoonLight's risk profile is much lower (open-source maker/hobbyist firmware, minimal data, person configuring the device = person who can opt out), but the transfer should still be disclosed.

One Inaccuracy in Existing Docs

The current docs/network/sta.md states: "No personal data, IP addresses, or identifiers that can trace back to an individual are collected, stored, or shared." This is not accurate — the device's IP address is sent to ip-api.com to determine the country. It should be corrected to say the IP is sent to ip-api.com for country lookup only, and only the resulting country field is forwarded to Google Analytics.

---

📝 Concrete Documentation Proposals

1. docs/network/sta.md — Replace / Strengthen the Analytics Section

Replace the current "MoonLight Analytics" section with:

## 🔒 MoonLight Analytics

MoonLight can send **anonymous** usage data to Google Analytics when the device restarts.
This helps the MoonModules team understand which hardware and firmware versions are in use,
so development can focus where it matters most.

### What is collected

| Data | How it is obtained |
|---|---|
| Country (e.g. "France") | Your device's IP address is sent to [ip-api.com](http://ip-api.com) to look up the country. Only the country field is then forwarded to Google Analytics — the IP itself is not sent to Google. |
| Firmware type (e.g. `esp32-s3-n16r8v`) | Read from the build configuration. |
| Board model (e.g. `QuinLED DigQuad`) | Read from board presets (when available). |
| MoonLight version (e.g. `0.8.0`) | Read from the build. |

No names, email addresses, MAC addresses, or other information that can identify a person are
collected or sent.

Each analytics event is sent with a **random, anonymous client ID** that is re-generated on
every restart — no persistent device or user tracking is possible.

### How data is processed

- **ip-api.com** receives your device's IP address to determine country.
- **Google Analytics (GA4)** receives the four fields above plus the random client ID.
  Google LLC is certified under the [EU-US Data Privacy Framework](https://www.dataprivacyframework.gov/)
  (since August 2023), which provides a legal basis for EU-to-US data transfers under GDPR.
  This framework remains in force but is subject to ongoing legal review.
- No other parties receive your data.

### Legal basis

For users in the European Union, data is processed under **legitimate interests**
(GDPR Art. 6(1)(f)). The processing is proportionate: only four non-personal fields are
collected, no persistent identity is created, and you can opt out at any time (see below).

For users in Switzerland, the Swiss Federal Act on Data Protection (FADP, in force since
September 2023) does not require a legal basis for ordinary data processing; transparency
and the right to object are the primary obligations, both of which are met here.

> ℹ️ _MoonModules is an open-source community project, not a commercial entity. We use this
> data solely to prioritise development — not for advertising or commercial profiling._

### How to opt out

Disable **Track analytics** in this settings panel. The change takes effect immediately on
the next restart.

If you want to exclude analytics entirely from the firmware binary, set `FT_ANALYTICS=0`
in `features.ini` before building.

---

2. README.md — Add a Privacy & Analytics Section (before ## ⚠️ Disclaimer)

## 🔒 Privacy & Analytics

MoonLight **can** send anonymous usage data to Google Analytics when the device restarts.
The data is limited to: country, firmware type, board model, and MoonLight version.
A random, anonymous client ID is generated on each boot — no persistent device or user
tracking is possible.

**Opt out anytime** via the *Track analytics* toggle in the WiFi → Station settings page.
Alternatively, build with `FT_ANALYTICS=0` to exclude analytics entirely from the binary.

See [`docs/network/sta.md`](docs/network/sta.md#-moonlight-analytics) for full details,
including what data is collected, which third parties receive it (ip-api.com and Google
Analytics), and the legal basis under GDPR and the Swiss FADP.

---

3. (Optional) Welcome Page interface/src/routes/+page.svelte — Unobtrusive Notice

A small, non-disruptive disclosure line inside the card footer area:

<p class="text-xs text-base-content/60 mt-3">
  ℹ️ MoonLight may send anonymous usage analytics on restart.
  <a href="/wifi/sta" class="link link-hover">Manage in WiFi settings</a> or see the
  <a href="https://moonmodules.github.io/MoonLight/network/sta/" class="link link-hover" target="_blank">privacy notice</a>.
</p>

---

Summary of Key Changes vs. Current Docs

Issue	Current Text	Proposed Fix
IP accuracy	"No IP addresses… are collected, stored, or shared"	Disclose that ip-api.com receives the IP; clarify only country reaches GA
GDPR claim	"meets the principles of the GDPR" (vague)	State "processed under legitimate interests (Art. 6(1)(f) GDPR)"
Swiss FADP	Not mentioned	Add FADP note (no legal basis required for ordinary processing)
Data transfer	Not mentioned	Disclose Google DPF certification and ongoing legal review
Opt-out	Mentioned briefly	Make more prominent and add compile-time option
README	No privacy section	Add brief section linking to full docs

Disclaimer: I'm not a lawyer. The analysis above is based on publicly available regulatory guidance and is provided for informational purposes. For authoritative legal advice on GDPR/FADP compliance, consult a qualified data protection professional.

[ewowi]

Updated the description see https://moonmodules.org/MoonLight/network/sta/#moonlight-analytics

and added to https://moonmodules.org/MoonLight/network/sta/#moonlight-analytics and https://github.com/MoonModules/MoonLight

[limpkin]

I believe moonlight welcome page (on the device) should include this notice, with emphasis that it is an opt-out