KitchenLocker Privacy Policy

HYPER C · Effective 4 October 2026

The short version. KitchenLocker works entirely on your device, with no account. If you sign in to sync between devices, the names of your locks, their combinations, the memo you write on a lock, your activity history and your backup codes are end-to-end encrypted before they leave your phone — we cannot read them. A lock's timer is not encrypted that way, because our service has to run it. Lock names stay sealed unless you choose to share them with an accountability partner. Usage reporting is off until you turn it on. We send crash reports to a server we run ourselves. If you invite an accountability partner, we store their email address and email them on your behalf. We do not show ads, and we do not sell or share your personal information for advertising.

This policy explains what data the KitchenLocker app ("the app") handles, what reaches HYPER C ("we", "us"), and what stays on your device. It applies to the app on iOS and Android, to the sync service behind it, and to the emails we send because of it. HYPER C is the name used by 임중혁 (Joong Hyuk Im), an individual developer based in the Republic of Korea; "we" and "us" mean 임중혁. Questions go to [email protected].

1. Data that stays on your device

The app is complete without an account. Everything it needs lives on your phone:

Your locks — names, memos, timers, settings, statistics, and the activity history, in a local database. A name and a memo are sealed before they sync, but both are kept here in readable form.
Combinations and backup codes — only in your device's secure keystore (iOS Keychain / Android Keystore), never in the regular database.
Your vault key and recovery code — if you sync. The key that seals your data stays in your device's secure keystore. The recovery code, which lets a new device into your vault, is kept where a reinstall or a replacement phone can find it: in the keychain on Apple devices, and in Google's Block Store on Android. If you use iCloud Keychain, Apple carries both to your other Apple devices. On Android the code is included in your phone's Google backup only when that backup is end-to-end encrypted, which requires a screen lock; otherwise it stays on the phone. Either way it is kept under your own Apple or Google account, and it never reaches our servers in a form we can read.
App settings — theme, notification preferences, and whether usage reporting is on.
Your answers to the terms — which version of the Terms of Service you accepted and when, and whether you turned usage reporting on, kept so you are not asked again.
Biometric app lock — if you enable Face ID, fingerprint or passcode protection, your operating system performs the check. The app receives a yes or a no; no biometric data is ever available to the app or to us.

Local notifications (timers ending, reminders) are generated on your device and need no connection.

2. What is end-to-end encrypted, and what is not

If you sign in, some of what syncs is sealed on your device with a key that only your devices hold. Our servers store and relay that ciphertext and have no key that opens it.

Sealed end-to-end: the name and category of each lock, combinations, the memo on each lock, the activity history, and backup codes.
Not sealed: each lock's timer and its status. These are stored on our servers in readable form because the service runs the timer, and so that they can be shown on your other devices, to your accountability partner, and in a monthly statement.

Lock names can be shared, if you choose. While names are sealed, your accountability partner and the emails we send them say only "a lock". If you turn off Encrypt lock names in Settings, a readable copy of every lock's name and category is stored on our servers, shown to your partner, and written into those emails. Turning the setting back on erases the readable copies from our servers; an email that has already been sent cannot be recalled.

A name and a memo are sealed before they sync, so we never see them — but both are kept in readable form on your own phone, so treat them as something anyone holding your unlocked phone could read. If you lose every device and every copy of your recovery code, the sealed data cannot be recovered by anyone, including us — that is what end-to-end means.

Signing in is optional. It exists so your locks can follow you between devices and so you can appoint a partner. You can sign in with Apple, with Google, or with an email address that receives a one-time code.

Account identity — a user ID from Apple or Google, your email address, and, from Google, an avatar image URL. We never receive a password; authentication happens with Apple or Google directly. Apple may give us a private relay address instead of your real one.
Sign-in codes — if you sign in by email, we keep a hashed copy of each code, together with the address it was sent to, the app or browser identifier, and a truncated network address, so codes can be limited and abuse spotted. Codes expire within minutes, and we delete the record an hour after a code expires.
Sessions — a hashed refresh token per signed-in device, the device name, the app identifier, and a truncated network address. We delete the record of a session 30 days after its refresh token expires.
Synced lock data — as described in section 2.
Device records — each installation registers a public key so the encryption key can be passed securely between your devices; new devices must be approved by an existing one or by your recovery code. We also store the recovery code itself, sealed with your vault key so that we cannot read it, which is how a connected device can show it to you again.
Your choice about lock names — whether you have turned Encrypt lock names off (section 2).
Push notification token — registered so the service can notify you, delivered through Firebase Cloud Messaging (Google).
Timezone and locale — used to count months in your local time and to address you.
Sync timestamps and server clock anchors — used to keep timers honest across devices.
Audit records — a log of significant actions on your account (sign-ins, deletions, partner changes) with a truncated network address, kept for security and to answer disputes.

Network addresses are truncated before they are stored, in our server logs as well as our database — to /24 for IPv4 and /48 for IPv6 — so what we keep identifies a neighbourhood, not a device.

4. Accountability partners

You may invite one person to be your accountability partner. To do that you give us their email address and, optionally, a name. We store that address and name even if the person never creates an account, so that we can send the invitation and know whom it was for. By entering someone's address you confirm that you are entitled to give it to us and that they are willing to hear from you through the app.

We email your partner on your behalf: the invitation, notices of your requests to open a lock early (including any reason you typed), notices when a backup code was used, and a monthly statement. These emails name a lock only if you share lock names (section 2); otherwise they say "a lock". Every one of those emails carries a way to stop receiving it, and a person who unsubscribes is not emailed again for that partnership.

A partner who accepts can see your locks' timers — and their names and categories only if you share them (section 2) — receives your unlock requests, and can approve or refuse them. A partner never sees a combination or a memo. We keep a record of each partnership and of each unlock request and its outcome. Either side can end a partnership from the app at any time.

When you accept the Terms of Service and answer the usage-reporting question, the app records which version you accepted, when, and what you answered. Once you are signed in, that record is sent to our servers and kept there, together with a truncated network address, as an append-only history. Turning usage reporting off later adds a new entry rather than erasing the earlier one. We keep this so that, if a question ever arises about what was agreed to and when, the answer exists. Nothing in the app reads it back.

6. Diagnostics and usage reporting

Crash and error reports — sent to an error-tracking server we run ourselves (GlitchTip, Sentry-compatible), not to a third party. A report contains the error, the app version, the device model and the OS version. Personally identifying fields and screenshots are disabled in the reporting client.
Usage reporting is off until you turn it on. The app uses Google Analytics for Firebase to count which screens are opened and how far people get through creating a lock. Collection is disabled in the app's build settings and stays off until you tick the box on the terms screen or the switch in Settings → Your data. When it is on, events are keyed to an anonymous app-instance identifier, never to your account, and never include a lock's name, its memo, a combination, or your email. Advertising-related consents are denied to the SDK whatever you choose. Turning reporting off also asks Google to delete the anonymous identifier, so earlier events are orphaned rather than kept waiting for the rest of a profile.
Remote configuration — the app downloads feature flags from Firebase Remote Config. That is a download, not a collection of your data.

7. Emails we send

We send email only because of something you or your partner did: a sign-in code, a partner invitation, unlock notices, monthly statements, and notices that an account deletion or a vault reset has been scheduled or completed. Mail is delivered by Amazon Simple Email Service, operated by Amazon Web Services in the United States. We keep a log of what was sent and to whom for 30 days, and a list of addresses that bounced or asked us to stop, so that we do not keep writing to them.

8. Purchases

KitchenLocker Pro is paid for entirely through the App Store or Google Play. We never receive your card number or billing details. The app asks the store, on your phone, whether a subscription is active and keeps the answer on your phone; our servers are not told. If you have turned usage reporting on, Google Analytics for Firebase may also record that a purchase happened, without linking it to your account.

9. What we don't do

We do not sell your personal information, share it for cross-context behavioral advertising, or show ads. The app carries no advertising SDK and does not request the advertising-identifier permission. We do not read your combinations, your memos, your activity history or your backup codes — we cannot — nor your lock names, unless you have chosen to share them. We do not collect your contacts, location, photos, or anything else outside what this policy lists.

10. Retention and deletion

On your device — deleting a lock moves it to a local bin for 30 days, then it is destroyed. You can empty the bin at any time. Uninstalling the app removes all local data, subject to your OS backup settings. The recovery code is the exception, by design: it stays in your Apple keychain or your phone's Google backup (section 1) so that a reinstall can find it, and it opens nothing once your account or your vault has been deleted.
Your account — you can delete it from inside the app (Settings → Privacy & data) or by asking us. Deletion has a grace period of 14 days, shown when you request it; signing back in before it ends cancels the request. After it, your account and everything synced to it are permanently removed from our servers. Partnership records and audit entries lose their link to you at the same time.
Vault reset — a device that cannot be approved may ask to reset your encrypted vault. The request waits 7 days and is announced by email; any of your connected devices can cancel it. If it runs, every sealed name, combination, memo and history entry is destroyed, and so are your monthly statements.
Lock names you shared — the readable copies are erased when you turn Encrypt lock names back on, and with your account when it is deleted.
Sign-in codes and sessions — codes expire within minutes, and their records are deleted an hour later; sessions end when you sign out, when a device is removed, or when the account is deleted, and their records are deleted 30 days after their refresh tokens expire.
Backups — our database is backed up on a schedule. Backups are encrypted before they leave our infrastructure and are kept on a rolling basis, so a deleted account persists in a backup for a limited time after deletion and then ages out.
Crash reports and usage events — kept only as long as needed for debugging and product decisions, then deleted according to the retention settings of our error tracker and of Firebase.

11. Legal bases

Where the GDPR or the UK GDPR applies, we process your data on these bases: performance of a contract for the account, sync, partner and notification features you asked for; legitimate interests for crash reporting, security, abuse prevention, and the audit and consent records; and consent for usage reporting and for anything else the law requires it for, such as push notification permission on your device. We process a partner's email address on the basis of our legitimate interest in delivering the feature you asked for, balanced by the fact that every message carries a way to stop. Where the Personal Information Protection Act of Korea applies, usage reporting is an optional consent item and refusing it does not limit the service.

We do not use your data for automated decision-making with legal effects.

12. Your rights

If you are in the EU, EEA or UK, you have the right to access, correct, delete and receive a copy of your personal data, to object to or restrict processing, and to withdraw consent at any time. You may also lodge a complaint with your local supervisory authority.

If you are a California resident, you have the right to know what personal information we collect, to delete it, to correct it, and to opt out of its sale or sharing. We do not sell or share personal information as defined by the CCPA/CPRA, and we do not discriminate against you for exercising your rights.

If you are in Korea, you have the rights the Personal Information Protection Act gives you to access, correct, delete and suspend the processing of your personal information, and to withdraw consent.

The fastest way to exercise most rights is in the app itself: usage reporting is a switch, and account deletion is built in. For anything else, including a copy of your data, email [email protected]; we respond within the timelines the applicable law requires. End-to-end encrypted content (lock names unless you share them, combinations, memos, activity history, backup codes) is unreadable to us, so a copy can cover it only as ciphertext.

13. International transfers

Our servers may be located outside your country, and two of our processors are in the United States: Amazon Web Services for email delivery and encrypted backups, and Google for push notifications, usage reporting and remote configuration. Where data protection law requires it, transfers rely on appropriate safeguards such as the European Commission's Standard Contractual Clauses or an adequacy decision. The Republic of Korea is covered by an EU adequacy decision.

14. Children

KitchenLocker accounts are for people aged 14 and over, or older where the law where you live sets a higher minimum age for consent to data processing. We do not knowingly collect personal data from children. If you believe a child has provided us data, contact us and we will delete it.

15. Security

Lock names, combinations, memos, activity history and backup codes are encrypted on your device before they sync. Everything travels over HTTPS. Tokens are stored hashed, network addresses are truncated before storage, and error tracking runs on our own server with identifying fields disabled. If you find a security problem, please tell us at [email protected] rather than publishing it; we would rather hear about it early and in private.

16. Processors and third parties

We use a small number of processors, each receiving only what its role requires:

Apple and Google — sign-in, and payments if we introduce them. Your device also keeps your recovery code in the keystore and backup they provide to you (section 1); that copy is held under your account with them and is not sent to us.
Google Firebase — push notifications, usage reporting (only if you turn it on) and remote configuration.
Amazon Web Services — email delivery, and encrypted storage of our backups.
Our own hosting — the sync service, its database, and the error-tracking server.

17. Changes to this policy

If we change this policy in a way that matters, we will update the date above and, for material changes affecting signed-in users, tell you in the app. Continued use after a change means the updated policy applies.

18. Contact

임중혁(HYPER C)
Privacy officer under the Personal Information Protection Act of Korea: 임중혁
[email protected] for anything about your data
[email protected] for security problems