Privacy Policy

Last updated: 5 October 2026 · Version 1.0

Lights On turns one phone, or a room full of phones, into a synchronised light show set to music. This policy explains what the Android and iPhone apps (both com.nurzel.lightson) and the services behind them do with your data. Unless a section says otherwise, it applies to both. It is written for the app as it ships today, not for features we might add later.

The short version

There is no sign-up: no email, no password, no social login.
The app creates an anonymous technical ID so rooms and your Pro subscription can work. It is not your name, but it is not anonymous data either.
Usage analytics and crash reports are switched off until you allow them, and refusing them does not limit any feature.
When you host or join a party, your nickname, the room code, the party message and playback timing go through our servers so the phones can stay in sync.
There are no ads, no advertising ID, no location, no microphone, no access to your photos or contacts.
Payments are handled by Google Play or Apple's App Store. We never see your card details.

1. Who we are

Lights On is published by Nurullah Sevinçkan, an independent developer, who is the data controller for the processing described here. You can reach us at lightson@memolang.org for any privacy question, for a data deletion request, or for general support. We will give our postal address on request.

Reading this policy is not consent. Where the law requires your consent for something, we ask for it separately inside the app.

2. Using Lights On without an account

The app has no registration form. When you first open it, it signs in anonymously to Firebase Authentication and receives a technical user ID. That ID is what lets the service know which phone opened a room, which phones are in it, and which device a Pro subscription belongs to.

"Anonymous" here means we do not know your name. It does not mean the records cannot be linked to each other: everything described below is stored against that ID. If you uninstall the app, clear its data or switch phones, you will usually get a new ID — and records created under the old one are not deleted automatically. You can ask us to delete them (see section 10).

3. What we process and why

We get data from what you type into the app, from what your device produces while a show is running, from Google and Firebase services, and from purchase notifications sent by the store and RevenueCat.

Activity	Data	Why
Technical session	Anonymous Firebase user ID, session tokens; the IP address and device/app client information our providers see when the app connects	To open a session, authorise requests and protect the service from abuse.
Hosting and joining rooms	Room code, nickname, host and participant IDs, join and connection times; the PIN you type, which the server checks against a salted hash it stores	To create the room you asked for, verify who may join, show the participant list and manage the room. Other participants are never shown the PIN or its hash.
Keeping the show in sync	Selected track and visual, playback state and start times, device role and readiness, clock-offset and latency measurements, audio output corrections, show error counters	To start the same show on every phone at the same moment and to recover from connection problems. These technical records are created whether or not you allowed analytics.
Room content	Your nickname and the short party message the host writes	To display them on the phones in the room. Anything you type here can be seen by the others, so do not put personal or sensitive information in it.
Room history and limits	Room code, host and participant IDs, opening and closing time and reason; the state of a room-creation request and your daily room quota	To apply the daily limit, to make repeated requests safe (so one tap never creates two rooms), and to keep a summary of which devices took part in which room. This summary is kept even if you turned analytics off — see section 9.
Pro subscription	Technical user ID, purchased product, store, subscription status and expiry, renewal and restore records exchanged between the store (Google Play or the App Store) and RevenueCat	To verify the purchase, unlock and maintain Pro, restore purchases and handle support. Card numbers and security codes are never entered into or seen by the app.
Optional usage analytics	Screen and feature interactions, chosen track and visual, room and show events, durations, sync quality values, paywall interactions, plus the app-instance identifiers and technical data the SDK adds	Google Analytics for Firebase, to understand how the app is used and improve it. Only after you allow it.
Optional crash reports	Crash and error traces, device model, OS and app version, installation identifiers, and the breadcrumb log leading up to the failure	Firebase Crashlytics, to find and fix crashes. Automatic sending only after you allow it.
Settings on your device	Nickname, last played track, language, light/torch/vibration settings, calibration, selected visual, onboarding and safety-warning acknowledgements, notification preference, and your analytics decision with its timestamp	To remember your preferences. These stay on the phone; the nickname and some show settings are also sent to the server while you are in a room.
Support and rights requests	The email you send us and whatever you include in it	To answer you and to act on your request. Please do not send passwords, full card numbers or identity documents we did not ask for.

If the technical ID, nickname or PIN cannot be processed, you cannot join a room; if purchase data cannot be processed, Pro cannot be verified or restored. That is different from the optional analytics: refusing those does not block any feature.

4. Why we are allowed to process this

We do not treat one blanket consent as permission for everything. Depending on what we are doing, we rely on:

Doing what you asked for — the session, rooms, synchronised playback and your subscription cannot work without the data in section 3;
Keeping the service secure and reliable — stopping PIN guessing and quota abuse, making repeated requests safe, and defending legal claims. You can object to processing we do on this ground;
Obligations we genuinely have — records we must keep for accounting, or must produce to a competent authority;
Your consent — used for the optional analytics and crash reports, and for nothing else. You can withdraw it.

These grounds have different names depending on where you live — "legal bases" under the GDPR and UK GDPR in Europe, processing conditions under the KVKK in Türkiye, and their equivalents elsewhere — but the split is the same everywhere: the optional analytics run on your consent, and the rest of the service does not.

5. Your analytics and crash-report choice

The app asks once whether usage statistics and crash reports may be sent to Google Firebase. Until you answer, automatic sending of both Google Analytics and Crashlytics data is off. Saying no does not limit any free or paid feature, and we do not ask again to unlock anything.

One detail worth being precise about: while automatic sending is off, Crashlytics can still write a report on your device. If you later turn sending on, reports that were waiting may be sent. When you decline, the app asks Crashlytics to delete unsent reports — which is not the same as deleting reports already received by Google.

You can change your answer. The app asks the question once, so today there are two ways to do it: write to lightson@memolang.org and we will act on your withdrawal, or clear the app's data on your phone (on iPhone: delete and reinstall the app), which resets the question to unanswered and therefore switches collection back off. Withdrawing consent stops further consent-based processing; it does not retroactively make earlier processing unlawful, and it does not by itself erase data already collected. To have that data erased, make a deletion request (section 10).

6. Permissions and what happens on your device

Camera — used only to control the camera flash (torch) during a show. The app does not take photos or video and does not upload images. If camera access is refused, the torch part of a show cannot run.
Vibration — haptic pulses in time with the show.
Notifications — the Android app can ask for notification permission, but this version does not send remote notifications and does not collect a push token. The iPhone app does not ask for notification permission.
Internet and network state — sessions, rooms, subscription checks, permitted reports and time synchronisation.
Time synchronisation — to start a show on every phone at the same millisecond, the app queries the public time service time.google.com over SNTP. That service sees your IP address and the time request; the app puts no room data, message or user ID into it.
Music — the tracks ship inside the app and play from your device. There is no microphone access and no recording of any kind.

The app does not request location, contacts or photo library access. It shows no ads and the ad-related analytics settings are disabled. On Android, the advertising ID permissions are explicitly removed from the app. On iPhone, the app does not use the advertising identifier (IDFA), never asks to track you across other companies' apps and websites, and the analytics SDK is told not to collect the vendor identifier (IDFV).

Settings stored on your phone may be included in the operating system's own backup or device-transfer features — Android backup, or iCloud and computer backups on iPhone — depending on your device settings. "Stored on your device" does not mean "excluded from operating-system backups".

7. Who can see your data

Other people in the party. Nicknames, the party message and show and participation information are what a shared room is made of, so everyone in the room sees them. Treat the room code and PIN like a password: anyone you give them to can join, and anyone in the room can write down or screenshot what they see. Do not put private information in a nickname or a party message.

Service providers. Google and Firebase provide authentication, the realtime database, server functions and crash reporting; Google Analytics handles the optional usage analytics; RevenueCat manages subscription entitlements; Google Play or Apple's App Store processes the payment and the store account under its own terms. Each of them processes data under its own agreement and role; we do not lump them together under a single label.

Authorities and advisers. Where a genuine legal obligation or the defence of a legal claim requires it, we may disclose the minimum necessary information to competent authorities or professional advisers. If the app or the service is ever transferred to someone else, we will provide the required information and a lawful basis for that transfer; a transfer does not create a free pass to use your data for new purposes.

8. Where your data is processed

Our providers are global. Depending on the service, your data is processed in the European Union, the United States and other countries where Google, Apple and RevenueCat operate — so it will usually leave the country you are in. Even when one server component runs in a European region, it does not follow that identity, analytics, subscription and support records all stay in the same place.

For those transfers we rely on the safeguards our providers make available, such as adequacy decisions and standard contractual clauses, and on the equivalent mechanism required by the data protection law that applies to you. Write to lightson@memolang.org if you want details of the safeguards that apply to a specific provider. Allowing analytics is not a general consent to transfers.

9. How long we keep things

Record	Kept
Anonymous user ID and the user, entitlement and quota records attached to it	While the app is in use, and afterwards until the record is no longer needed or you ask us to delete it.
Live room: nickname, party message, participant state, PIN hash, sync and connection data	A room's lifetime is about ten minutes; scheduled server cleanup removes the live records after it closes or expires.
Room history summary: room code, host and participant IDs, open/close times	90 days after the room closes. This is kept regardless of your analytics choice, because it is how repeated requests, quotas and abuse handling stay reliable.
Room-creation requests and the records that prevent double processing	Short term, for the reliability of that operation; the daily room quota resets each day (UTC).
Subscription, purchase verification and store notifications	While the subscription is active and afterwards for as long as we need them for support, disputes and any accounting obligation that applies.
Google Analytics user and event data	According to the retention period set on our Analytics property (Google's default is 2 months; the maximum for a standard property is 14 months). Aggregated reports can outlive the underlying records.
Crashlytics crash reports	Around 90 days in the Firebase console.
Support and rights-request emails	While we handle the request and afterwards only as long as needed to show we handled it properly.
Settings on your phone	Until you clear the app's data or uninstall it.

Deletion runs on schedules and in backups, so a retention period is the point at which deletion starts, not a guarantee that every copy disappears in the same second.

10. Your rights

Wherever you live, you can ask us to:

tell you whether we hold data about you, what we do with it and who receives it, and give you a copy;
correct it if it is wrong;
delete it, or hand it to you in a portable form;
stop or limit a particular use — including objecting to the processing we do to keep the service secure and reliable;
withdraw a consent you gave, and tell the recipients about a correction or deletion.

These rights come from the law that applies where you live — the GDPR or UK GDPR in Europe, the KVKK in Türkiye, and comparable laws elsewhere — so their exact scope can differ. You can also complain to your local data protection authority.

Send requests to lightson@memolang.org. Because the app has no login, we may need to ask for details that let us match the request to the right records — for example the code and approximate time of a party you hosted, or the Google Play order number or App Store order ID for purchase records. A nickname alone is not enough, since anyone can type any nickname. We will not ask for more identification than the request needs, and if we genuinely cannot link the records to you, we will tell you so instead of guessing.

We answer within 30 days. If we need longer, or cannot do what you asked, we will tell you why and what you can do next.

Two things that surprise people: uninstalling the app is not a deletion request, and a deletion request does not cancel a subscription. Cancel it separately in the store you bought it from: Google Play, or on iPhone the subscription settings of your Apple Account.

11. Children

Lights On is not directed to children under 13, and we do not knowingly process their data. If you believe a child under 13 has used the app and provided data, write to lightson@memolang.org and we will look into it and delete what we find. Where local law sets a higher age for consent to data processing, parental consent must be obtained for users below that age.

12. Security

Connections use transport encryption, room PINs are stored only as salted hashes, access to room data is controlled by server rules and authorisation checks, and wrong-PIN attempts are rate limited. Lights On is not an end-to-end encrypted messenger and no system can promise absolute security. If a personal data breach occurs, we will meet the notification duties that apply to us.

13. Changes to this policy

The current version always lives on this page, with the date and version number at the top. If a change is significant, we will announce it before the new processing starts, and if a new purpose needs consent, we will ask for it separately. Updating this text does not extend an old consent to new processing.