M3LYAndroid Privacy

Android / Google Play Privacy Policy · private beta

Private by design. Minimal by default.

This policy applies specifically to the M3LY Android application, package me.m3ly.app, including distribution through Google Play. Last updated 2 September 2026. M3LY is currently an 18+ private beta.

1 · Operator and privacy contact

M3LY and Snooptsz Group LTD.

M3LY is being prepared for operation under Snooptsz Group LTD, with company formation in progress. Privacy correspondence: Office 20274, 182-184 High Street North, East Ham, London, E6 2JA, United Kingdom.

Day-to-day privacy responsibility is assigned to the Privacy & Compliance Officer (PCO), reporting directly to the Managing Director. Privacy questions and rights requests: hello@m3ly.me.

The current processing model is not assessed as requiring a statutory UK Data Protection Officer at this stage. That position is reviewed if the scale or nature of processing changes.

2 · What the Android app processes

Only data required to authenticate, connect, secure and operate M3LY.

Depending on the account and features used, M3LY may process a pseudonymous M3LY handle/principal, Human/AI Agent/Bot/Robot actor class, findability preference, public passkey/WebAuthn credential material, protected compatibility-credential verifiers, recovery-method state, session references, device references, Android pairing state, machine ownership/claim state, temporary-account expiry state, entitlement status, limited authentication/security events and infrastructure connection metadata.

M3LY does not require a real-world name, phone number or email address as the native account identity. Required pseudonymous account/device/session references are service-security identifiers and are not used as advertising or cross-service tracking IDs.

3 · Passkeys, secrets and recovery

Private authentication secrets remain private.

For passkeys, M3LY stores only the public WebAuthn credential material needed to verify authentication. The private passkey key remains with the user's authenticator and is not sent to M3LY.

If a persistent Human chooses an optional password, passcode, recovery passphrase or recovery code, M3LY processes the submitted value only to create or verify the protected verifier required for the selected method. Plaintext secrets are not intended to be retained after that operation.

M3LY may be unable to recover an account when all valid passkeys, recovery methods and authorised devices are lost. M3LY does not weaken another user's security to recover an account.

4 · Android permissions

Permissions are used only for the feature that needs them.

The currently qualified Android source requests only Internet access. It does not currently request Contacts, Location, Camera, Microphone, SMS or Call Log permissions.

M3LY is developing additional connection technologies. A later qualified build may request Bluetooth, Bluetooth Low Energy, Nearby Devices, NFC, nearby Wi-Fi, Wi-Fi Direct/Wi-Fi Aware, local-network, location-related discovery, camera/QR, microphone/voice, radio or accessory permissions where required for a user-visible connection or development capability.

These permissions are not intended to identify users, build behavioural profiles, create advertising IDs, create location history or track people across unrelated services. Bluetooth, NFC, nearby-device, Wi-Fi and location-related discovery information is intended to be used transiently for discovery, routing, pairing, transport selection or the specific feature requested by the user and is not retained as an identity/location history unless a separate disclosed security or user-requested function genuinely requires bounded retention.

5 · Local storage and Android security

Device state stays constrained.

Android backup is disabled for the current M3LY build. Device credentials use protected no-backup application storage. The current packaged WebView surface is designed to remain isolated and cookie-free for the local application bundle. M3LY does not currently include an advertising SDK or behavioural-analytics SDK in the qualified Android source.

6 · Messages, voice and transport capability

No plaintext fallback.

Production private messaging is not represented as available until M3LY's E2EE qualification gate is satisfied. M3LY will not silently fall back to plaintext merely to make a communication feature appear available.

Voice, Bluetooth/Nearby, peer Wi-Fi, NFC, radio/accessory routes and external reach remain disabled or unqualified unless a later build explicitly qualifies them. When enabled, any materially new data processing or Android permission will be reflected in this policy and the applicable Google Play disclosure.

7 · Network and security metadata

Minimum operational metadata, not behavioural history.

Internet communication necessarily exposes limited technical information such as IP address, connection timing, protocol/routing details and security events to the infrastructure required to deliver and protect the service. M3LY uses such information only for service delivery, authentication, rate limiting, abuse prevention, fraud/scam/phishing protection, troubleshooting and security.

Routine authentication-attempt telemetry is currently bounded to a maximum of 24 hours. It is not converted into an indefinite behavioural history.

8 · Aurora, reports and abuse prevention

Security processing is purpose-limited.

Aurora is M3LY's security and anti-abuse layer. It may process limited pseudonymous account/device references, rate/security signals, abuse reports and known malicious indicators necessary to prevent spam, scams, phishing, fraud, account compromise and service abuse.

If a specific spam, scam, fraud, abuse or security incident is reported or detected, M3LY may retain the minimum evidence necessary for investigation, repeat-abuse prevention, legal claims, compliance or a lawful report to competent authorities. Any extended hold must be case-specific and have a documented reason and review/closure trigger.

Ordinary user data is not retained longer merely because it might be useful later.

9 · Retention

Short-lived data expires and is purged.

Current technical controls use: WebAuthn challenges up to 5 minutes; Android pairing proofs up to 10 minutes; Machine claim proofs up to 10 minutes; normal Web sessions up to 30 days unless shorter or revoked; temporary identities exactly 1 hour or 24 hours; and routine authentication-attempt telemetry up to 24 hours.

An automated privacy purge runs hourly against eligible expired/used technical records. Account-linked data is removed following verified account deletion, subject only to narrowly documented security, fraud, legal, accounting or statutory retention requirements.

10 · Account deletion

Deletion is distinct from a security freeze.

Users can start account deletion from M3LY Settings or at https://m3ly.me/account-deletion.html. M3LY verifies account control before destructive deletion. A security freeze is not represented as account deletion.

M3LY deletes or irreversibly de-identifies account-linked information that no longer has a valid purpose, except for the minimum information subject to a specific lawful/security retention obligation.

11 · Service providers

Infrastructure is limited to M3LY operation and protection.

Supabase provides the dedicated M3LY backend/database and Edge Function infrastructure; the current project is configured in the London eu-west-2 region. Cloudflare provides current edge/security delivery functions and may process request, routing, TLS, IP and security metadata required to deliver and protect M3LY.

M3LY also maintains an owner-designated backup layer referred to internally as BB; it is restricted to the approved minimal backup scope and is subject to processor, encryption, location, DPA and retention review before any material production-personal-data expansion.

Google Play processes Android app distribution and, where used, payment/account information under Google's own terms and privacy practices. M3LY receives only the minimum purchase/entitlement information needed to provide paid functionality and comply with accounting/legal obligations, not full payment-card credentials.

12 · Payments

Store billing is separated from private communications.

Where paid digital features are sold through the Google Play-distributed Android app, Google Play Billing is used unless an applicable Google programme, platform rule or law permits another compliant route. M3LY does not need to receive full card credentials from Google Play.

Crypto or other payment methods may be introduced on eligible channels later. They are not represented as active Android in-app payment methods unless separately reviewed for legal, privacy, security and Google Play compliance.

13 · Legal bases and user rights

Service delivery, security and lawful operation.

Where UK GDPR or EU GDPR applies, processing may rely on performance of the requested service or pre-contract steps, legitimate interests in security and abuse prevention, legal obligations and consent where an optional activity legally requires consent. M3LY does not sell personal data and does not use personal data for behavioural advertising.

Depending on jurisdiction, users may have rights to access, correct, delete or obtain a copy of personal data; restrict or object to certain processing; withdraw consent where applicable; and complain to a competent regulator. Requests may be sent to hello@m3ly.me. Proportionate proof of control of the relevant pseudonymous M3LY account may be required.

14 · Children

18+ private beta.

The current M3LY private beta is intended for people aged 18 or over and is not currently designed for children.

15 · Changes

The policy follows the actual Android build.

This Android Privacy Policy is reviewed whenever M3LY changes Android permissions, SDKs, processors, transports, messaging, payments or material data flows. The Google Play Data Safety declaration must remain consistent with the exact Android build distributed to users.