Privacy at a glance

Data Safety and Store Disclosures

Reviewed against the app code: July 3, 2026

This page summarizes Block battle's data handling and provides a working disclosure matrix for Google Play Data safety and Apple App Privacy. The full explanation is in the Privacy Policy.

Collected

Account, profile, gameplay, security, and optional notification data.

Not sold

No advertising SDK, sale of data, or cross-app advertising tracking.

Deletion available

In-app deletion with a seven-day recovery period, plus a web request path.

1. Public data safety summary

Information	Examples in Block battle	Why it is used	Choice
Account identity	Email, username, display name, account and profile IDs, social-login ID	Account creation, sign-in, verification, and account support	Optional
Public profile	Nickname, selected country, locale, built-in avatar, biography, links, rating	Profiles, multiplayer identity, leaderboards, and personalization	Partly optional
Gameplay	Lobby status, match participants, game state, results, duration, line counts	Real-time play, rankings, statistics, and recent match history	Optional online play
Security metadata	IP address, user agent, session timestamps, hashed credentials and tokens	Authentication, fraud prevention, service security, and abuse response	Required online
Device identifier	Firebase installation and push-messaging token, platform	Match-related push notifications	Optional
Safety reports	Reason, free-form details, involved player IDs, IP address, user agent	Moderation, fair play, abuse investigation, and player safety	Optional

“Optional” means a player can use solo gameplay without creating an account or can decline the feature. Some information becomes necessary after the player chooses an online account, multiplayer, reporting, or notifications.

2. Google Play Data safety worksheet

This is a store-console worksheet, not a substitute for completing the Data safety form in Play Console. It reflects the current repository and assumes production releases use HTTPS/WSS and that Facebook and X sign-in remain disabled. Recheck every enabled SDK and production build before submission.

Top-level answers

Play Console question	Draft answer	Basis
Does the app collect or share required user data types?	Yes	Online account and multiplayer data leave the device and are retained.
Is all collected user data encrypted in transit?	Yes	Production API and WebSocket endpoints must use HTTPS and WSS. Verify the final artifact.
Can users request deletion?	Yes	In-app path and web request page.
Does the app contain ads?	No	No ad SDK or ad feature is present in the reviewed code.
Independent security review completed?	No	Do not claim this badge without an eligible independent assessment.
Families Policy commitment?	Not claimed	Only claim after target-audience review and full Families Policy compliance.

Data types to select

Google Play type	Collected	Shared	Required / optional	Purposes to select
Personal info → Name	Yes	No*	Optional	App functionality; Account management
Personal info → Email address	Yes	No*	Optional	App functionality; Fraud prevention, security, and compliance; Account management
Personal info → User IDs	Yes	No*	Optional	App functionality; Fraud prevention, security, and compliance; Account management
Personal info → Other info	Yes	No*	Optional	App functionality; Account management
App activity → Other user-generated content	Yes	No*	Optional	App functionality; Fraud prevention, security, and compliance; Account management
App activity → Other actions	Yes	No*	Optional	App functionality; Fraud prevention, security, and compliance
Device or other IDs → Device or other IDs	Yes	No*	Optional	App functionality; Developer communications; Fraud prevention, security, and compliance

* Drafted as “not shared” because hosting, email, Firebase Authentication, and FCM are used as service providers, while public profiles and selected social login are user-initiated transfers the player reasonably expects. Google excludes those transfers from “sharing” when its conditions are met. If an enabled SDK uses data for its own advertising or unrelated purposes, change the relevant rows to “shared.”

Mark these data types as not processed only ephemerally because at least some data in each selected category is retained. The app can be used without sign-in, so the online data collection is drafted as optional under Google's definition.

3. Apple App Privacy worksheet

In App Store Connect, answer that the app collects data. The following types should be disclosed as linked to the user, used for App Functionality, and not used for tracking:

Apple data type	Block battle data	Linked	Tracking	Purpose
Contact Info → Name	Display name or nickname received during account setup or social sign-in	Yes	No	App Functionality
Contact Info → Email Address	Account email and verification address	Yes	No	App Functionality
Identifiers → User ID	Username, user ID, profile ID, provider identity	Yes	No	App Functionality
Identifiers → Device ID	Firebase installation and messaging identifiers used for push delivery	Yes	No	App Functionality
User Content → Gameplay Content	Multiplayer matching, game state, results, rating, and match history	Yes	No	App Functionality
User Content → Other User Content	Biography, profile links, room choices, and player-report details	Yes	No	App Functionality
Other Data → Other Data Types	Selected country and locale, IP address, user agent, and account security metadata	Yes	No	App Functionality

Set the required Privacy Policy URL to privacy.html on the deployed domain. The optional User Privacy Choices URL can point to account-deletion.html. Review the privacy manifests and disclosures of every SDK in the archived iOS build before publishing this label.

4. Data not collected by the reviewed app

The current code does not collect:

precise or approximate device location;
phone number, physical address, contacts, calendar, SMS, call logs, or installed-app list;
health, fitness, biometric, or other sensitive personal categories;
payment information, purchase history, or financial information;
user photos, videos, audio recordings, or files (profile avatars are built-in game assets);
advertising data or data for cross-app tracking; Block battle does not intentionally use an advertising identifier;
analytics, crash logs, or performance telemetry through an analytics or crash-reporting SDK.

These statements must be updated before enabling a new permission, SDK, custom avatar upload, analytics, advertising, payments, or another data-collecting feature. Social SDK defaults must also be checked in the final native build even when their sign-in buttons are disabled.

5. Service providers and recipients

Google Firebase: authentication and Cloud Messaging, including installation and push-delivery identifiers.
Google Sign-In: user-initiated account authentication.
Facebook or X: only if the respective optional sign-in provider is enabled and selected by the user.
Infrastructure providers: production hosting, database, network delivery, backups, security, and email delivery.
Other players: public profile, leaderboard, lobby, and multiplayer information needed for the game.

Provider processing is described more fully in the Privacy Policy disclosure section.

6. Required release checks

Deploy these pages over HTTPS and replace relative filenames in the store consoles with public absolute URLs.
Confirm block-battle-feedback@proton.me is monitored and the developer/operator identity matches the store listing.
Verify the final Android and iOS artifacts use only HTTPS/WSS endpoints and do not include an unexpected analytics, ads, diagnostics, or social SDK configuration.
Test in-app deletion end to end and test the web/email request procedure.
Review Firebase, Google Sign-In, and every enabled provider's current store disclosure guidance.
Update the Privacy Policy and both store forms whenever data handling changes.

Official references: Google Play Data safety, Google Play account deletion, Apple App Privacy details, and Apple account deletion.