Privacy Policy — Re:Fill

Effective date: 2026-09-10 Last updated: 2026-09-24

This Privacy Policy explains how Jansevt Labs (“we”, “us”, “our”), a sole-trader business in the Republic of Korea, handles information in connection with the mobile application Re:Fill (the “App”). The operator and Privacy Officer are identified in Section 15, item 11. It covers the App on Android (Google Play) and iOS (Apple App Store), including pre-release testing as well as publicly released versions.

This version applies to processing on or after the effective date above, including processing of information we already hold on that date. It does not apply retroactively to earlier processing.

---

1. Summary (the short version)

• Your data lives on your device by default. The medication and supplement information you enter is stored locally on your phone. It is not sent to us automatically.

• Cloud backup is optional and user‑initiated. The App sends the backup contents in Section 2.3 to cloud storage managed by us when you sign in and request a backup. You can also export or share PDF/Excel files yourself; data may leave your device depending on the destination you choose. In the current App, deleting the stored cloud copy requires deleting the cloud account; there is no separate backup‑off / stored‑copy deletion control.

• We do not run a general‑purpose product analytics SDK and we do not configure the App to track you across other apps or websites. AdMob/UMP still process the limited advertising and privacy-status data described below.

• Every user follows the same age-protective advertising route. We do not ask for or infer age. After the seven-day no-ads period, the App marks UMP as under age of consent, configures Mobile Ads as child-directed with a G content ceiling before initialization, and marks every ad request non-personalized and restricted-data-processing. We do not use the Android advertising ID, show an iOS App Tracking Transparency prompt, or read your IDFA. Google excludes child-directed requests from third-party real-time bidding. Google still processes the advertising and privacy-status information described below; the bidding restriction is not a promise of no data processing.

• Crash reporting is off by default. New crash reports are sent only if you turn it on. We do not intentionally attach medication records and use redaction controls, but no redactor can guarantee that every future error message is free of user‑entered sensitive text.

• We never receive your payment‑card or billing details. Apple or Google handles payment; we receive the transaction identifier and entitlement status described in Section 2.4.

The rest of this policy gives the full detail required by law (including Korea’s PIPA, the EU/UK GDPR, and California’s CCPA/CPRA).

---

2. Information we collect — and information we do not

2.1 Information you enter into the App (stored locally by default)

When you use the App you may create entries that can include:

• Medication or supplement names, quantity on hand, dosage amount, and unit;

• Dose schedules (the times of day you plan to take an item) and optional schedule labels;

• Intake records — when a dose was taken, skipped, or missed, with timestamps;

• Free‑text notes / memos you write;

• Categories and display preferences (colors, sort order);

• App settings (e.g., language, time format, reminder preferences).

This information may reveal health‑related information about you (see Section 6). By default, all of it is stored only on your device in a local database and is not transmitted to us or to any third party. It leaves your device only through the optional features described below (cloud backup, or files you choose to export and share yourself).

2.2 Account and account-security information

We use Google sign-in (Android) or Apple sign-in (iOS) for optional cloud backup and data restoration. Google's Firebase Authentication processes your email address (a relay address if you use Apple's Hide My Email), display name where supplied, and a user identifier linking your account to backups. A Re:Fill account is not required to purchase or restore “Remove Ads.” Older app versions associated purchase records with a Re:Fill account; those existing records remain subject to the retention and deletion rules below.

We also use necessary account-security and deletion-processing records. These include the Apple user identifier, notification type and event time, and a hash we derive from the notification identifier; the corresponding Re:Fill account identifier, linked sign-in providers, account creation/last-sign-in times where needed; and access restrictions, deletion requests, outcomes, retry and review information. We check account status through Firebase Authentication and handle necessary processing records in Google Cloud Firestore/Functions. See Sections 7, 8 and 15 for recipients and processing locations.

We do not separately retain raw notifications, sign-in tokens, relay email addresses or medication content in these account-change notification records. Residual-backup cleanup checks necessary account identifiers and file paths/versions without opening backup-file contents. These records are not anonymous. Sections 9 and 10 describe their use and retention.

To remove backups left after an individual Re:Fill account is deleted, Firebase Authentication sends an account-deletion event to our server. It can include the user identifier and existing account and sign-in-provider information, such as an email address, display name and account metadata where present. Our cleanup function uses only the user identifier from this event and does not create a separate event archive. Section 10 explains the cleanup and retry limits.

When you request account deletion on iOS, a temporary deletion-protection record may be created in Firebase/Firestore. It contains your Re:Fill account identifier, Apple developer-specific identifier, authentication time, and limited protection/update/expiry timestamps. It helps the deletion request continue if an Apple connection-revocation notification arrives first, and restricts other requests from recreating account records during deletion. This protection record contains no medication or backup contents, password, or Apple token. Section 9 describes Apple account-change handling, and Section 10 distinguishes this limited deletion permission from record retention.

2.3 Cloud backup contents (only if you enable backup)

If you request a cloud backup, the App uploads your medication/supplement items, dose schedules, dose records, per-item settings and categories to cloud storage managed by us (Google Cloud / Firebase, primarily in Seoul) so you can restore them later or on another device. App-wide settings such as language, time format and notification preferences, and consent records stored on your device, are not included in the backup. The App also stores the backup date, app/database-schema/backup-format versions, device platform, data size, per-group counts and SHA-256 integrity value. It does not copy the entire App database.

Backups are user‑initiated; the current App does not provide a separate always‑on backup switch. See Sections 7, 8, 10 and 12 for where copies are stored, how they are protected, retained, and deleted.

For deletion and account security, Google delivers upload-completion events from the backup storage. These events can include the storage location, object name, file-version identifier, timestamps and other object metadata, including custom or access-related metadata where present. Our cleanup function uses the location, object name and exact file version to check whether the linked account still exists and, if it does not, request deletion of that version. It does not read the backup file's contents or create a separate event archive. The processing and retention limits are explained in Section 10.

2.4 Purchase information

The App supports a single optional purchase, “Remove Ads.” Payment is processed entirely by Apple or Google; we never receive or store your payment-card or billing information. To verify a purchase or restoration, the App sends its store, product identifier and purchase evidence (a Google Play purchase token or an Apple signed transaction) to our verification service in Google Cloud / Firebase. We check it with the relevant store and refund records. App attestation protects this service. New verification requests do not send a Re:Fill sign-in token or create an account-linked entitlement record. The device keeps a small store-specific record of verified access, containing a hashed purchase reference, store environment, product and date, without the raw purchase evidence. This record is excluded from medication backups and is not a way to transfer a purchase between Apple and Google.

Store refund and reversal notifications can leave minimal records containing a hashed purchase reference, store/product, refund status and limited event/expiry times. These are pseudonymous, not guaranteed anonymous; Section 10 describes their retention. Older app versions may still create account-linked entitlement and purchase-claim records containing active/refund status, date, platform/product and the store purchase identifier (Google Play token or Apple original transaction ID). Existing account-linked records are retained and deleted under the same rules as before. Signing out, changing or deleting a Re:Fill account does not cancel a store purchase or remove currently verified store access.

2.5 Advertising data (Google AdMob)

Unless you have purchased “Remove Ads,” the App can show ads served through Google AdMob after its first 168 hours on the device. During that no-ads period the App does not run UMP or initialize Mobile Ads. After the period ends, every UMP information request is marked under age of consent, so UMP does not request adult advertising consent. Once UMP reports that ads may be requested, the App applies child-directed treatment and a G-rated content ceiling before Mobile Ads initialization. UMP does not pass its under-age flag to Mobile Ads, so these are separate controls. We do not ask for, infer or store your age; adults receive the same restricted treatment.

Every ad request also carries the non-personalized ads (NPA) and restricted data processing (RDP) signals. NPA and RDP do not by themselves exclude third-party bidding. The App additionally applies child-directed treatment to every ad request, and Google states that requests receiving this treatment are not eligible for third-party real-time bidding. AdMob's general partner and bidding lists therefore do not identify the recipients of these protected requests. The G ceiling limits creative content; it is not a substitute for the separate processing restrictions.

Google still processes information needed to deliver, measure and protect ads, including:

• your IP address, including its use for coarse, city-level location and invalid-traffic detection. The recorded account configuration disables optional full-IP sharing with bidding sources; this does not prevent Google from receiving an IP address to deliver the service;

• device and ad-request context, such as user agent, device/SDK details, the App and placement, and approximate IP-based location. We do not put medication fields into ad requests; and

• on-device storage or identifiers, where permitted by the serving mode, for functions such as measurement, frequency capping and fraud prevention. Limited ads have the narrower limits described below.

The Android advertising-ID and Privacy Sandbox advertising permissions are absent, and the App does not request iOS IDFA. We configure the Google Mobile Ads SDK to disable its publisher first-party identifier on both platforms: before SDK initialization on iOS and by persisting the setting after initialization on Android. Banners and interstitials require both UMP eligibility and successful completion of all protection-setting and SDK-initialization calls. Pending, failed or timed-out calls keep ad requests disabled without disabling other App functions. A failed attempt is not retried in the same App session. This does not establish the absence of SDK-initialization communication or make identifier generation impossible in every execution.

Limited ads are a separate serving mode. Our recorded AdMob configuration permits programmatic limited ads where Google's serving rules allow them. Limited ads disable personalization and identifier-dependent features such as frequency capping; the programmatic variant can use invalid-traffic-only cookies and local storage and Google programmatic demand. The child-directed exclusion from third-party real-time bidding still applies. The App has no third-party mediation adapter, and the recorded account configuration has no third-party waterfall source. General Authorized Buyers or SDK-bidding listings do not override the request's child protection. Google processing, ad-content delivery and any separate service-provider processing must still be assessed under the applicable roles, disclosures and transfer rules in Sections 7, 8 and 15; this Policy does not claim that the bidding restriction eliminates every third party or storage operation.

2.6 Crash and diagnostic data (off by default)

The App includes optional crash reporting via Firebase Crashlytics. It is disabled by default and is enabled only if you opt in in Settings. When enabled, it sends technical diagnostics (e.g., error messages, stack traces, device model, OS version) to help us fix problems. The App does not deliberately attach your medication database, and it redacts known sensitive patterns before reporting. Because exception text can change, we cannot promise that redaction will remove every piece of personal or health‑related text from every future report. You can turn off new collection at any time.

2.7 Feedback you send us (optional)

If you use the in‑app Send feedback feature, we collect the message you write plus basic technical details to interpret it: app version, device model, OS version, app language, and the time sent. It is stored in our cloud database (Cloud Firestore, by Google Firebase). The developer receives an hourly email notification containing only a link to the stored submission and its server receipt time, not the message or diagnostic details. Reading the submission requires a Google account with access to our Firebase project. This is a one-way feedback channel, not a guaranteed individual reply service. The App does not attach a dedicated account, email, or user‑ID field, even if you are signed in, and it does not automatically attach your medication database. This describes the stored feedback document: when you are signed in, Firebase still uses your account authentication token for the database request, without adding that token as a feedback field. This does not make the submission anonymous: you may identify yourself or disclose medication or diagnosis information in free text, and the diagnostic combination may distinguish a device or submission. Please do not include identifying or health information in feedback; use our support email if you need an answer or a verified privacy request.

2.8 Direct support and representative communications

If you email us or contact DataRep, we process the contact details and message you provide, any attachments or identity evidence, people or App records you mention, and our acknowledgement, instructions and response. An authority or organisation may also provide its identity, case details, allegations, referenced content or URLs. Please provide only what is necessary. These communications may contain health, offence-related or other sensitive information even though we do not ask for it; Sections 4, 7, 8, 10 and 13 explain the applicable limits and routes.

2.9 Information we do not collect

• No GPS or precise location (the App requests no location permission; see Section 2.5 for AdMob’s coarse, IP‑based location);

• No contacts, calendar, photos, camera, or microphone access;

• No advertising ID (Android) and no IDFA / cross‑app tracking (iOS);

• No general‑purpose product analytics SDK. The App does contain the AdMob/UMP advertising and privacy-status SDKs described in Sections 2.5 and 11;

• No payment‑card or financial account information.

---

3. How we use information

We use information only for the following purposes:

We do not use your health-related information for profiling that produces legal or similarly significant effects, and we do not exchange that health-related information for money or other valuable consideration.

Health‑related information is never used for advertising or marketing, never shared with the ad network, and is never used to determine employment or insurance eligibility or for any unauthorized social sharing.

---

4. Legal bases for processing (EEA / UK — GDPR)

If you are in the European Economic Area or the United Kingdom, we rely on the following legal bases:

Where the App validly asks you for consent, you may withdraw it at any time. You can stop making new backup requests, turn off new crash collection, and delete the cloud account to request deletion of a stored backup. Stopping new backup requests does not delete an existing stored backup. These controls do not by themselves settle the cloud-backup basis or authorisation condition described above. The current advertising route does not ask for an adult advertising-consent choice; you may object to legitimate-interest processing through the contact in Section 12 or remove ads through the one-time purchase. The current App has no separate stored-backup deletion control. Withdrawal does not change whether processing based on consent before withdrawal was lawful; it does not make an otherwise unlawful operation lawful.

---

5. Notifications and reminders

The App delivers dose and refill reminders as local notifications scheduled on your device. To fire reminders at the exact time you set, the App uses notification and exact‑alarm permissions (and, on Android, a permission to reschedule reminders after the device restarts). The content of your reminders does not leave your device for this purpose. You can manage notification permissions in your device settings; disabling them will stop reminders.

---

6. Health‑related (sensitive) information

The information you enter about medications and supplements can reveal information about your health. We treat it with particular care:

• It is stored on your device by default and is not transmitted to us.

• It is uploaded to cloud storage managed by us only when you request a backup. The storage path is tied to your authenticated account and end‑user access is restricted by account‑owner rules, but this is not end‑to‑end encryption: Google, and the developer under controlled administrative access, can technically process the server‑side copy.

• It is never used for advertising, marketing, or analytics, and is never shared with the ad network or any data broker.

• It is not connected to Apple Health / HealthKit or to Google Health Connect / Google Fit in any way.

• It is not made public by the App; you control all sharing (for example, files you export yourself).

Section 4 distinguishes ordinary on-device personal use from cloud backup operated by us as controller. On-device extraction and compression for a requested backup, and validation/restoration of downloaded data, also belong to the latter activity. Lack of access to device records is not a blanket exemption from legal responsibility; the limitations of the current backup flow without separate health-data consent or guardian procedures remain. General acceptance of the Terms/Policy or correcting the destination wording does not itself satisfy the valid processing basis and authorisation requirements applicable to sensitive information.

---

7. Third parties and service providers

We do not operate as a data broker or separately offer personal information for purchase. Data reaches the service providers and independent controllers described here to operate and secure the App, serve protected advertising, process purchases and optional features, or carry email between you and us. The child-directed bidding exclusion in Section 2.5 is distinct from the legal classification of any actual disclosure as a “sale” or “sharing”; Section 13 explains that applicability boundary.

Different legal roles are involved, and the difference matters to you:

• Processors process our customer data under the applicable service terms and instructions: Firebase Authentication, Cloud Storage, Cloud Firestore, Cloud Functions, Crashlytics, App Check, the Workspace mail route, and Data Protection Representative Limited when it handles representative communications. The active online Workspace Business Starter Agreement incorporates the Cloud Data Processing Addendum (CDPA) by reference. Google may separately process service data under its terms; the processor role does not cover every Google-group activity.

• Independent controllers decide their own purposes under their own terms and privacy policies, and we cannot direct that processing: Google AdMob, Google Play, and Apple. A separate service provider or party actually involved in ad-content delivery must be assessed under its own role and terms; we do not assign every party the same role. The App’s child-directed requests are excluded from third-party real-time bidding, so a general AdMob bidder-list entry is not evidence of that party receiving these requests.

• A storefront entity may also act as our commercial agent, commissionaire, marketplace provider or payment processor. That commercial role is not the same as being our processor for App data.

For electronic requests within the contracted language scope, DataRep's service can include translation into English. DataRep describes AI translation in its EU GDPR, DSA and Swiss representative services. This concerns correspondence, not access to your medication database or cloud backups. Separately arranged professional translation is a different service. The reviewed materials do not identify the technology provider, its processing countries, retention or training-use terms, or whether any particular request has been translated.

The Apple entities that cover the App's currently selected storefronts are Apple Canada, Inc.; Apple Pty Limited; Apple Inc.; Apple Services LATAM LLC; iTunes KK; Apple Distribution International Ltd.; and Apple Services Pte. Ltd. (which includes the South Korean storefront). Only the entity assigned to a user's storefront performs that commercial role. This storefront list does not replace the residence-specific Apple privacy controller stated above.

AdMob account controls and the actual request route. Regional partner and bidding lists describe account settings, not the recipients of every request. Their membership can change without an App update, but it does not override child-directed treatment. Because every UMP request is marked under age of consent, the App does not use an adult-consent message as its current party-disclosure surface. This Policy and the provider links below must describe the actual Google route and any separate recipients that are involved; required party and overseas-transfer details must be established before public use of an affected route. Before changing age treatment, request signals, mediation or other routing controls, we reassess recipients, applicable notices and transfer grounds. A list change alone is not proof of a new recipient for the protected route.

Our separate seller‑payout agreement is with Google Payment Korea Limited. It concerns payment to us as the developer and is not listed as a recipient of an App user's card or billing details, which the App never receives.

The entity and role mapping is reviewed when a billing profile, storefront/territory, provider agreement, subprocessor list or UMP partner selection changes. A storage region such as Seoul is a technical location, not a contracting entity or a guarantee that all support and onward processing stays there.

Useful links:

• Google Privacy Policy

• Google contracting entity schedule

• Google Cloud Data Processing Addendum

• Google's AdMob ad-partner controls

• AdMob bidding rules and the child-directed exception

• Google's explanation of limited ads

• Google's publisher first-party identifier controls

• Google Cloud subprocessors

• Google Controller‑Controller Data Protection Terms

• Firebase Data Processing and Security Terms

• How Google uses information from sites or apps that use its services

• Google Ads settings

• Apple Privacy Policy

• Sign in with Apple & Privacy

• App Store & Privacy

• DataRep Privacy Notice

---

8. International data transfers

The primary resource location for your cloud backup, purchase entitlement, and feedback is Google Cloud / Firebase in the Republic of Korea (Seoul region, asia-northeast3). A regional storage choice does not mean that all support, security, telemetry, or provider processing stays in Korea; Google describes these Firebase products as using global infrastructure subject to product terms.

Sign‑in is different. Google runs Firebase Authentication only from data centres in the United States, and the service offers no choice of region — so your account identifier, the email address you sign in with, and a display name where your provider supplies one are held in the United States rather than in Korea. The safeguards for that transfer are the ones described below.

• For users in the EEA/UK: the Republic of Korea has been recognized as providing an adequate level of protection within the scope of the relevant EU/UK decisions. Direct collection from you, storage in Korea, and a provider’s later disclosure to a separate overseas recipient are legally distinct events. For Google Cloud/Firebase processor services, a restricted transfer from us to a non‑adequate Google processor uses the Controller‑to‑Processor SCCs (Module 2); Google's onward restricted transfer to a subprocessor uses the Processor‑to‑Processor SCCs (Module 3) unless an applicable alternative covers it.

• For users in Switzerland: the Swiss Federal Council has not listed the Republic of Korea in Annex 1 of the Data Protection Ordinance. A Swiss-law disclosure to a non-adequate country requires an applicable Article 16 safeguard or Article 17 exception. The provider SCCs described here apply only within their respective contractual scope; Korea's EU/UK adequacy does not substitute for a Swiss-law ground. DataRep's separate route is described below.

• For AdMob and Google Play controller processing, the Google end controller is Google Ireland Limited for EEA/Swiss data and Google LLC for UK data. The Ireland route is adequate; a restricted UK route to Google LLC uses the Controller‑to‑Controller SCCs (Module 1). Google's EU–U.S. DPF, UK Extension and Swiss–U.S. DPF apply only to Google LLC and covered certified U.S. subsidiaries, not automatically to every Google affiliate or ad partner.

• For Apple, Apple Distribution International Limited controls EEA/UK/Swiss personal data and Apple states that its international transfers of that data are governed by Standard Contractual Clauses. We do not claim an Apple EU–U.S. DPF basis.

• The active online Workspace Business Starter Agreement is with Google Asia Pacific Pte. Ltd. in Singapore and incorporates the CDPA by reference. The Admin legal record confirms the CDPA acceptance and European Data Protection Law certification and records the Irish DPC, UK ICO, Swiss FDPIC and our appointed representative, DataRep. The appropriate SCC version specified by the CDPA therefore applies to an applicable EEA/UK/Swiss restricted transfer. The hourly feedback digest uses the Gmail API with a dedicated gmail.send grant, and direct email is received, stored and answered in the same Workspace mailbox. New business mail is not globally forwarded to a separate consumer Gmail account. If our billing country, applicable law, contract or service scope, competent authority, representative or operational mail route changes, we pause the affected route until the record and safeguards are re-verified.

• DataRep representative communications are a separate route. The contracting entity is the Irish company Data Protection Representative Limited. It receives communications in the relevant jurisdiction and forwards them through its EEA/UK operations to us in the Republic of Korea. The EEA→Korea and UK→Korea stages use the applicable adequacy decision/data bridge within its scope. DataRep describes other DataRep companies, service-delivery third parties and public-cloud providers by category; their individual names and processing countries are not identified in the materials available to us. Its Terms cite requestor consent, performance of a contract in the requestor's interest and public interest as grounds for forwarding. Those contractual statements do not establish a Swiss-law safeguard or exception for every case, and we do not claim that DataRep's Swiss→Korea route is covered by SCCs. You may ask us about the applicable recipients and transfer ground for your request, or contact us directly using Section 13.

• Google and Apple operate globally and may process data outside Korea as part of the applicable service. A U.S. Google transfer may use an active Data Privacy Framework certification within its exact entity and service scope; otherwise the applicable SCC remains the safeguard.

---

9. Sign in with Apple and Google

• Sign in with Apple (iOS): You may use Hide My Email, in which case we receive only a private relay address (@privaterelay.appleid.com) rather than your real email. We use your email solely to identify your Re:Fill account. If you delete your account, we request revocation of the Sign in with Apple token. A failure to complete token revocation does not prevent you from deleting your Re:Fill account.

• Google Sign‑In (Android): We receive your email and display name to identify your Re:Fill account.

We do not use sign‑in information for advertising or marketing.

We verify the source and contents of Apple's account-change notifications before handling them as follows.

• Withdrawal of Sign in with Apple for Re:Fill: we restrict access using Apple sign-ins at or before that withdrawal. This alone does not delete your Re:Fill account, cloud backups or purchase entitlement. A later, newly authenticated Apple sign-in and a sign-in through another provider are treated separately. To erase cloud data, use account deletion or an email request.

• Request for permanent deletion of the Apple Account itself: we check the notification and associated Re:Fill account. Where there is no other linked sign-in provider and the account state can be safely confirmed, we restrict access and remove cloud backups, legacy account-linked entitlement/purchase-link records and the Re:Fill cloud account. A newer sign-in or account, another provider, an ongoing deletion or other uncertain state requires review rather than automatic deletion. Failure to find an account mapping is not proof that all earlier data has been erased.

• Change to Hide My Email forwarding only: we do not delete the account or backups. This route does not send automated email to you or create a new email-preference list.

Notification delivery and processing may be delayed. Do not rely on Apple Account deletion alone for immediate Re:Fill erasure; use in-app deletion or the email-request route when you need to request deletion directly. This server processing does not delete on-device data or cancel the store purchase itself. Purchase recovery after permanent deletion of the Apple Account depends on Apple's rules and is not guaranteed by Re:Fill.

See Section 12 for direct deletion methods and Section 10 for processing-record retention and residual-upload checks.

---

10. Data retention

• Temporary iOS deletion-request protection: the request's limited permission to continue cleanup lasts 2 hours from the setting or renewal of that deletion-request protection. An incoming Apple account-change notification does not by itself extend this permission. Expired permission does not remain valid while a record awaits deletion. Without an Apple access restriction or unresolved permanent-deletion safeguard, the record becomes eligible for automatic TTL deletion at the same two-hour boundary. Otherwise, the access-restriction and unresolved-work criteria below apply. This does not extend the request's two-hour permission. Firestore deletion is asynchronous; recovery copies follow the separate periods below.

• On‑device data: kept until you delete it in the App or uninstall the App.

• Cloud backups: a live backup remains until you overwrite it or delete your cloud account. Google Cloud Storage object versioning also keeps the generations a new backup replaces, so that a backup made by mistake over a good one can still be recovered. An older generation becomes eligible for automatic deletion when it is outside the 10 most recent or has been noncurrent for 365 days, whichever happens first. Google performs lifecycle actions asynchronously and does not guarantee an exact execution time. Once the lifecycle delete runs, the generation remains restorable by us for the bucket’s 7‑day Soft Delete window and is then no longer recoverable by us through Cloud Storage. About 373 days (365 days, an operational estimate of about one day for lifecycle processing, and 7 days of Soft Delete) is a planning estimate, not a guaranteed deadline or a statement that every provider‑system copy has been physically erased. Your current backup is never selected by these lifecycle rules. Deleting your account requests deletion of every generation.

• Cloud‑backup deletion limits: account deletion closes your backup folder to new uploads first, then requests deletion of every generation and re‑checks until no active generation is listed, to remove generations visible during those checks. After Firebase Authentication reports an individual account deletion, the server also re‑checks that account's backup folder and requests deletion of all remaining generations, including earlier versions, only after confirming the account is absent. These controls do not by themselves establish cancellation of every upload session already in progress; after a backup or its metadata file finishes uploading, the server checks account existence and requests deletion only of that exact file version if the account is absent. Existing accounts, including disabled or recreated accounts found by the check, are preserved. Account-check failures do not establish absence. These cleanup routes do not bypass unresolved Apple account-deletion safeguards. Event delivery and retries have finite windows of up to 7 days for account-deletion events and 24 hours for upload-completion events. These are retry limits, not waiting periods before deletion, deletion deadlines or guarantees that every provider transport copy is erased then. Failed or undelivered events require operational follow-up; these routes do not replay all historical account deletions or uploads. Deleted objects remain recoverable by us for 7 days under Google Cloud Storage Soft Delete; after that window they are no longer recoverable by us through Cloud Storage. Under the current Google Cloud Data Processing Addendum, once Customer Data cannot be recovered by the customer, Google completes deletion of the relevant Customer Data from its systems as soon as reasonably practicable and within a maximum of 180 days, unless applicable law requires storage. The 7‑day and estimated 373‑day figures therefore describe our Cloud Storage recovery window, not the completion of deletion from every Google system.

• Account information: kept until you delete your account. Our sign‑in provider states that once deletion is started, the information is removed from its live and backup systems within 180 days.

The following criteria cover Apple notification processing, access restrictions and post-deletion checks described in Section 9. Temporary iOS deletion-request protection follows its separate permission limit above.

• Account-security/deletion-processing records: unresolved Apple account-change work retains limited necessary account identifiers, state, times, retries and review information. We do not discard unresolved work merely because a period has elapsed; delays, review dates and continued necessity are checked. After resolution, direct linking fields such as the Apple user identifier and Re:Fill account identifier are removed, and a minimal completion receipt used to prevent duplicate processing becomes eligible for automatic deletion 31 days after completion. The receipt is not guaranteed anonymous.

• Access restrictions and deletion-request markers: records preventing reuse of an earlier Apple sign-in remain while the Re:Fill account exists and become eligible for automatic deletion two hours after its absence is confirmed. The separate, limited permission to continue an in-app deletion request follows the two-hour rule above, not the lifetime of the access restriction. Unresolved Apple permanent-deletion protections remain even if the account has disappeared and become eligible two hours after cleanup completion is confirmed. A position used to check these records in turn can contain an account identifier and is reset when a full pass finishes. If checking stops partway through, that position can remain longer; its continued need must be reviewed.

• Residual-upload checks after Apple permanent-account deletion: after safety checks, we remove existing cloud data and the account first, then check for late uploads against an eight-day boundary measured from confirmed revocation of sign-in credentials. This is not an eight-day wait before deleting existing backups. Completion requires a new check started at or after that boundary confirming no residual data. Delays, failures or uncertain account states require review and can postpone confirmation. Necessary processing records remain during this work, not a separate copy of medication contents.

• Automatic deletion and recovery copies: the 31-day and two-hour record-retention periods above determine eligibility for automatic deletion, not a guaranteed time of physical erasure. Google says Firestore TTL deletion is typically completed within 24 hours after eligibility, but it is asynchronous and not instantaneous. This delay does not extend a deletion request's limited permission. The Firestore recovery copies and operational/security logs below have their own retention periods and do not disappear when the live processing record is deleted.

• Purchase entitlement: the device keeps its verified store-specific record until current store reconciliation removes it or the app data is erased. Legacy account-linked cloud entitlement records are kept until account deletion, including refund status while the account exists. Your purchase itself is held by Apple/Google and a valid purchase can be restored even after account deletion.

• Refunded-purchase records: legacy purchase and refund records remain linked to your cloud account while it exists. On account deletion, unrefunded purchase claims are deleted; refunded or revoked claims lose your account identifier, raw store purchase identifier and ownership type, and become eligible for automatic deletion 180 days after the account link is removed during deletion. The remaining hash key, store/product, refund status and limited timestamps are pseudonymous, not guaranteed anonymous. Refund or reversal notifications received without an account-linked claim use that minimal form and retain any existing valid expiry without extending it. If no valid expiry exists, we set one no later than 180 days from the notification’s authenticated event time, using an earlier recorded time where available. Notifications do not recreate an account. In older app versions, a legitimately restored purchase can become account-linked again; the current accountless verification flow does not create that link. These records help prevent reuse of refunded purchases. Deletion is asynchronous and typically occurs within 24 hours after TTL eligibility, not at the exact expiry instant.

• Crash diagnostics (if enabled): kept by Crashlytics for approximately 90 days; turning the feature off stops new collection but does not instantly erase reports already sent.

• Feedback: the Firestore submission is retained for 365 days after server receipt and then becomes eligible for automatic TTL deletion. Google says TTL deletion is typically completed within 24 hours after eligibility, but it is not instantaneous. The Workspace link notification has the same 365-day period after receipt and is permanently deleted on the next scheduled application of the Workspace rule, which might not run at the exact expiry moment. A verified deletion request or earlier end of purpose shortens both periods. If a submission contains health information or unnecessary direct identifiers, we restrict access and promptly delete the live Firestore record and any existing email copies containing that content, unless a specific lawful retention requirement applies as described in Section 4. We also remove the associated notification where identifiable. New notifications do not contain the feedback body, but this does not erase existing copies or the recovery copies below.

• Support and privacy‑request email: routine correspondence has a 365-day retention period after the final response. It is then permanently deleted on the next scheduled application of the Workspace rule, which might not run at the exact moment the period ends. A documented exception carries its own end date: an actual consumer complaint or dispute record is retained for 3 years, and an applicable electronic-commerce contract, withdrawal, payment or supply record for 5 years. Separately, an important business document covered by the Korean Commercial Act is retained for 10 years from its creation, and a voucher or similar document for 5 years from its creation. A specific statutory duty, authority matter or legal claim may require a different recorded period; none of these exceptions is applied to every support email.

• DataRep representative records: DataRep's Privacy Notice states that it keeps an email archive of Data Requests and client responses for 10 years, to evidence requests and responses in the event of later claims. That archive is separate from our Workspace copy; deleting our copy does not delete DataRep's copy. Under Terms v4.1 §§6.2(f) and 7.6, personal data is returned or deleted at the end of the appointment, except for retention permitted by applicable law or lawful legal/audit purposes. DSA correspondence follows that contractual end-of-appointment and lawful-retention criterion; no separate numerical DSA period or exact deletion deadline is published. Neither our 365-day correspondence period nor the 10-year Data Request archive is automatically applied to DataRep's DSA records.

• Firestore recovery copies: point-in-time recovery may retain earlier account, purchase, feedback and temporary processing records for up to 7 days; daily managed backups retain snapshots for up to 28 days from creation. These periods are separate from live-record retention, so copies can remain after a live record is deleted. Individual records cannot be selectively edited in these copies, which expire automatically. Before restored data is used, subsequent deletions, expiries and revocations must be applied and checked. Affected records are not returned to service if that cannot be verified.

• Operational and security logs: technical server logs may include your account identifier and are not designed to contain your medication database. Our ordinary operational/security log retention is 180 days for security, fraud prevention and refund, billing or deletion disputes. Google-required administrative audit logs have a separate, provider-fixed 400-day retention period. The logs expire on their respective schedules, not as a selective part of live-account deletion. Any legal exception to an erasure request must be assessed for that request; the log schedule is not a blanket exception.

---

11. Cookies, identifiers, and similar technologies; advertising controls

The App is not a website and does not use browser cookies for its own features. The Google AdMob SDK can nevertheless store or read identifiers/local storage for an eligible advertising mode. After the 168-hour no-ads period, the App first asks UMP for current ad-serving status with its under-age flag set; UMP does not ask for adult advertising consent and does not transfer that flag to Mobile Ads. Before Mobile Ads initialization, the App therefore separately applies child-directed treatment and a G ceiling. It then requests NPA and RDP on every ad request, disables the two platform cross-app advertising IDs, and invokes the SDK controls for its publisher first-party identifier. NPA may still use permitted storage for frequency capping, aggregate measurement and fraud prevention. Limited ads are different: features that need a local identifier are unavailable, except that our current programmatic limited ads setting permits invalid-traffic-only cookies/local storage and programmatic demand where Google's stated conditions are met. None of these modes means that only Google can receive an ad request (Section 2.5).

Your controls:

• Remove ads entirely: when the product is offered through your app store, buy the one‑time “Remove Ads” purchase in the App.

• All regions: the App does not collect an age or divide users into adult and child advertising paths. It submits the same UMP under-age and Mobile Ads child-directed/G configuration for everyone, so the current flow does not request or expose an adult advertising-consent choice.

• Google and device settings: you can review Google’s general ad settings at adssettings.google.com and industry opt-outs at aboutads.info, and adjust ad settings in your device’s operating system. Those settings do not make Re:Fill request personalized advertising.

---

12. How to access or delete your data; your controls

• Request deletion of your account and linked live cloud data — in the App: Settings → Account → Delete Account. The cascade removes your authentication record, the backup generations found by the deletion function, and your purchase‑entitlement record, and unlinks or deletes the associated purchase‑claim records. Section 10 explains the 7‑day Storage soft‑delete window, the 7/28‑day Firestore recovery copies, 180-day operational/security logs and 400-day provider-required administrative audit logs, and the de‑identified refunded‑purchase record. Your store purchase remains with Apple/Google and can be restored.

• Delete your account — on the web: you may also request deletion at the Account & Data Deletion page or by emailing support@jansevtlabs.com.

• Stop making new cloud backups: do not request another backup. The current App has no separate backup‑off or stored‑copy deletion control; use account deletion to request removal of the stored cloud backup.

• Delete on‑device data: delete entries in the App, or uninstall the App.

• Turn off crash reporting: Settings → crash reporting toggle.

• Delete feedback you sent: the App attaches no dedicated account identifier or reference code, so we cannot automatically match a submission to an account. Email support@jansevtlabs.com with the approximate date/time and message text; we will search Firestore and any existing content-bearing email copies, identify associated link notifications, and delete matching records on a best‑effort basis. This matching limitation does not mean the text is anonymous.

• Delete support correspondence: ask us at the same address. We delete matching correspondence earlier when the request is valid, unless a documented statutory duty, authority matter, or legal claim requires retention until its recorded end date. Without an earlier deletion or documented exception, the routine 365-day schedule in Section 10 applies.

We will respond to verifiable requests within the time required by applicable law.

---

13. Your privacy rights

Depending on where you live, you may have some or all of the following rights. To exercise them, contact support@jansevtlabs.com.

• EEA / UK (GDPR): access, rectification, erasure, restriction, objection, portability, and the right to withdraw consent. You also have the right to lodge a complaint with your local supervisory authority.

• California (CCPA/CPRA): the right to know, delete, and correct your personal information, to limit the use of sensitive personal information, and—where applicable—to opt out of a “sale” or “sharing.” The currently confirmed revenue and processing scale does not meet the CCPA definition of a business. We do not operate as a data broker, request cross-context behavioural targeting, or send platform advertising IDs. Every ad request carries NPA/RDP and separate child-directed treatment, which excludes it from third-party real-time bidding under Google’s rules. These technical restrictions do not by themselves determine the legal classification of all actual Google or separate-provider processing. Before that law applies to this advertising route, we must document the relevant terms and data use and provide any required opt-out and Global Privacy Control handling. We will not discriminate against you for exercising a privacy right.

• Other U.S. states: if you reside in a U.S. state with a comprehensive privacy law (for example, Virginia, Colorado, or Connecticut), you may have similar rights to access, correct, delete, and opt out; contact us to exercise them.

• Republic of Korea (PIPA): see Section 15.

EEA, UK and Swiss users (Article 27 / FADP Article 14 representative). We are established outside the EEA, the UK and Switzerland, so we have appointed a representative under Article 27 of the EU GDPR, Article 27 of the UK GDPR, and Article 14 of the Swiss FADP. If you are in one of those places, you may contact the representative about our processing of your personal data, instead of or in addition to contacting us.

Our representative is Data Protection Representative Limited, trading as DataRep, registered in Ireland under company number 616588. Reach them in whichever way suits you:

• Email — datarequest@datarep.com, putting Jansevt Labs; Re:Fill in the subject line.

• Online form — www.datarep.com/data-request.

• By post — address the envelope to DataRep, not to Jansevt Labs, or it may not reach them, and name Jansevt Labs; Re:Fill inside the letter:
• EEA: DataRep, 77 Camden Street Lower, Dublin, D02 XE80, Ireland
• UK: DataRep, 107-111 Fleet Street, London, EC4A 2AB, United Kingdom
• Switzerland: DataRep, Leutschenbachstrasse 95, 8050 Zurich, Switzerland
• DataRep also provides postal contact routes for the other EEA countries. Ask us, or DataRep, for the address designated for your country.

If you use this route, DataRep processes the request and response records described in Sections 7, 8 and 10, including the published 10-year Data Request email archive. The translation services described above may apply. Our response is normally sent directly to you. DSA communications use the separate address in our Terms of Service and the retention criterion in Section 10. Using a representative does not give it access to your App database.

Please use the representative for data‑protection matters only. For help with the App, a question about your account, or anything else, write to us directly at support@jansevtlabs.com — that reaches us faster. You may also lodge a complaint with your local supervisory authority (in the UK, the Information Commissioner’s Office; in Switzerland, the Federal Data Protection and Information Commissioner).

---

14. Security

• On‑device data is protected by your device’s built‑in operating‑system encryption (Android File‑Based Encryption; iOS Data Protection). The App does not add a separate application‑level encryption layer to the local database, so keep your device secured (lock screen, OS updates).

• Cloud data is transmitted over TLS and stored using Google Cloud’s server‑side encryption at rest; backup integrity is verified with SHA‑256.

• End‑user access to cloud data is restricted by authenticated‑account rules and protected by Firebase App Check, which uses Google Play Integrity (Android) or Apple App Attest (iOS) to help verify that requests come from a genuine App installation. At every process start, before any consent screen, the App configures the relevant provider; configuration alone does not necessarily obtain a new attestation or make a network transfer. When the SDK needs a current token, the provider receives the IP address, app‑installation/device‑integrity material and related context. The SDK caches the resulting token and automatically supplies a current token with requests to protected Firebase services. Five protected functions covering backup, purchases, account deletion and quiet Apple-session checks instead obtain a fresh limited‑use token when they are invoked. The server submits that token to App Check's consumption check and, if App Check reports that the token was already consumed, rejects the request before authentication, input processing or any side effect. The explicit handler check is required because consumption alone does not automatically reject a repeated valid token. We do not deliberately attach your account, email or advertising ID to the attestation, but these signals can distinguish an installation or device and are not described as anonymous (Art. 6(1)(f); see Section 4). Google and controlled developer administrative access remain technically capable of processing server‑side data; the App is not end‑to‑end encrypted.

No method of transmission or storage is 100% secure, and we cannot guarantee absolute security.

---

15. Republic of Korea — PIPA disclosures

This section addresses the Personal Information Protection Act (“PIPA”) in the Republic of Korea and supplements the rest of this Policy.

• 1) Purposes of processing: providing medication/supplement reminders and refill tracking; optional cloud backup/restore; account authentication, access protection and deletion handling; ad delivery; optional crash diagnostics; handling user feedback and improving the App; handling privacy, representative, authority and DSA communications; security and legal compliance (Section 3).

• 2) Items processed: medication/supplement names, quantities, dosages, units, schedule times and labels, intake records (timestamps/status), notes, categories, app settings; account email, display name, identifiers and limited account-security/deletion-processing records (2.2); purchase‑entitlement record; ad‑related data (IP, device/contextual, identifiers); opt‑in crash diagnostics; feedback text and diagnostic fields; and, when a representative route is used, the requestor's identity/contact or authority details, request/message, attachments/evidence, people or records mentioned, and our instructions/response (Sections 2, 7 and 13).

• 3) Retention and use period: see Section 10. We delete live data without undue delay when its purpose ends or a valid deletion request applies, subject to the documented provider and recovery windows. DataRep's separate Data Request/client response email archive is 10 years. Its DSA records follow the contractual end-of-appointment return/deletion criterion and lawful-retention exceptions, not an inferred 10-year period.

• 4) Provision to third parties: we do not operate as a data broker or separately offer personal information for purchase. AdMob/UMP, Google Play Billing, Apple and any separate service provider actually involved process the limited data described in Section 7 under their applicable roles, purposes and terms. A general AdMob bidder list does not establish receipt of the App’s child-directed requests, which are excluded from third-party real-time bidding. These routes are distinct from processor consignment (see item 5 below, which explains which ground applies to which route).

• 5) Consignment, independent controllers, and overseas transfer (under PIPA Article 28-8): the App uses the following overseas processor and controller routes (cloud backup is performed only when you request it). A contracting or billing entity is not automatically the physical storage location, and a storefront agent is not automatically our processor:

Ground and conditions. For overseas outsourced processing or storage within our authentication, App Check, cloud backup/storage, entitlement-sync, optional crash-reporting and Workspace mail routes, PIPA Article 28-8(1)3 is the intended ground. It applies only where that processing or storage is necessary to enter into or perform a contract with you, and all required transfer details are published in the Privacy Policy or notified by a legally permitted method. Our contract with a provider alone does not establish those conditions. This ground does not cover provision to an independent controller merely because we use that provider's service; the independent processing by advertising, sign-in and store providers must be assessed separately.

Required transfer details. For each applicable route, the disclosure must identify the transferred data; destination countries, timing and method; the recipient's legal name and contact details; its purpose and retention/use period; and how to refuse the transfer and the effects of refusal. General descriptions such as “global provider routes” or categories of subprocessors do not replace those specific details. Where details remain unverified, the table is not a completed transfer disclosure: we must establish the applicable ground and required notice before public use of the affected route. The safeguards in Section 8 do not by themselves establish a Korean-law transfer ground or the sensitive-information condition in item 6.

DataRep. An individual's direct submission abroad, onward delivery to Korea and any personal data we send back from Korea are distinct processing stages. The available materials do not determine every onward recipient/country or the applicable PIPA transfer ground for every stage. The representative appointment is not treated as consent to those disclosures.

How to refuse. You can avoid account/backup transfers by not signing in or requesting backup, avoid Crashlytics by leaving it off, and avoid feedback/email transfers by not sending them. You do not have to use DataRep for an ordinary privacy request: you may contact us directly at support@jansevtlabs.com, without losing your rights. Communications that authorities direct to a legally appointed representative are handled under the applicable legal duty, not optional marketing consent. Ad‑related processing stops after “Remove Ads” is active. App Check has no in‑App off switch: its provider is configured at every process start, and token acquisition, refresh or use occurs when required to protect Firebase services. Provider configuration alone is not necessarily a transfer. Not using an optional feature prevents its new transfers but also means that feature is unavailable to you; it does not erase information already held. Section 12 explains deletion and other rights. The App does not offer a mode that guarantees all provider transfers are disabled.

• 6) Sensitive information: medication/supplement data may constitute health-related sensitive information. Where Article 23 applies, it requires separately informed consent or a statute requiring or permitting the sensitive-information processing; no such statutory alternative has been established for this App’s cloud backup. It stays on your device by default and is uploaded only when you ask for a backup. The current confirmation says that “current data” will be backed up using the connected Google or Apple identity; it does not separately name medication/health information or ask for consent to that processing. The App attempts to save the action, time and wording version locally; a failed local write does not stop the backup attempt. This record is not included in the cloud backup and is unavailable to us. We do not treat that confirmation, the general sign-in footer or the local record as proof that PIPA Articles 22 and 23 consent, an Article 22-2 legal-representative authorisation, or equivalent foreign-law requirements have been met. Before offering the feature where such a requirement applies, we must establish and be able to demonstrate the applicable basis and, where required, verify the legal representative's consent; otherwise the feature must not be offered to the affected jurisdiction or age group. The overseas-transfer ground for an otherwise lawful upload is addressed separately in item 5 and does not replace these sensitive-information or child-authorisation requirements.

• 7) Destruction procedure and method: live electronic records are deleted using the relevant service deletion method and then age out of Soft Delete, immutable recovery backups, logs, and other documented copies under Section 10. Product recovery periods state when we can no longer recover data through the service; they do not by themselves prove that every provider‑system copy has already been physically erased. Google’s applicable processor deletion period and legal‑retention exceptions are stated in Section 10. On‑device data is removed when you delete entries or uninstall the App.

• 8) Rights of data subjects and legal representatives, and how to exercise them: you may request access, correction, deletion, or suspension of processing by contacting us (Sections 12–13).

• 9) Automatic collection devices (e.g., identifiers/cookies) and how to refuse: see Section 11.

• 10) Security measures: see Section 14.

• 11) Privacy Officer: under Article 31(2) of PIPA and Article 32 of its Enforcement Decree (small‑business owner), no separate Privacy Officer is designated; the developer acts as the Privacy Officer.
• Operator / Privacy Officer: DONGHUN HAN, sole trader trading as Jansevt Labs
• Contact: support@jansevtlabs.com

• 12) Right to lodge a complaint: you may contact the Personal Information Protection Commission (PIPC) / Korea Internet & Security Agency Privacy Center (privacy.go.kr, 118).

• 13) Automated decisions (Article 37-2): the App provides reminders and refill alerts using fixed schedules that you set; we do not make any decision about you by fully automated means (including AI) that produces legal effects or similarly significantly affects you within the meaning of PIPA Article 37-2, so the rights to refuse such a decision or request an explanation do not currently apply. If this ever changes, we will disclose the criteria and procedure used and how personal data is processed, and we will honor those rights.

---

16. Children’s privacy

Re:Fill is a general-audience App intended for people aged 13 or older, including users aged 13–17; it is not a Kids Category product and is not directed to children under 13. Store content ratings do not verify a user's age or legal capacity. We do not ask for or verify a date of birth, age, adult status or guardian status.

Core medication records stay on the device by default. Optional cloud backup is different: it sends account-linked medication and supplement records to cloud storage where Google and the developer under controlled administrative access can technically process the server-side copy. When the law requires consent or verified parent/legal-guardian authorisation for that processing—such as for a Korean child under 14 or a child below the applicable EEA digital-consent age—Google/Apple sign-in, a store age rating, purchase approval, acceptance of these documents or the present device-only action record does not by itself establish that requirement. The App currently has no separate health-data consent or guardian-consent/verification procedure or age-based backup block. Sections 4 and 15 describe the applicable legal requirements alongside these procedural limitations.

If we learn that a child has provided off-device personal information without an authorisation required by applicable law, we will restrict the processing and delete it without undue delay unless the law requires or permits a different response. If you believe this has happened, contact support@jansevtlabs.com.

---

17. Changes to this Policy

We may update this Policy from time to time. We will post the updated version with its “Last updated” date and a separate “Effective date” and, where required, provide additional notice. If a change conflicts with a contract term, the provision more favorable to you applies (as required under Korean law). For users in the Republic of Korea, we will give notice at least 7 days before a change takes effect, and at least 30 days before any change that materially affects your rights or obligations (for example, new categories of personal information collected or a new purpose of use).

---

18. Contact us

Email: support@jansevtlabs.com