<!-- TRUSTED_VERDICT_HEADER -->
# 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.

---
<!-- /TRUSTED_VERDICT_HEADER -->

# Security & Privacy Scorecard

## Meross

## What This Means for You

The Meross build (version 3.41.1) includes Firebase integrations that bundle the Meross account identifier into diagnostic error event data. WiFi passwords stored on the device for use during device provisioning are protected by an encryption scheme with fixed initialization vectors that reduces the protection strength compared to current industry-standard approaches.

## Recommendation: Solid

CITT rates this build 76/100 (Solid). The local device control path uses ephemeral session key negotiation between the phone and smart home devices, providing forward secrecy per session, and the build contains no advertising networks or data-broker SDKs. The WiFi password provisioning path relies on a fixed-pattern encryption scheme, and in-app content viewers are configured with unrestricted JavaScript file access that, combined with globally permitted cleartext HTTP, may allow a network adversary who intercepts CDN content to read locally stored account data.

**Best For:** People who use Meross smart home devices and want to control plugs, switches, and hubs from a smartphone.

## 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:** 4 findings (1 high, 1 medium, 2 low)

**Network Security:** 3 findings (2 medium, 1 low)

**Code Safety:** 2 findings (1 high, 1 low)

**Privacy:** 2 findings (1 medium, 1 low)

## Privacy Concerns

### What Leaves the Device

- Meross account identifier, device model, Android version, and app version: bundled into diagnostic error event parameters configured to reach Firebase Analytics when region-code or in-app browser errors occur (runtime delivery was not observed)
- Crash and stability data: shared with Firebase Crashlytics
- User files: may be stored in Amazon S3 via AWS Amplify; server-side access configuration could not be determined from the build

### What Stays on the Device

- WiFi network passwords: stored on the device for use in smart home device provisioning on the local network; no code path identified in the build routes these to remote servers, so they remain within the home environment
- Smart home command and automation data: the build includes a local network control path that operates on the home LAN using direct device-to-device communication

### Third-Party Data Sharing

**Third parties that may receive data from the app:**
- Google Firebase (Analytics, Crashlytics, Cloud Messaging) - Diagnostic events, crash reporting, and push notifications
- Amazon Web Services (Cognito, S3) - Cloud storage for user-generated content
- Google Maps - Mapping and location display features
- Google Play Billing - In-app purchase processing
- Google Sign-In - Account authentication option

## Understanding the Scores

**Security:** 73/100
**Privacy:** 83/100

### Security Breakdown

- **Data Security:** 74/100. The build includes two encryption utilities with fixed initialization vectors used in the WiFi password storage and device provisioning paths, reducing the protection strength of those operations. Account sign-in data is stored without encryption in device preferences, and verbose debug output is enabled in the production build.

- **Network Security:** 82/100. Cloud API communication appears to use HTTPS. The network security configuration permits cleartext HTTP across the board, covering both the local-network device provisioning path and external CDN content delivery. The Alexa and Google Smart Home OAuth callback path uses an HTTP scheme without app ownership verification rather than a verified HTTPS scheme.

- **Code Safety:** 82/100. The local device session protocol uses ephemeral key negotiation, providing forward secrecy for each control session. Three in-app content viewers in the build are configured with unrestricted cross-origin file access and JavaScript enabled alongside mixed HTTP/HTTPS content loading. An adversary who intercepts the CDN delivery path may be able to use these settings to read locally stored account data.

### Privacy Breakdown

- **Data Collection:** 86/100. The build links Firebase Analytics and Firebase Crashlytics, with the Meross account identifier included in diagnostic error event parameters. No advertising or behavioral-profiling SDKs were identified in the build.

- **Data Sharing:** 92/100. Identified data flows in this build target Meross's own infrastructure, Google Firebase services, and Amazon Web Services. The build contains no data-broker or advertising-network SDKs.

- **User Control:** 85/100. The build supports Google Sign-In and standard Meross account management. The in-app content viewers are configured to grant geolocation access to loaded web content without a visible user prompt, based on the code configuration reviewed.

## Positive Security Features

- The local device control session protocol uses ephemeral key negotiation, providing forward secrecy per session for communication between the phone and smart home devices
- The build contains no advertising networks, data brokers, or behavioral-profiling SDKs
- Identified data flows go to Meross's own servers and Google/Amazon infrastructure, with no third-party data-monetization services present in the build

## Areas for Improvement

### Disclosure observations

Observations about disclosure, each stated against published guidance so a reader can compare:

1. **Google Play Data Safety section**
   Google Play's Data Safety guidelines ask developers to declare which data types leave the device and for what purpose. The Data Safety section for this app, as retrieved on 2026-08-16, was empty. The build links Firebase Analytics and Crashlytics and includes the account identifier in diagnostic event parameters. Whether these data flows are declared could not be confirmed from the build alone; readers can compare the published Data Safety requirements against the store listing.

2. **Account identifier in diagnostic analytics events**
   Google Play's Data Safety guidelines ask developers to disclose when persistent identifiers are included in data shared with analytics services. The build includes the Meross account identifier in Firebase Analytics event parameters for two defined error conditions. Whether this practice is reflected in the app's store listing disclosures could not be determined from the build.

### Security Enhancements

1. **WiFi password encryption**
   Migrating from static initialization vectors to randomly generated per-operation values in the WiFi password storage and provisioning paths would strengthen the protection for those data flows.

2. **In-app content viewer file access**
   Disabling cross-origin file access in the in-app content viewers and scoping the cleartext HTTP permission to only the local-network device provisioning addresses would reduce the risk posed by a network adversary on the CDN delivery path.

3. **Backup configuration**
   Adding data-exclusion rules to the backup configuration would prevent account sign-in data stored in device preferences from being included in Android device backups by default.

4. **OAuth callback scheme**
   Migrating the Alexa and Google Smart Home OAuth callback links to HTTPS and enabling app ownership verification would ensure callback parameters are delivered only to the Meross app on Android 12 and later devices.

## Technical Context

**App Type:** Smart home controller and IoT device management
**Classes Analyzed:** 21,091
**Third-Party Services:** 22
**Context Tags:** smart_home, iot, location, sensitive_data

---

## 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 Android applications, intended to help people make informed decisions about app security and privacy.

### App Details

**Developer:** Meross Technology Co. Ltd.
**Version:** 3.41.1 (Build 1025)
**Analysis Date:** 2026-08-16
**Package:** com.meross.meross

### Analysis Limitations

- Static analysis only (code review without running the app)
- Based on APK version 3.41.1 analyzed on 2026-08-16
- May not reflect server-side security controls
- Cannot detect all runtime behaviors
