Summary
Mobile MCP currently initializes PostHog telemetry and sends usage events to a
maintainer-controlled analytics project by default, unless users explicitly set
MOBILEMCP_DISABLE_TELEMETRY. This opt-out design creates meaningful security,
privacy, and compliance risk for organizations that use Mobile MCP in sensitive
or regulated environments.
Background
Mobile MCP is a tool that automates real mobile devices and simulators. In the
course of normal operation it interacts with:
- Real device screens and UI hierarchies (accessibility trees)
- App state, launch/termination events, and bundle identifiers
- Device orientation, screen recordings, and screenshots
- Crash logs and diagnostic output
- URLs opened inside apps
- Automation workflows that may touch internal or production apps
This is not a generic developer tool operating on inert files. It operates
against live device state that may reflect real user data, internal application
behavior, or enterprise-controlled systems.
The problem with opt-out telemetry in this context
1. Telemetry is sent before security review can disable it
Enterprise security teams review OSS dependencies and approve them for use
before they reach production environments. In an opt-out model, telemetry begins
flowing the moment a developer runs the tool — before any review has taken place,
before MOBILEMCP_DISABLE_TELEMETRY has been added to configuration, and often
before IT or security teams are even aware the tool is in use. This means data
may leave the organization during the evaluation or onboarding period, which is
precisely when security review is supposed to happen.
2. The embedded project token prevents organizations from controlling their
telemetry destination
The PostHog project token hardcoded in source routes all telemetry to a
project controlled by the package maintainer. Organizations have no ability to:
- Redirect telemetry to their own analytics infrastructure
- Apply data residency or sovereignty controls to telemetry data
- Audit what is being sent before it leaves their network
- Rotate or revoke the token if it is deemed a risk
This is especially significant in environments subject to data residency
requirements (GDPR, CCPA, HIPAA, FedRAMP) where any outbound data flow to a
third-party SaaS system requires explicit approval.
3. Embedded ingestion tokens allow unwanted event submission
A PostHog project token is a public ingestion credential — it is not a read
key, but it does allow anyone who obtains it to submit arbitrary events to the
same PostHog project. Because the token is committed to a public repository, it
can be extracted by anyone who audits the source or inspects the running process.
This creates two risks:
- Competitors or bad actors can pollute the maintainer's analytics with synthetic
events, degrading the quality of telemetry data.
- Organizations subject to supply chain security audits (SOC 2, ISO 27001) may
flag an embedded third-party ingestion credential as a finding, blocking
approval of the dependency entirely.
4. Opt-out requires every deployment to be configured correctly
In practice, organizations deploy tools like Mobile MCP across CI/CD pipelines,
developer workstations, shared build servers, and automated testing
infrastructure. Correctly setting MOBILEMCP_DISABLE_TELEMETRY in every
environment requires explicit action at every deployment point. A single
misconfigured environment silently sends telemetry. An opt-in model inverts
this: telemetry only flows when explicitly enabled, so misconfiguration is safe
by default.
5. Automated security scanners flag default-on telemetry
Tools such as Snyk, Semgrep, and internal OSS governance systems flag packages
that perform network egress by default as part of automated supply chain risk
assessment. A finding in an automated scan can block a dependency from being
approved for use, require a formal security exception, or trigger a manual audit
— all of which add friction for organizations that would otherwise be happy to
use the tool. The embedded token specifically triggered a credential exposure
finding in Snyk scanning.
6. Enterprise CI environments may have restricted outbound network access
Many enterprise CI/CD environments run in air-gapped or egress-filtered networks
where outbound connections to external SaaS endpoints are blocked at the firewall
level. When Mobile MCP attempts to send telemetry in these environments, the
connection either hangs (adding latency to every tool invocation) or fails
silently. In either case the tool is degraded and the organization has no control
over the behavior without setting the opt-out variable.
What opt-in telemetry would look like
Telemetry should be disabled by default. No network connection to any external
telemetry endpoint should be attempted unless a user has explicitly opted in.
Opt-in should require:
- An explicit environment variable such as
MOBILEMCP_TELEMETRY=1 or
MOBILEMCP_TELEMETRY=true.
- A user-supplied project token (
MOBILEMCP_POSTHOG_PROJECT_TOKEN) so
telemetry goes to a destination the user controls, not the maintainer's
project.
- Fail-closed behavior: if telemetry is enabled but configuration is
incomplete, the tool should disable telemetry and warn — not fall back to
sending data to a default destination.
This approach preserves the ability to collect telemetry for maintainers who
want it (they can run their own PostHog project and opt in), while making the
default behavior safe for all users.
Impact on security-conscious adopters
Organizations with formal OSS approval processes, supply chain security
requirements, or data residency obligations cannot approve software with
default-on telemetry that routes to maintainer-controlled infrastructure. This
effectively blocks Mobile MCP from being used in:
- Enterprise mobile development teams subject to SOC 2 or ISO 27001 audits
- Government and defense contractors with FedRAMP or ITAR considerations
- Healthcare organizations subject to HIPAA
- Any organization in the EU with data residency requirements under GDPR
- Companies with internal OSS governance policies that require opt-in telemetry
Request
Change telemetry from opt-out to opt-in. Remove the embedded PostHog project
token. Require users to supply their own telemetry destination and token before
any telemetry is initialized or transmitted. Treat missing or incomplete
configuration as disabled, not as a signal to use a default destination.
A reference implementation is available in
PR #329.
Summary
Mobile MCP currently initializes PostHog telemetry and sends usage events to a
maintainer-controlled analytics project by default, unless users explicitly set
MOBILEMCP_DISABLE_TELEMETRY. This opt-out design creates meaningful security,privacy, and compliance risk for organizations that use Mobile MCP in sensitive
or regulated environments.
Background
Mobile MCP is a tool that automates real mobile devices and simulators. In the
course of normal operation it interacts with:
This is not a generic developer tool operating on inert files. It operates
against live device state that may reflect real user data, internal application
behavior, or enterprise-controlled systems.
The problem with opt-out telemetry in this context
1. Telemetry is sent before security review can disable it
Enterprise security teams review OSS dependencies and approve them for use
before they reach production environments. In an opt-out model, telemetry begins
flowing the moment a developer runs the tool — before any review has taken place,
before
MOBILEMCP_DISABLE_TELEMETRYhas been added to configuration, and oftenbefore IT or security teams are even aware the tool is in use. This means data
may leave the organization during the evaluation or onboarding period, which is
precisely when security review is supposed to happen.
2. The embedded project token prevents organizations from controlling their
telemetry destination
The PostHog project token hardcoded in source routes all telemetry to a
project controlled by the package maintainer. Organizations have no ability to:
This is especially significant in environments subject to data residency
requirements (GDPR, CCPA, HIPAA, FedRAMP) where any outbound data flow to a
third-party SaaS system requires explicit approval.
3. Embedded ingestion tokens allow unwanted event submission
A PostHog project token is a public ingestion credential — it is not a read
key, but it does allow anyone who obtains it to submit arbitrary events to the
same PostHog project. Because the token is committed to a public repository, it
can be extracted by anyone who audits the source or inspects the running process.
This creates two risks:
events, degrading the quality of telemetry data.
flag an embedded third-party ingestion credential as a finding, blocking
approval of the dependency entirely.
4. Opt-out requires every deployment to be configured correctly
In practice, organizations deploy tools like Mobile MCP across CI/CD pipelines,
developer workstations, shared build servers, and automated testing
infrastructure. Correctly setting
MOBILEMCP_DISABLE_TELEMETRYin everyenvironment requires explicit action at every deployment point. A single
misconfigured environment silently sends telemetry. An opt-in model inverts
this: telemetry only flows when explicitly enabled, so misconfiguration is safe
by default.
5. Automated security scanners flag default-on telemetry
Tools such as Snyk, Semgrep, and internal OSS governance systems flag packages
that perform network egress by default as part of automated supply chain risk
assessment. A finding in an automated scan can block a dependency from being
approved for use, require a formal security exception, or trigger a manual audit
— all of which add friction for organizations that would otherwise be happy to
use the tool. The embedded token specifically triggered a credential exposure
finding in Snyk scanning.
6. Enterprise CI environments may have restricted outbound network access
Many enterprise CI/CD environments run in air-gapped or egress-filtered networks
where outbound connections to external SaaS endpoints are blocked at the firewall
level. When Mobile MCP attempts to send telemetry in these environments, the
connection either hangs (adding latency to every tool invocation) or fails
silently. In either case the tool is degraded and the organization has no control
over the behavior without setting the opt-out variable.
What opt-in telemetry would look like
Telemetry should be disabled by default. No network connection to any external
telemetry endpoint should be attempted unless a user has explicitly opted in.
Opt-in should require:
MOBILEMCP_TELEMETRY=1orMOBILEMCP_TELEMETRY=true.MOBILEMCP_POSTHOG_PROJECT_TOKEN) sotelemetry goes to a destination the user controls, not the maintainer's
project.
incomplete, the tool should disable telemetry and warn — not fall back to
sending data to a default destination.
This approach preserves the ability to collect telemetry for maintainers who
want it (they can run their own PostHog project and opt in), while making the
default behavior safe for all users.
Impact on security-conscious adopters
Organizations with formal OSS approval processes, supply chain security
requirements, or data residency obligations cannot approve software with
default-on telemetry that routes to maintainer-controlled infrastructure. This
effectively blocks Mobile MCP from being used in:
Request
Change telemetry from opt-out to opt-in. Remove the embedded PostHog project
token. Require users to supply their own telemetry destination and token before
any telemetry is initialized or transmitted. Treat missing or incomplete
configuration as disabled, not as a signal to use a default destination.
A reference implementation is available in
PR #329.