Introduction and Problem Statement
Self-hosted software is increasingly adopted for its promise of enhanced privacy and data sovereignty. However, a critical vulnerability has emerged in Immich Machine Learning, a self-hosted photo processing application. The application’s integration of Microsoft’s ONNX Runtime library has inadvertently activated default telemetry, silently transmitting user data to Microsoft’s servers. This breach not only undermines the foundational principles of self-hosting but also raises urgent concerns about transparency and trust in open-source ecosystems.
Technical Analysis
Immich Machine Learning leverages ONNX Runtime, a high-performance library for machine learning inference. By design, ONNX Runtime enables telemetry by default, as explicitly stated in its privacy documentation. Upon deployment of Immich’s Docker container, this telemetry mechanism remains active, initiating DNS queries to Microsoft’s telemetry endpoint (mobile.events.data.microsoft.com). These queries occur during runtime, irrespective of whether the application processes sensitive data, such as personal photographs.
The causal mechanism is clear: ONNX Runtime’s default telemetry setting triggers DNS queries to Microsoft’s servers, potentially exfiltrating user metadata. While Microsoft asserts that collected data is anonymized, the transmission of metadata from user-generated content directly contradicts the self-hosting ethos of retaining exclusive control over data.
Critical Risks and Edge Cases
For users processing sensitive or proprietary images, the risks extend beyond privacy invasion. If telemetry data includes metadata or cryptographic hashes of processed images, it could inadvertently expose intellectual property or personally identifiable information (PII). Furthermore, unblocked DNS queries serve as a red flag for network administrators, indicating unauthorized communication with external entities.
Compounding the issue, Immich’s developers have yet to address the problem, despite it being reported in August. This delay risks normalizing privacy violations within open-source communities, where users expect proactive safeguards against such vulnerabilities.
Mitigation Strategies
To disable telemetry, users must explicitly set the environment variable ORT_DISABLE_TELEMETRY=1 within the immich-machine-learning container. This override directly suppresses ONNX Runtime’s default telemetry behavior, halting DNS queries to Microsoft’s servers. Additionally, isolating the container from external networks using Docker’s internal network feature prevents unintended outbound communication:
-
Step 1: Add the environment variable
ORT_DISABLE_TELEMETRY=1to the container configuration. - Step 2: Create an isolated Docker network:
networks: immich-iso: internal: true driver: bridge
- Step 3: Attach Immich containers to this isolated network, ensuring only the reverse proxy maintains external access.
While these measures are effective, they place an undue burden on users to rectify a problem introduced by default configurations. The responsibility for ensuring privacy in self-hosted solutions must rest with developers, not end-users.
Broader Implications
This incident underscores a systemic issue in open-source software: the uncritical integration of third-party libraries without rigorous privacy audits. ONNX Runtime’s telemetry, though optional, is enabled by default—a design choice fundamentally at odds with self-hosting principles. If unaddressed, such practices will erode trust in self-hosted tools, driving users back to centralized services they sought to avoid.
Immich’s case serves as a critical reminder for both developers and users. Transparency, proactive auditing, and respect for user autonomy must become non-negotiable standards in self-hosted software development. Until these principles are universally adopted, users must remain vigilant, treating every dependency as a potential vector for privacy breaches.
Disabling Telemetry in Immich Machine Learning: A Privacy-Centric Approach
Immich Machine Learning, a self-hosted photo processing application, integrates Microsoft’s ONNX Runtime library to optimize machine learning operations. However, this library activates telemetry by default, initiating DNS queries to Microsoft’s telemetry endpoint (mobile.events.data.microsoft.com). This default behavior contradicts the fundamental principle of self-hosting: retaining complete control over data and infrastructure. The following guide outlines precise steps to disable telemetry and fortify the isolation of your Immich deployment, ensuring compliance with privacy-first self-hosting practices.
1. Disabling Telemetry in ONNX Runtime
Telemetry in ONNX Runtime is enabled by default, as explicitly stated in its privacy documentation. To deactivate this functionality, users must explicitly configure an environment variable within the immich-machine-learning container. Execute the following steps:
-
Set the environment variable: Incorporate
ORT_DISABLE_TELEMETRY=1into your Docker configuration. This variable directly inhibits the telemetry mechanism within ONNX Runtime, preventing the generation and transmission of DNS queries to Microsoft’s servers. -
Mechanism: The
ORT_DISABLE_TELEMETRYvariable intercepts the initialization of ONNX Runtime’s telemetry module at runtime, bypassing the default behavior of constructing and dispatching HTTP requests to Microsoft’s telemetry endpoint. This intervention ensures that no metadata related to usage is exfiltrated.
2. Network Isolation of Immich Containers
Disabling telemetry alone does not preclude potential data exposure. To enforce a robust self-hosting environment, isolate Immich containers from external networks. Implement the following measures using Docker Compose:
-
Create an isolated network: Define a Docker network with
internal: trueand thebridgedriver. This configuration confines network traffic to the Docker environment, effectively blocking external communication. - Attach Immich containers: Assign all Immich-related containers to this isolated network. Reserve external network connectivity exclusively for your reverse proxy to handle incoming requests.
-
Mechanism: Docker’s network isolation operates by configuring the virtual Ethernet bridge (
bridgedriver) to discard packets destined for external IP addresses. This physical restriction ensures that containers cannot establish unauthorized outbound connections, thereby eliminating the risk of unintended data transmission.
3. Validation of Security Measures
Post-implementation, validate the effectiveness of telemetry disablement and network isolation through the following procedures:
- Monitor DNS logs: Inspect DNS logs for queries to mobile.events.data.microsoft.com. Successful disablement of telemetry will eliminate these queries, confirming the absence of telemetry activity.
-
Test network isolation: Execute
pingcommands to external IP addresses from within the Immich containers. If isolation is correctly configured, these commands will fail, verifying that external communication is blocked at the network level.
4. Broader Implications and Developer Accountability
This issue underscores a pervasive challenge in self-hosted software ecosystems: the integration of third-party libraries without rigorous privacy audits. Developers must adopt the following practices to uphold user privacy and autonomy:
- Transparency: Explicitly document all dependencies and their default behaviors, ensuring users are informed of potential privacy implications.
- Proactive auditing: Conduct comprehensive privacy assessments of third-party libraries prior to integration, identifying and mitigating risks proactively.
- User autonomy: Implement opt-out mechanisms for telemetry and data-sharing features, empowering users to retain control over their data.
Until such practices become standard, users must proactively safeguard their self-hosted environments. By disabling telemetry and enforcing network isolation, you restore control over your data, aligning your deployment with the core tenets of self-hosting.
Conclusion and Best Practices
The integration of Microsoft telemetry within Immich Machine Learning, enabled by default through the ONNX Runtime library, exposes a critical vulnerability in self-hosted software ecosystems: third-party dependencies can autonomously compromise user privacy without explicit consent. This issue transcends technical oversight, constituting a fundamental breach of the trust inherent in self-hosting. Self-hosting relies on absolute control and transparency over data processing workflows. However, ONNX Runtime’s telemetry module, upon initialization, generates DNS queries to Microsoft’s servers (mobile.events.data.microsoft.com), potentially exfiltrating metadata associated with photo processing tasks. The causal mechanism is unambiguous: the telemetry module is instantiated at runtime, unconditionally triggering HTTP requests regardless of data sensitivity or user intent. This behavior directly contravenes the core tenet of self-hosting: maintaining exclusive user control over data.
Why This Matters
The implications are profound. Unchecked, such privacy violations establish a dangerous precedent, normalizing the silent exfiltration of data from self-hosted environments to external entities. For users processing sensitive content—such as personal photographs or proprietary intellectual property—this risk is intolerable. The concern extends beyond Microsoft; it underscores a systemic issue in software development: the uncritical integration of third-party libraries without rigorous auditing of their default behaviors. Even anonymized telemetry data exposes critical metadata, including cryptographic hashes of processed images and usage patterns. Once transmitted, this data falls outside user control, nullifying the privacy guarantees of self-hosting.
Practical Mitigations
Immediate action is imperative to safeguard user data. Implement the following measures:
-
Disable Telemetry: Inject the environment variable
ORT_DISABLE_TELEMETRY=1into theimmich-machine-learningcontainer. This intervention intercepts the telemetry module’s initialization process, physically blocking HTTP requests to Microsoft’s endpoint. -
Enforce Network Isolation: Deploy Docker Compose to configure an isolated network with
internal: trueandbridgedriver settings. This architecture discards outbound packets destined for external IP addresses, confining Immich containers to internal communication. Attach your reverse proxy to this isolated network to preserve external accessibility while maintaining internal segregation.
Developer Accountability
While users can mitigate this issue, ultimate responsibility rests with developers. The Immich team’s inaction since the issue’s reporting in August exemplifies a pervasive problem: privacy is systematically deprioritized in open-source projects. Developers must adopt proactive measures:
- Audit Third-Party Libraries: Prior to integration, conduct exhaustive assessments of dependencies like ONNX Runtime. Telemetry mechanisms should never default to enabled in self-hosted software.
- Document Dependencies Transparently: Explicitly disclose all third-party components, their default configurations, and potential data flows. Transparency is non-negotiable for building user trust.
- Enforce Opt-In Telemetry: If telemetry is deemed necessary, implement an opt-in model, ensuring users retain explicit control over data transmission.
Edge Cases and Risks
Address edge cases rigorously: even with telemetry disabled, network isolation remains critical. Without it, other components in your infrastructure may still initiate external communication, bypassing telemetry mitigations. Validate your configuration by monitoring DNS logs for unauthorized queries to Microsoft’s endpoints and testing network isolation using ping commands. Failure to enforce network isolation exposes your system to persistent data leakage risks, irrespective of telemetry settings.
Final Thoughts
Self-hosting represents a commitment to privacy and autonomy. The Immich telemetry issue serves as a stark reminder: default behaviors in third-party libraries can silently subvert these principles. Users must maintain vigilance, regularly auditing and adjusting configurations to preempt vulnerabilities. Developers, in turn, must embed transparency and user sovereignty into their design paradigms. Only through concerted action can we restore trust in self-hosted solutions and ensure they deliver on their promise of uncompromised privacy.

Top comments (0)