Kkomkkomi Privacy Policy

Effective date: October 7, 2026

Privacy officer and contact: Dongmin Yu (유동민), ydm2790@gmail.com

This policy explains what the Kkomkkomi app and its web report pages (kkomkkomi.web.app) keep, where they keep it, who can see it, and when it is deleted. It describes what the app and the server settings actually do.

1. What stays on the phone

The app keeps the following in its own database and folder on the phone.

The company name and optional business phone
Client names, and the names and order of their zones
Visit dates, and for each zone the before and after photos, the note, the source of each photo, any directly observed capture time, and the cleaning status (done, partly done, or not done) with its reason
The IDs of the pages it published, the state of its publish jobs, and the times when it recorded a page deletion request and confirmation

The business phone is not sent to the operator's servers. Directly observed capture times are not sent to the operator's servers either. The other data does not reach those servers until you share a report as a link. If the phone's backup is on (Android Auto Backup or iCloud Backup), the phone's operating system can back this data up to your own Google or Apple account. The operator cannot see that backup.

A PDF report is made on the phone and sent, through the system share sheet, to the app you choose. It is not sent to the operator's servers. A shared PDF file stays in the app's cache folder on Android and in its temporary folder on iPhone, until the system clears it or the app is uninstalled. The app also removes the information that section 3 describes from a photo before it puts the photo in a PDF. An entered business phone appears in the PDF, so its recipient can see it. Public web reports do not include the business phone.

A photo taken with the camera or selected from the gallery is first written as a file by the photo picker, into the app's cache folder on Android and into its temporary folder on iPhone, and the app keeps a copy of that file without the information that section 3 describes. The file in the cache or temporary folder can keep that information, and it stays until the system clears it or the app is uninstalled.

Uninstalling the app deletes the data on the phone. A copy in a backup stays in your account. Section 6 says how to delete the data from inside the app.

Gallery photos are labeled in the preview, PDF and web report. The app does not infer when a gallery photo was taken. Supported PNG input is converted to JPEG before it is saved; unsupported input is not saved.

If an in-app camera supplies a directly observed capture time, the app stores it locally in UTC and shows it in the current device local time in the preview and shared PDF. It is a device-clock observation and is not sent to the operator's servers. The current picker, gallery, recovered and old photos have no capture time; no time is inferred from file times or when a photo was selected.

When the app starts, it signs in to Firebase Authentication anonymously. It does not ask for a name, an email address, or a phone number. Firebase creates a random user ID, and that ID owns the pages published from the phone.

Firebase Authentication processes the IP address and the user agent (device and app information) of each sign-in, and keeps logged IP addresses for a few weeks.

The anonymous account is deleted when you delete all data in the app (section 6). If the account is lost in another way, for example when the app is uninstalled, you and the app can no longer change, close, or delete the pages and reports it published, and their links stay open until the operator closes them (section 7). The operator can close or delete those pages on request; section 12 says how to ask.

3. What a link share sends

When you tap "링크로 공유하기" (Share as link) on the visit report screen, the app uploads the visit to Firebase and then shares the link. Each client has one fixed page, and the page ID is 128 random bits. The upload holds the following.

Client page: the user ID, the company name (if saved), the client name, the time the page was created, and the time its link was closed (if closed)
Visit report: the visit date, the time the share was requested, and for each zone its name, its note, and the storage paths of its before and after photos, a mark for each photo selected from the gallery, and for a zone marked partly done or not done, that status and its reason. When the account holds a paid entitlement, the upload also holds a mark that the report goes without the line "꼼꼬미로 작성됨" (Made with Kkomkkomi), and anyone with the link can read that mark with the report.
Photos: JPEG files, at most 1,600 pixels on each side, at quality 80

The camera app writes information such as the time and the device model into a photo file, and, depending on its settings, the location. The app removes that information when it keeps a photo, and keeps what the photo needs to show correctly, such as its orientation and its color information. A photo that an earlier version of the app kept still holds that information in its file on the phone, but the app removes it before it uploads such a photo too. A photo file that an earlier version already uploaded keeps that information on the server, and uploading the same visit again does not replace it.

The app finishes the upload before it opens the share sheet. So the uploaded data stays on the server and opens through the link even if you close the share sheet without sending the link. A request that could not be uploaded without a network is tried again when the app opens again and when the network returns.

When a visit is uploaded again, its report is replaced, and photos that the report no longer names are deleted from the server.

4. Who can see it

Anyone who has the link can see the following without signing in, as long as the link is not closed.

The whole client page document, which includes the user ID. The web report page does not show the user ID, but anyone with the link can read the document directly.
Every visit report and photo published for that client. A person who got the link of one visit can open the list of the other reports of the same client.

A link is hard to guess, but it is not secret. Anyone it is forwarded to can open it. A person who comes in through a link cannot find or list the pages of other clients without their page IDs.

Opening a web report page sends a request to Firebase Hosting, and reading a report and its photos sends requests to Cloud Firestore and Cloud Storage, all of them Google's servers. Firebase Hosting keeps the IP address of each visitor for a few months. As the administrator of the Firebase project, the operator can access the data stored on the server.

5. Closing a link

In "Report link" on the client screen, you can close the link of that one client or replace it with a new link. These buttons show only while the client has an open link.

"Close Link" closes this client's current link. The next time you share a link, a new one is made.
"Make New Link" closes the current link and uploads its reports again under a new link. You send the new link by sharing it from a visit report.
Until the server has closed the link, the app says that it is closing the link, and the links you sent can still open. A request that could not reach the server for lack of a connection is tried again when the app opens again and when the connection returns.

These controls apply to the current link. A previous page with a deletion request but no confirmation is not used again by these controls, and its link may still open. The app keeps its warning and includes it in the confirmation dialog. Use "Delete All Data" in section 6 to finish deleting such pages.

To close every link you shared and delete the data on the server, use "Delete All Data" in section 6, or ask the operator at the contact in section 12. The operator tells you the result within 10 days of receiving the request.

When a link is closed, the app does the following.

It marks the page as closed. After that, nobody can open the page, its reports, or its photos through the link.
It deletes the photos that the app uploaded under the page. Cloud Storage keeps a deleted photo recoverable for 7 days, and then it is gone.
It does not delete the client page document or the report documents. The company name, the client name, the visit dates, the zone names, the notes, the status and the reason of each zone marked partly done or not done, and the user ID stay on the server. After the page is closed, the link cannot read them, and the operator can still access them. "Delete All Data" in section 6, or the operator, deletes these documents.

6. Deleting all data in the app

When you tap "Delete All Data" on the company profile screen and confirm, the app deletes the following, in this order.

The photo files that the app uploaded or started to upload (Cloud Storage), those of closed links included
The visit report documents, then the client page documents (Cloud Firestore), closed pages included
The anonymous account (Firebase Authentication)
The database on the phone (the company name, the clients, the zones, the visits, the notes, the cleaning statuses and their reasons, and the publish records) and the photo files in the app's folder

If a step fails, the app runs none of the steps after it, and the screen says which step failed. The app starts deleting data on the phone only after the server data and account are deleted. A device cleanup failure can occur after the database rows are already gone, while rewriting the database file, clearing its log, or deleting photo files. You can explicitly try again. The development and test builds have no server, so they delete only the data on the phone.

Before it starts to delete the data on the server, the app stops the report uploads and link closings that are still waiting. If the deletion stops halfway or the app starts again, a stopped report is not uploaded again, unless you tap Share link again.

Immediately before requesting deletion of each client page, the app records that request on the phone. It records confirmation only after the server acknowledges the deletion. A page with either record is not used for uploads or link closing again, including after restart. A request without confirmation does not prove the link is closed: the server may have deleted it even if its answer was lost, or deletion may have failed. The app does not automatically continue deleting all data after restart. Use "Delete All Data" again to finish.

If you explicitly share a visit again after a page deletion request, it uses a new link and uploads only that visit. Making or sharing a new link does not close a previous unconfirmed link. Its warning remains until deletion is confirmed. The next "Delete All Data" attempt also includes new pages recorded on this phone. These local records remain until the database erase commits; an account deletion failure preserves them, while a device cleanup failure can happen after they are gone.

After the deletion, the links you shared no longer open, and the app is as it was when first installed. The app signs in with a new anonymous account the next time it starts, shares a report as a link, or, in the release version, opens the plans screen or gets a tap on "Add Client" while 2 or more clients are not archived (section 2).

The following can remain after the deletion.

Deleted photo files: Cloud Storage keeps them recoverable for 7 days, and then they are gone.
The data of the deleted anonymous account: Firebase removes it from its live and backup systems within 180 days. IP addresses logged at sign-in are kept for a few weeks, and the IP addresses of web page visitors that Firebase Hosting logs, for a few months.
Pages and photos published before the app was reinstalled, or from another phone: the app on this phone does not know them, so it cannot delete them. Ask at the contact in section 12.
Rarely, a photo upload that the app cancelled because it took too long can still finish on the server, and that photo file can then remain.
The files that the photo picker and the PDF share left in the cache and temporary folders (section 1): they stay until the system clears them or the app is uninstalled.
A copy in a phone backup: it stays in your account.
The customer record at RevenueCat (sections 9 and 10): the app cannot delete it. Ask at the contact in section 12. A subscription bought in the store is not cancelled; you can cancel it in the subscription settings of the App Store or Google Play.
PDF files that recipients saved or forwarded, and photos and screens that they saved from a link

7. When the app is uninstalled

Uninstalling the app deletes the publish records on the phone, and the anonymous account can be lost with them, but the data on the server and the account are not deleted. Unless its data is restored from a backup, a reinstalled app does not know the pages it published before, and a new anonymous account cannot change, close, or delete the pages of the old one. So a link that was never closed stays open until the operator closes it, and it cannot be closed from the app. To delete the data on the server and the account too, use "Delete All Data" in section 6 before you uninstall the app. If the app is already uninstalled, ask the operator at the contact in section 12.

8. How long data is kept

Data on the phone: until you delete all data (section 6) or uninstall the app. The app has no control that deletes one client or one visit, and a client can only be archived from the list. A photo that is retaken has its old file deleted.
Client page documents and report documents: nothing deletes them automatically. They stay until you delete all data (section 6), or until the operator deletes them at your request.
Photos: until the link is closed, a new upload of the report drops them, you delete all data, or the operator deletes them, and then 7 days in a recoverable state
Anonymous accounts: until you delete all data. The data of a deleted account is removed from backups too within 180 days. IP addresses logged at sign-in are kept for a few weeks.
IP addresses logged by Firebase Hosting: a few months
The customer record at RevenueCat (the user ID and the purchase history): the app has no control that deletes it. It stays until the operator deletes it at RevenueCat at your request.

9. Where data is stored, processing by Google and RevenueCat, and transfer abroad

Firebase, which Google operates, processes the data on the server side. Cloud Firestore (page and report documents) and Cloud Storage (photos) are in the Seoul region (asia-northeast3). Firebase Authentication runs only from data centers in the United States, so anonymous account data is processed in the United States. Firebase Hosting runs on Google's global infrastructure, so the IP address of a visitor can be processed outside Korea.

The operator entrusts Google with the processing that the app and the web reports need, and discloses the items below on the transfer abroad in this policy, under Article 28-8(1)(3) of the Korean Personal Information Protection Act.

Data transferred: The user ID of the anonymous account, the IP address and user agent of each sign-in, the IP address of each request for a new sign-in token, and the IP address of each visitor of a web page
Countries: The United States (Firebase Authentication), and the countries of Google's data centers (Firebase Hosting)
When and how: Over the internet, when the app signs in (sections 2 and 6), when the app opens the screen of a visit report and asks for a new sign-in token, which tells whether the company has a paid plan, when the app uploads a report to share it as a link (section 3) and asks for a new sign-in token for the same reason, and when a web page is opened
Recipient: Google LLC. Contact: Firebase Support (firebase.google.com/support/troubleshooter/contact)
Purpose and retention: Sign-in and serving the pages. Retention is as in section 8.
How to refuse, and the effect: The app signs in when it starts, so there is currently no way to refuse this transfer while using the app. Not using the app avoids it.

The operator entrusts RevenueCat with the processing that checking, selling, and restoring subscriptions needs. RevenueCat stores the data it processes on Amazon Web Services in the United States. The items on the transfer abroad are below.

Data transferred: The user ID of the anonymous account (used as the RevenueCat app user ID), the purchase history of the store (the Apple receipt file or the Google purchase token), the device type and operating system, and the time the app was last used
Countries: The United States
When and how: Over the internet, when the release version of the app opens the plans screen, when "Add Client" is tapped while 2 or more clients are not archived, and when a subscription is bought or restored. After the first of these, the RevenueCat SDK also syncs the subscription state periodically and each time the app comes back to the foreground, until the app is closed completely.
Recipient: RevenueCat, Inc. Contact: compliance@revenuecat.com
Purpose and retention: Checking, selling, and restoring subscriptions, fraud prevention, and subscription statistics. Retention is as in section 8.
How to refuse, and the effect: Not opening the plans screen, not tapping "Add Client" while 2 or more clients are not archived, and not buying a subscription avoids this transfer. Delete All Data (section 6) does not contact RevenueCat. You can ask for the deletion of the transferred data at the contact in section 12.

10. Analytics, diagnostic data, location, and cookies

The app contains no analytics, crash reporting, or advertising tools that the operator uses. The Firebase SDKs inside the app (Authentication, Cloud Firestore, and Installations) declare in their own privacy manifests that they collect "other diagnostic data" for analytics, not linked to the user and not used for tracking. Google names the Firebase user agent (device, operating system version, and SDK versions) as such data that Firebase Authentication and Cloud Firestore send, and says that Google uses it to provide and improve Firebase services.
The App Store and Google Play process the payment of a subscription, and the app receives no payment details. The app uses the RevenueCat SDK to check, sell, and restore subscriptions. RevenueCat collects "purchase history", and because the app uses the user ID of the anonymous account as the RevenueCat app user ID, the purchase history is linked to that user ID. It is used for app functionality (checking subscriptions and preventing fraud) and for analytics (RevenueCat's customer records and statistics), and not for tracking. The development and test builds, and the app on platforms other than iOS and Android, send nothing to RevenueCat.
The app does not ask for location permission. It removes a location stored inside a photo file before an upload, as section 3 says. Sections 1 and 3 name the files that can still hold one.
This page and the web report page use no cookies.

11. What photos can show

Before and after photos can show people's faces, monitor screens, and documents. The app has no capture guide and no tool to hide part of a photo yet. Check what a photo shows before you upload it.

The cleaning company that takes and uploads the photos is responsible for the personal information of the people in them, as the party that processes it. The app operator provides the app and the servers that keep and show the photos.

12. Your rights and how to make a request

You can ask to see, correct, or delete your information, or to stop its processing. In the app, "Delete All Data" in section 6 deletes the data on the server and on the phone directly. For any other request, email the contact below. The anonymous account has no name or contact, so include something that finds the data, such as the link of a client page.

The operator lets you see the data, or tells you the result, within 10 days of receiving the request (Enforcement Decree of the Personal Information Protection Act, Article 41(4) and (5), Article 43(3), and Article 44(2)).

Privacy officer: Dongmin Yu (유동민), ydm2790@gmail.com