# Did not meet TRUSTED criteria This build did not satisfy all of CITT's published criteria for the TRUSTED mark. The full criteria and this app's results are shown below. ## Trust Pillars - **Secure by Design**: Not met. Did not meet one criterion in this area. - **Data Minimization**: Not met. Did not meet one criterion in this area. - **Manifest Mismatch**: Not met. Did not meet one criterion in this area. - **User Control**: Strong. Strong result in this area. - **Truly Local**: Not applicable. Does not apply to this app. - **Child-Safe**: Not applicable. Does not apply to this app. --- # Security & Privacy Scorecard ## Meross Smart Home ## What This Means for You Smart home commands issued through Matter or HomeKit stay within Apple's end-to-end encrypted infrastructure and do not reach Meross servers. The build's device provisioning path uses hardcoded static encryption keys, which a network observer on the same local network during device setup may be able to use to recover the home Wi-Fi password. ## Recommendation: Solid CITT rates this Solid (78/100). Login information and device keys are stored in the iOS Keychain, and cloud connections to Meross servers carry additional server identity verification on top of standard transport security. The provisioning flow for adding new devices to a home network uses a static encryption key, creating a window where a local network observer could potentially recover the Wi-Fi password entered during pairing. Firmware updates for connected devices may be delivered over unencrypted connections in some code paths. **Best For:** People who use Meross smart plugs, switches, and lights and want native HomeKit or Matter integration with Apple's encrypted device control infrastructure. ## Method and Limitations Static analysis only. CITT reviewed the code of this build without running the app, so runtime behavior was not observed. The findings below describe the analyzed build and may not reflect server-side controls or later versions. CITT makes no determination about compliance with any law or platform policy; it reports what the artifacts contain and cites the published guidance so a reader can compare. ## Key Findings **Data Security** - 0 findings **Network Security** - 1 finding (1 medium) **Code Safety** - 2 findings (1 medium, 1 low) **Privacy** - 1 finding (1 medium) ## Privacy Concerns ### What Leaves the Device - Usage and session data: the binary links the Firebase Analytics SDK, which is designed to share device identifiers and behavioral data with Google for analytics purposes. - Crash reports: the binary links Firebase Crashlytics, which may share diagnostic information with Google when the app encounters an error. - Device IP address: the binary contains an unencrypted URL path for ipinfo.io alongside a secure path. If the unencrypted path is exercised, the device's public IP is sent to ipinfo.io, which can infer approximate city, region, and coordinates from that IP without an iOS location permission being requested. This was not observed at runtime. ### What Stays on the Device Smart home commands issued through Matter or HomeKit are handled on the local network or within Apple's end-to-end encrypted infrastructure and do not pass through Meross cloud servers. This means the state of connected devices remains outside Meross's visibility when using HomeKit or Matter control paths. ### Third-Party Data Sharing **Third parties that may receive data from the app:** - Firebase Analytics (Google) - usage analytics and device identifiers - Firebase Crashlytics (Google) - crash and error reporting - Firebase Messaging (Google) - push notifications - AWS (Amazon) - cloud authentication, backend services, and file storage - OpenWeatherMap - weather data for home automations - ipinfo.io - IP-based location lookup - Kookong SDK - Bluetooth and IoT device communication - OpenTelemetry Swift - application telemetry ## Understanding the Scores **Security:** 75/100 **Privacy:** 86/100 ### Security Breakdown - **Data Security:** 82/100. Login information, device keys, and session keys are stored in the iOS Keychain, hardware-backed storage that other apps cannot access. The Wi-Fi provisioning path uses a static encryption key that a local network observer may be able to use to recover the home Wi-Fi password during device pairing. - **Network Security:** 82/100. Cloud connections to Meross infrastructure carry additional server identity verification layered on top of standard transport security. The MQTT connection between the app and local smart home devices on the home network may be configured to accept unverified server identities, based on static analysis - this was not observed at runtime and the scope appears limited to local-network connections. - **Code Safety:** 90/100. Memory protection is active throughout the binary. External web content is opened in a sandboxed browser with no interface between web content and native device controls. ### Privacy Breakdown - **Data Collection:** 85/100. The binary links Firebase Analytics and Crashlytics, which are designed to share usage and diagnostic data with Google. No advertising SDK is present and no data broker SDK was identified. - **Data Sharing:** 90/100. Data sharing is limited to the developer's own infrastructure and the analytics and cloud services listed under Third-Party Data Sharing. No advertising network or data broker SDK was identified in this build. - **User Control:** 87/100. Smart home device control via HomeKit and Matter keeps activity within Apple's encrypted infrastructure. Standard iOS controls govern notification access. ## Positive Security Features - Smart home commands issued through Matter or HomeKit stay on the local network or within Apple's end-to-end encrypted infrastructure and do not pass through Meross cloud servers. - Cloud connections to Meross servers carry additional server identity verification layered on top of standard transport security, making it harder for a local observer to impersonate the Meross backend. - Login information, session keys, and device keys are stored in the iOS Keychain, hardware-backed storage that is inaccessible to other apps. - Shared data storage is restricted to the developer's own first-party app extensions under a single developer Team ID; no third-party developer can access it. - External web pages are opened in a sandboxed browser view with no access to the app's own storage or session data. - The embedded browser has no interface between web content and native smart home controls, so web content cannot reach device APIs. - Memory protection is active throughout the binary, providing defense against memory corruption. - No advertising SDK is present; no broad-reach ad network has access to usage data. ## Areas for Improvement ### Disclosure observations Observations about disclosure, each stated against the published guidance so a reader can compare: 1. **Analytics SDK disclosure** Apple's App Store privacy label guidelines require developers to declare data types collected by third-party SDKs integrated into the app. The build links Firebase Analytics (Google), which is designed to collect device identifiers and behavioral data. The app's privacy manifest declares no collected data types. Readers can compare Firebase's published data practices against the current App Store privacy label to assess whether the disclosure is complete. 2. **IP-based location lookup disclosure** The binary contains an unencrypted URL path for ipinfo.io that, if exercised, would send the device's IP address to a third-party service that returns approximate geographic location derived from that IP. This flow does not require an iOS location permission. Whether this path is exercised in production could not be determined from static analysis alone, and it is not reflected in the current privacy manifest. ### Security Enhancements 1. **Wi-Fi provisioning key hardening** The device provisioning path uses a static encryption key to protect the home Wi-Fi password during setup. Generating a unique key per pairing session would eliminate the window in which a local network observer could potentially recover that password. 2. **Firmware update transport security** Ensuring firmware update downloads for connected devices always use encrypted connections, with integrity verification that cannot be substituted by a local network observer, would reduce the risk of malicious firmware being delivered on the home network. 3. **URL scheme input validation** The custom URL scheme registered in the build can be invoked by any other installed app without a permission prompt. Verifying that inbound URL scheme requests occur within an authenticated session before executing any device control actions would reduce the risk of unauthorized device actuation by other apps. ## Technical Context **App Type:** IoT smart home controller, cloud and local network **Classes Analyzed:** 180,206 **Third-Party Services:** 10 **Context Tags:** iot, smart_home, location, camera, bluetooth --- ## About This Analysis This security analysis was conducted by CITT (Can I Trust That), an independent security analysis service. The analysis is static code review of iOS applications, intended to help people make informed decisions about app security and privacy. ### App Details **Developer:** Meross **Version:** 3.42.0 (Build 698) **Analysis Date:** 2026-08-22 **Package:** com.meross.Meross ### Analysis Limitations - Static analysis only (code review without running the app) - Based on iOS build 3.42.0 (Build 698) analyzed on 2026-08-22 - May not reflect server-side security controls - Cannot detect all runtime behaviors