Privacy Policy

1. What we handle, and where it is stored

Temperaments, chemistry and scores shown in the app are all computed on your phone; nothing is sent to a server in order to compute them.

Optional use of location — In Settings → "Today's time periods" you can turn "Use current location for time periods" on or off; the default is on. While it is on, the app checks your location when you open "My chart today", and asks for the while-in-use location permission if you have not decided yet. It never re-asks automatically after you decline once — change it in your device's app settings. Once a valid fix is obtained the lookup ends, and latitude, accuracy and the measurement time are used only to check validity. The rounded longitude and the expiry information are deleted when you turn the setting off, leave the screen, send the app to the background, after the 15-minute expiry, or when the device date or time zone changes. While the setting is on, one fresh lookup happens when you return to the screen or after expiry; nothing is looked up in the background. Only the on/off setting is stored on the device: no movement history is built, and the location is never sent to geocoding, map or weather services. How the operating system's own location services behave follows your device settings and those services' policies. You can use the app with the device clock alone without allowing location.

2. Data we do not require, and data we do not collect

• We do not require legal names, contacts, addresses or photos. However, if you put a real name in a free-text label or display-name field, it may be included in an invitation relay or share link (we recommend labels such as "friend" or "my manager")
• Server-side collection of location, permanent storage of it, or movement history (the on-device handling you may opt into is in §1)
• Advertising identifiers and third-party analytics or ad SDKs such as Google's or Meta's (app and web usage statistics are aggregated in Umami, which we run ourselves. App statistics pass through our server, which may add an approximate country derived from the connecting IP — §6)
• Account information — 4tuneHacker has no sign-up and no sign-in

3. How invitation relay works

When a friend enters their birthday through your invitation link, that content travels over an encrypted connection (HTTPS), rests briefly on the relay server, and is deleted the moment the inviter's app fetches it. Anything the app never fetches is deleted automatically after 7 days. The relay server does not read or use that content for any other purpose.

The friend's input page carries the same notice, and the form is submitted only after the friend checks the consent box.

The app (1.0.1 build 27 or later) does not save a received reply as a person right away. It keeps the reply in the "Friend replies to review" list on Home, and the reply becomes a person only when the inviter taps Add. Ignore deletes it from the phone at once; Report deletes it from the phone and opens an email to us (§8). The review list is not included in backup files.

The inviter can close an invitation link at any time with Make a new link in "Add a friend". A closed link can no longer send details, and any server copy sent through it that has not been delivered yet is deleted together with it, with anything left over removed automatically within 7 days at the latest. Closing a link without an internet connection takes effect on the server the next time you open the app online.

3-1. Sending your saved birth details

When you choose to send your own details, the app first shows your public display name, Gregorian birth date and birth time (or unknown). Sharing sends this text and an app link containing the same information to the messaging app you choose. Copying puts it on your clipboard. The link is encoded, not encrypted. Our server does not relay or store this message.

The recipient reviews the details before adding them to their phone. The Hangul name registered for name readings is excluded, as are person identifiers, conversation records and backup credentials. Messages and clipboard contents may also be kept by your device or chosen service. Deleting your information in this app does not delete those copies; ask the recipient to delete them separately.

4. How to delete things

• Deleting a person — deleting a person in the app also deletes their birthday and derived values, along with the conversation notes, the recently copied item and the conversation-mode setting attached to them. Earlier automatic backups may still contain them.
• Deleting conversation notes — you can delete them one by one on a friend's conversation history screen. Notes in earlier automatic backups or exported backup files must be deleted separately.
• Deleting all automatic backups — choose “Delete all automatic backups” in Settings → Data to remove the app's automatic copies. Turning automatic backup off also deletes existing automatic copies. If deletion fails, the app shows an error and retries on a later launch.
• If you are a friend who wants your data removed — after delivery, ask the person who invited you to delete it from their phone. A server copy that has not yet been delivered is removed under the invitation-relay rule below.
• Invitation relay messages — the server copy is deleted as soon as the inviter's app stores it in the review list and acknowledges receipt. An unreceived message is deleted automatically after at most 7 days. A sender cannot retract it from the app after submitting it.
• Ignoring or reporting a reply — deletes that reply's label, birth date and time from the phone immediately.
• Closing an invitation link — "Add a friend" → "Make a new link" (or "Report and close link" when reporting).
• Deleting a share link — delete it in Settings → My share links and it stops opening immediately; it is fully removed from the server 7 days later. Even if you never delete it, a link disappears automatically 180 days after it was last opened.
• Withdrawing usage-statistics consent — turning the switch off in Settings stops new transmissions and deletes this device's consent record (§6-1). Turning it off is not itself reported to the server.
• Requesting deletion of statistics already sent — tap Settings → Data → "Request deletion of sent usage statistics" to send a request containing only this install's identifier. The server deletes this install's usage-statistics records within about 2 days. You can tap it whether statistics are on or off, and tapping it does not turn statistics back on.
• Deleting the app — the app's internal data and automatic backups go with it, but exported backup files, operating-system device backups, messages or clipboard contents, and copies on recipients' devices must each be managed separately. Share links and existing usage statistics are not erased by deleting the app alone; they follow §5 and §6. Delete share links in Settings before removing the app if you want them to stop opening immediately.

5. Share links ("Share a link")

When you tap "Share a link" on a compatibility or group screen, only the result values — temperament, inner nature, zodiac animal, elements, score, label (or initials) and graph layout — are stored on the server and a pillaxy.com/share/… address is created. No birthday or birth time is included, and a link alone cannot be used to work a birthday back out.

• Reporting a share page — tap "Report this page" at the bottom of a share page, or email the link to [email protected]. We aim to review reports within 24 hours and take down links that break our rules (a taken-down link is fully removed from the server 7 days later).
• Who can see it — anyone who knows the link can open it. Labels are included, so send it only to people you are comfortable showing them to.
• Group change sync — while the creator's app is running and online, a group share link reflects members added or removed, display-name changes and updated results at the same address. It keeps the per-link group selection and initials setting, and never transmits birthdays, birth times, or the Hangul name registered for name readings. Offline changes are applied at the next connection. Existing short links are connected once their group is identified, and ambiguous links can be attached to a group by hand in Settings. Long links that carry the results after # in the address, and image files, stay fixed.
• Retention — 180 days after the last time it was opened. Every visit extends it; a link nobody opens is deleted automatically. View counts are tallied so the link can display them.
• Issuer mark — the creator's install identifier is stored with the link so that only the creator can delete it (§4).
• Preview cards — the preview image shown in KakaoTalk and similar apps is drawn from those same result values only.

6. App usage statistics

6-1. The app (4tuneHacker / 포츈해커)

To learn which features are used so we can fix the app, we send a screen name when a screen opens and an action name with its bucket value when you take one of the predefined actions. Screen and action records are kept briefly on the device and sent in batches; a usage summary (heartbeat) is sent separately, once a day. The app sends statistics requests only to pillaxy.com, and our server forwards only the allowed items to the Umami instance we run ourselves.

Only the 14 screen names below are counted. Changing which person or group a screen shows, or returning to the app on the same screen, does not add another screen view. Movement inside a sheet is not counted as a screen view either. When a screen opens, the app may also send the previous screen's name, or a special entry path such as just launching the app, arriving from a notification, or arriving from a deep link.

What we send

That is 46 action names in total (of 48 defined, minus the 2 reserved for report interest and preview, which have no payment feature behind them yet). A share, invite or backup event means an attempt to start; it is not a record confirming that anything reached another person or that a save completed. Copying a conversation does not mean it was used, and a usage note is the user's own self-report. Turning notifications on is likewise a settings change and does not mean a notification was delivered. Some records may be missing because of network errors and rate limits. For fields with a fixed list of allowed values — entry source, sheet type, shape-detail category and the like — we send only one value from that list, and a value that is technically allowed but not actually produced by this app version is not sent, as noted in the table above.

The server reserves two names, for report interest and preview (report_interest · report_preview). No name is reserved for payment. This version of the app has no place that sends them, so they are not collected. We will update this policy before the actual feature ships.

• What we never send — birthdays and birth times; the names, ids and UUIDs of people and groups; the real counts of people and groups; whose page you looked at, edited or deleted; scores, temperament or zodiac results; the sentences, situations, tones, notes or note identifiers of conversations; share and invitation URLs or tokens; anything you typed or searched; precise location, the rounded longitude, solar-time corrections or the location permission state; advertising identifiers; or the fact that you opened a private name-reading or animal-reading screen. We do not log every button press — only the actions listed above are counted.
• How we batch it — screen and action records are kept briefly in the app's memory, then sent together roughly every 20 seconds, once 20 have piled up, or whenever the app goes to the background. If the app closes completely before a batch goes out, whatever had piled up since the last send is discarded, not transmitted. Turning usage statistics off also empties whatever was waiting to be sent.
• Identifier and linkage — our server receives the raw install identifier and sends a persistent secret-keyed hash to Umami. There is no name or account, but the value links screens, actions and summaries from the same app installation, so we do not describe it as fully anonymous. Share links store the same raw install identifier as an issuer mark; our policy and analytics storage keep the share and statistics records separate.
• Retention — new usage records in Umami are kept for 6 months, and a daily cleanup job deletes anything older. Session rows, which carry the hashed identifier and similar fields, are deleted only once 6 months have passed since they were created and no events remain, so session information for an install that is still in use can outlive 6 months. The earlier rules — 30 days for individual records and 180 days after last use for the per-install summary — still apply, but only to what remains in the former D1 store from before the migration.
• When you choose — the "Create my chart" screen carries a "Send app-improvement usage stats" switch, off by default. If you already have a saved explicit choice, it is shown as-is. Turning the switch on creates, at that moment, a consent record on this device with the consent time and consent-record format version; turning it off deletes that record along with saving the new value. A value you turned on is saved when you finish onboarding by creating your chart or restoring a backup, and nothing is sent before then regardless of the switch position. A previous install saved as on with no valid consent record (including one turned on in an earlier version) is treated as off starting with this version, and the switch is shown as off too — you must turn it on again to re-consent before anything is sent.
• How to turn it off — Settings → Data → "Send app-improvement usage stats". Turning it off stops new statistics requests, attempts to cancel any in flight, and discards whatever was waiting in the batch queue along with the consent record. Records that already reached the server are not recalled by this action alone; they are deleted under the retention rules above, or you can delete them sooner with Settings → Data → "Request deletion of sent usage statistics" (§4). The fact that you turned it off is not itself sent. If you turn it back on, a new consent record is created and observation resumes from the current screen; nothing from the period it was off is sent retroactively.

6-2. The website (pillaxy.com)

To know which pages get read, the website counts visits with an analytics tool we run ourselves (Umami, umami.jdsnl.com). It is not a third-party vendor's tool like Google Analytics, and visit records do not go to any ad company. This policy page is counted the same way.

• What we send — page address, where you arrived from (source and campaign markers such as search or social), approximate country, browser and device type, screen size, browser language.
• How addresses and titles are handled — they are cleaned before sending, by these rules. Share and invitation link identifiers (/share/… · /i/…) are collapsed into a single bucket, and everything after # in the address is removed entirely. After ? only the five campaign markers (utm_source · utm_medium · utm_campaign · utm_term · utm_content), the language lang (ko/en/ja/zh/es) and the style style (ko/en) are allowed. Campaign values are allowed only as 1–32 characters of lowercase letters, digits, underscores and hyphens; we do not additionally inspect the meaning of values in that shape to detect and strip personal information. Everything else is removed, and the page title — which could carry a label — is never sent at all. For addresses that came from an external site we keep only the source, such as the domain, and drop the path and query.
• IP address — used to determine the country of access and not stored as such. The analytics tool has no field to hold an IP address in the first place.
• Cookies — none. We do not plant anything on your device to recognise you, so there is no consent banner either.
• Retention — visit records are erased automatically by a daily cleanup job once 6 months have passed. Session information carries the same exception as in §6-1: it is deleted only once 6 months have passed since creation and no events remain, so it can outlive 6 months for a returning visitor.
• How to turn it off — turn on "Do Not Track" in your browser and nothing is collected.

7. Legal basis for processing

Usage statistics are processed on the basis of your consent — you consent by turning on the switch, on the onboarding screen or in Settings, and finishing onboarding, and you can withdraw at any time in Settings (§6).

The "Add a friend" web relay, "Tell a friend my birthday" direct sharing, and creating a share link are processing to perform the exact feature you asked for by tapping the button on that screen. They do nothing unless you take that action, and we use them for no other purpose (§3, §3-1, §5).

8. Your rights and how to exercise them

Reporting — report an unwanted invitation reply with "Report" in the review list, and a share page with "Report this page". The report email is prefilled only with the label and the date received, never a birth date or time. We aim to review reports within 24 hours.

You can request to access, correct, delete, restrict processing of, or port the information we hold, or withdraw consent.

• What you can do right in the app — deleting a person or conversation note, deleting a share link, turning off usage statistics (withdrawal) and "Request deletion of sent usage statistics" are all handled in the app. See §4 for details.
• Other requests — write to [email protected] and we will respond within 10 days (one month for EU residents) after we confirm your request. The app has no accounts, so we have no way to identify you — include what is needed for us to answer (device type, the screen involved, and so on).
• Filing a complaint — in Korea, you may contact the Personal Information Protection Commission (privacy.go.kr) or the Privacy Infringement Report Center (privacy.kisa.or.kr, 118 within Korea). EU residents may contact their local data protection authority.

9. International transfers

Some processing runs on the global network of Cloudflare, Inc., headquartered in the United States.

• Recipient — Cloudflare, Inc. (servers and databases run on Cloudflare's global network, including the United States).
• Items transferred — the install identifier, usage-statistics items (§6), data created by invitation relay and share links (§3, §5), and the connecting IP — each limited to what that specific feature actually uses.
• When and how — transmitted over an encrypted network connection the moment you use that feature in the app or on the website.
• Purpose — operating the invitation-relay, share-link and usage-statistics relay servers.
• Retention — each item's retention period follows the section that covers it (§3, §5, §6).
• How to refuse — turn off usage statistics in Settings (§6), or simply do not use the invitation or sharing features.

The analytics tool that stores usage statistics (Umami) is run directly by the operator in Korea, separately from Cloudflare, and is not transferred abroad.

10. Data protection contact

• Responsible — 4tuneHacker operator (representative), data protection contact
• Contact — [email protected]

4tuneHacker is run by a single operator, who serves directly as the person responsible for personal information protection. Questions, access or deletion requests, and complaints about this policy or how personal information is processed go to the contact above; reply times follow Section 8.

11. Notice to California residents

Under the California Consumer Privacy Act / CPRA, we have collected the following categories of information over the past 12 months.

• Identifiers — the install identifier
• Internet or app activity — screen and action records if you enable usage statistics (§6)
• Approximate location — the country derived from the connecting IP
• User-provided content — labels you type or choose for invitations and shares

We do not sell personal information, and we do not share it for cross-context behavioral advertising. You have the right to know, to delete and to correct, and the right to non-discrimination for exercising these rights. See §8 for how to exercise them.

12. Children

4tuneHacker is not directed to children. We ask that anyone under 14 not turn on the usage-statistics switch without a guardian's consent (§6). If we learn that a child's personal information was collected, we delete it without delay.

13. Backup files

Automatic backup is on by default from app version 1.0.2, build 30. After setup, the app saves a backup in its private storage on the first eligible launch or return from the background each device-local day. It keeps the latest seven backups. No backup is created on days when you do not open the app, so copies may remain for more than seven days. Backups include saved people's birth details and labels, your optional Hangul name, groups, saved conversation records and modes, and invitation-link credentials. Pending friend replies, tutorial sample data, recently copied items and usage-statistics consent records are excluded.

Deleting a person or record does not remove it from earlier automatic backups. Use “Delete all automatic backups” in Settings, or turn automatic backup off, to delete the app's copies. If deletion fails, the app shows an error and retries on a later launch. Deleting the app removes its internal copies. Exported files and copies in operating-system backups must be managed separately.

Automatic backup does not send backup contents to our servers. On iPhone, copies may be included in an iCloud or Finder device backup, depending on your settings; this is separate from app cloud synchronization. Android system backup and device transfer exclude the app's data. Exporting a file sends it to the destination or service you choose.

The app can also export your data to a file in case you change devices. You create and keep that file yourself. The most recently copied item is excluded from backups. Nothing is transmitted to a 4tuneHacker server by the backup feature.

A registered name is deleted by tapping "Remove the registered name" on the edit screen for your own chart and saving. Backup files you already exported have to be deleted separately. Restoring a backup never overwrites an existing name; it fills one in only when the same person identifier has none.

14. Security

App data is held in the operating system's per-app sandbox (iOS, Android), protected by the device lock and OS-level encryption. Communication with the relay server is always encrypted with HTTPS.

15. Third parties and processors

We do not provide or sell personal information to third parties, and we do not use it for advertising or marketing. The servers and databases behind invitation relay and share links, and the relaying of app statistics, run on Cloudflare infrastructure (see §9 for the scope of the international transfer). Storage and aggregation of app and web usage statistics are handled by the Umami instance we run ourselves (umami.jdsnl.com). Statistics remaining from before the migration are deleted from the former D1 store under the existing periods (§6-1), and outside the purposes in §3, §5 and §6 above we neither keep nor use any data.

16. Changes to this policy

When features grow and the information we handle changes — for example, purchase records keyed to an install identifier once paid features arrive — we update this page first and raise the effective date and version. Birth details are not stored on our server except for the consented invitation relay described in §3.

• v19 (2026-10-06) — Documents on-device automatic backups starting with app 1.0.2, build 30, their seven-copy limit, included and excluded data, and deletion controls. It distinguishes operating-system device backups from file export. Usage-statistics consent is unchanged.
• v18 (2026-10-02) — Invitation replies now wait in a review list until the inviter chooses to add them (app 1.0.1 build 27 or later). This explains ignoring or reporting replies, closing invitation links and reporting share pages. Share links are created only when the user taps Share a link. Usage statistics and the consent record are unchanged.
• v17 (2026-10-01) — The app no longer accepts Hanja for names and no longer includes a Hanja dictionary. Name readings now use only the sound of the name written in Hangul. On the first normal launch of the updated app (iOS build 26 or later), previously saved Hanja is removed from the app's name storage data. An earlier backup you exported yourself may still contain Hanja; restoring it in the new app does not import Hanja. Usage statistics and the consent record are unchanged.
• v16 correction (2026-10-01) — Corrected the location-setting statistics disclosure, setting-change event, consent-record description and feature names to match the app. The collected items, purposes and retention period have not changed.
• v16 (2026-09-27) — Changed the usage-stats switch back to off by default; turning it on now creates a consent record on the device with the consent time and policy version. An install already saved as on before this version with no consent record is treated as off and must be turned on again to re-consent. Added "Request deletion of sent usage statistics" to Settings → Data (§4). Added Legal basis for processing (§7), Your rights and how to exercise them (§8), International transfers (§9), Data protection contact (§10), Notice to California residents (§11) and Children (§12).
• v15 (2026-09-26) — Changed the usage-stats switch to default on; new installs send unless you turn it off during onboarding; an install already saved as off, or an existing install with no saved choice, stays off.
• v14 (2026-09-26) — Added to app usage statistics: screen dwell time; app open and session length; sheet opens; entry sources for notifications, deep links, and opening a person/pair/today's-chemistry/shape screen; tutorial progress; feature actions (graph style, relation toggles, people search and more) and setting changes; device type, OS version (major version on iOS, API level on Android), build number and text size; and finer usage-summary fields (demo data present, tutorial state, language preference, whether a display name or name reading is registered, share-link and conversation-note count ranges, days since install, and more). The number of action names grew to 46, and screen/action records are now briefly queued on the device and sent in batches (§6). What we never send is unchanged.
• v13 (2026-09-21) — Made app usage statistics explicit opt-in and off by default; clarified device linkage of the install identifier, the direct-send and invitation-relay paths, and deletion scope for local, server and external copies.
• v12 (2026-09-20) — Added user-initiated sending of saved birth details (§3-1), the 4tuneHacker name and Spanish in the language list.
• v11 (2026-09-19) — Anonymous usage statistics are now chosen with a switch on the first-run screen, and nothing is sent before onboarding is finished (§6-1). Added the contact section (§11) and this English page.
• v10 (2026-09-10) — Documented group share link change sync and the items not transmitted during it (§5).
• v9 (2026-09-08) — Documented on-device storage and dictionary lookup for the optional Korean name and Hanja, the name reading, what deletion and backup restore cover, and their exclusion from invitations, shares and statistics.
• v8 (2026-09-08) — Moved the location control to Settings and documented the on-by-default setting stored on the device. Reflected the one-shot location check on entering, returning to the screen, or after expiry, the first permission request, and the no-repeat rule after a decline.
• v7 (2026-09-08) — Documented the in-memory handling, 15-minute lifetime, clearing conditions, and exclusion from transmission and permanent storage for optionally applying the current location to today's time periods. Location, its derived values and the permission state are not sent as usage statistics.
• v6 (2026-09-08) — Documented the conversation helper's on-device notes, person identifiers, 7-day copied item, deletion and backup scope. Updated to 14 app screens and 17 actions, and documented that conversation contents and notes are excluded from server statistics.
• v5 (2026-09-07) — Added "My chart today", opened from the People tab, bringing supported app screen names to 12. What is sent, retention and how to turn it off are unchanged from v4.
• v4 (2026-09-07) — Documented 11 app screens and 12 actions, the excluded items, relaying to and storage in Umami, the 6-month retention and its session exception, and the scope of turning statistics off and of deleting the app. Added style to the allowed web query items.
• v3 (2026-09-07) — Added website visit statistics (§6-2). Reworded §2 and §9 to match how the self-hosted analytics tool actually works. What the app sends did not change.
• v2 (2026-09-06) — Added server storage, retention and deletion for share links (§5), anonymous usage statistics (§6) and deletion methods (§4). Reworded to match actual behaviour.
• v1 (2026-08-25) — First publication.

17. Contact

If you have a question about this policy or about how data is handled, or you want something deleted, write to us. The app has no accounts, so we have no way to identify you — include only what is needed for us to answer.

• Email — [email protected]
• Common questions — support page

For things you can do inside the app right away, such as deleting a share link or a person, see §4 first, and see §8 for how to exercise a right such as access or correction.