Amended Privacy Policy, applicable from November 24, 2026, 00:00 KST. The current Policy remains applicable before that time.
Planned notice: November 9, 2026. Comments and objections: until November 23, 2026, 23:59. Planned commencement: November 24, 2026, 00:00. All dates and times are KST (UTC+9). Delayed notice requires adjustment preserving the current notice and objection periods.
See the amendment comparison.
Techclip (the “Operator”) processes the minimum personal information necessary to provide Musecat under the Korean Personal Information Protection Act and other applicable law. This Policy covers members and non-members using the web and apps, community, support and external integrations. Function-specific provisions apply when that function is provided and used. New data, purposes or recipients require updated disclosures and necessary consent before processing.
This Policy discloses processing practices. Reading it or accepting the Terms does not constitute consent to optional collection, third-party disclosure or overseas transfer.
The table describes proposed processing by function. Optional functions do not require their information unless used. Users should not enter unnecessary resident registration numbers, health information or other people’s personal information in free-text fields.
Social-login providers’ own processing follows their policies. The Operator remains responsible for information received and processed by Musecat. Google users may also consult Google’s Privacy Policy.
To prevent automated bulk collection of arcade details and excessive requests, Musecat calculates read and request limits and prevents reuse of additional-read verification. It uses the authenticated account ID and reads join date and XP level for members; guests are identified by their actual client IP. State is stored even in observation mode, which evaluates limits without enforcing restrictions. This is not physical-visit verification or a long-term visit history.
Private state contains arcade IDs, first-counted times, additional-read usage, request counts, account/IP/session bindings and issue, use and expiry status of challenges and permits. Repeat reads of the same arcade do not count as another arcade. IP and quota keys use HMAC identifiers but remain linkable and are not anonymous. Challenge and permit records also contain untransformed member account IDs. The bases are necessary security processing for performance under Article 15(1)(4) and legitimate interests under Article 15(1)(6), considering abuse-prevention necessity, limited data/validity and individual rights safeguards. These bases do not authorize advertising or long-term behavioral analysis.
Additional-read verification uses Cloudflare Turnstile. Musecat sends the verification token and raw IP to Siteverify, without storing the token itself in its read-state database. Sections 7–8 describe external processing.
Handles, nicknames, disclosed profiles, public posts and arcade revision history may be viewed by others or found through external search. Favorites, visits and external records follow each function’s visibility. Defaults and displayed fields must be ascertainable; new disclosure of private data requires appropriate information and choice.
Emails, credentials, private messages and inquiries are not public profile fields. Messages reach recipients; arcade/team inquiries reach authorized staff. Operational access for reports and troubleshooting is limited to necessity.
Plaza text, photos and author information are available to other eligible members. A plaza accessible without separate joining is not private one-to-one messaging. Leaving or clearing local history does not automatically delete server posts. Sections 4–5 govern retention/deletion.
Externally displayed or distributed posters and QR outputs may expose text, images and destinations. Server-submitted download material and user identification must be distinguished from editing data processed only on-device.
Personal information is processed until the period or end event below and destroyed without undue delay once its purpose ends. Minimal records needed for a specific dispute or statutory preservation are segregated with their basis, data and end point. Free operation does not waive destruction duties.
Expired state is not used for quota/verification. Up to 10,000 expired rows are cleaned every 15 minutes. Other reads may renew a row and retain an earlier entry for almost two hours; queues, outages or volume may delay physical deletion further. Neither the 60-minute window nor cookie expiry is a complete server-deletion deadline. Failed cleanup is retried after recovery; deletion requests are handled separately.
PocketBase access logs have a 5-day setting, with IP logging enabled and authenticated account-ID logging disabled. Restriction events record tier/path/reason/mode. Separate proxy/container operational logs remain through service operation/troubleshooting and log rotation; linkable fields, including raw IP, are subject to destruction/restriction requests. Read-state TTL does not delete other logs.
Backups retain the latest 15 daily copies and, separately, the latest 24 verified hourly copies. These counts do not promise deletion after exactly 15 days/24 hours; creation outages may leave older copies. Separate deployment-verification copies become destruction candidates when verification/recovery ends and are not indefinite archives.
Records shall be identified and destroyed so recovery or reproduction is difficult. Paper shall be shredded or incinerated. Legally retained subsets shall be segregated and access-restricted.
Users may request deletion through available controls or Support. Processing time for backups or collaborative records requires specific scope and deadlines, not indefinite retention.
App-specific notices shall be finalized using the connection notice draft.
Disclosure requires a legal basis or necessary separate consent. Authority requests shall be checked for requester, legal basis and scope; a mere request does not justify indiscriminate disclosure.
“External developers” collectively is not a sufficient recipient description. Future apps and new data are not covered by blanket consent. Reading and writing permissions must be distinguished. The table is not itself a valid completed disclosure-consent form before actual details are finalized.
Ordinary entrustment alone does not require separate consent. Underlying processing requires a lawful basis; the Operator provides processor/task disclosure, contracts, safeguards and supervision. Statutory individual-notification duties remain applicable.
External SMTP delivery of ordinary service email is not currently used. Social-login providers independently process their own account-service data under their policies. New processors/purposes require updated disclosures before processing.
The Turnstile notice distinguishes site-protection entrustment from independently determined detection improvement. Musecat uses the minimum necessary security scope and provides the provider’s rights contact for independent processing. Turnstile use is not approval for advertising, profiling or disclosure to other apps. Entrustment is subject to purpose restrictions, safeguards and return/deletion protections under the Cloudflare DPA.
Necessary overseas entrustment/storage for entering into or performing the user contract follows Article 28-8(1)(3), including statutory disclosure or notification. No blanket renewed-consent popup is required solely for that processing. Where neither this nor another lawful transfer basis applies and transfer relies on consent, obtain separate consent before transfer. Independent third-party disclosure requires its own lawful basis.
Musecat state validity is not Cloudflare retention. Provider changes require updated disclosures and legally required further notification/consent. Verification is not blanket approval of disclosure to other apps.
Discovery may use the current or selected reference location. Visit verification may process coordinates, accuracy and results. A search reference is not necessarily the actual current location or a verified visit.
If identifiable location information is used, applicable legal status and registration duties must be assessed and required separate terms and consent provided. The responsible location officer/contact, purposes, periods, third-party disclosure, verification logs, destruction and rights must be specifically disclosed. Device permission does not replace those requirements.
Users may refuse or revoke device access. Location-dependent discovery or verification may be unavailable, while other functions remain usable. Publishing visits is separate from location permission. Coordinate transfers to map/directions services require assessment of sender, data and necessary consent before use.
Address/region search and reverse geocoding may use server-side provider requests. Nearby-location free search/reverse uses OpenStreetMap Foundation’s Nominatim; other paths may use Kakao Local API or Google Maps Geocoding according to region/mode. Requests contain query/address or coordinates and language/region, without adding member ID, email, personal authentication tokens or the visitor’s raw IP. Providers may process Musecat’s requesting-server IP and request contents.
Independent provider processing is not automatically Musecat entrustment. Personal or personal-location data requires its applicable processing/disclosure/transfer basis and statutory procedures, including separate consent where required; device permission or Policy publication is no substitute. Declining external conversion may limit search/reverse geocoding while ordinary arcade-list viewing remains available.
Musecat’s geocoding cache is valid for 24 hours; expired items are excluded/deleted when looked up again. Size bounds, restart and cache reset also clean records; validity is not the exact destruction time of every memory copy. Opening an external map/directions service sends the selected destination and permitted origin, subject to that provider’s policy.
Disclosure by Musecat and receipt of external records shall be explained separately. Source, data, purposes and retention must be disclosed before import, with required consent. Bilateral approval does not combine or enlarge each direction’s permissions.
After disconnection, new requests shall stop, permissions shall be revoked and unnecessary credentials and records destroyed under finalized rules. Separate deletion requests and legal preservation duties shall be distinguished. Users shall be given the external operator’s contact and route to request deletion of delivered records.
Cookies or device storage may maintain login, security, language and display settings. Browser privacy/site-data controls allow deletion or blocking. Blocking authentication cookies may restrict login-dependent functions.
Major cookies are listed below, distinguishing authentication/security and requested functions from preferences.
On-device drafts/display caches can be cleared through function reset/deletion or browser site-data controls. New advertising or other-purpose tracking requires separate information about collectors, fields, periods, refusal and required consent. Reading the Policy or login is not advertising/tracking consent.
Self-hosted Umami processes page URL/title/referrer, access time, browser/OS/device/screen, approximate region and transformed session identifiers for usage statistics. IP is processed for session/approximate-location calculation but is not stored as a raw-IP field in standard analytics records. Transformation is neither guaranteed anonymization nor automatic deletion. Records remain until comparative-statistics purposes end or preservation assessment for a deletion request is complete. This is not entrustment to Umami Cloud.
Production web cookies use HttpOnly, Secure and SameSite=Lax. Deletion or blocking may impair verification or permit persistence without resetting account/IP base quotas. Cookie expiry differs from server destruction under Section 4. Disclose Turnstile storage/cookies after checking provider documentation and the actual widget configuration; do not imply that every Cloudflare product cookie is used.
Camera, selected photos and files shall be accessed only as needed for requested capture, attachment or output saving. Location permission supports disclosed discovery or field verification. Permissions can be changed in device settings; refusal of optional access may limit only the relevant function. Permission does not authorize uploading every photo or file.
Apps and browsers may store authentication, settings, drafts and display caches. Server-transmitted information follows Sections 2 and 4; device-only preferences, drafts and caches can be cleared through function reset or device/browser site-data controls. Uninstalling does not itself delete server accounts or data. Operating-system backup and restoration residuals must also be assessed.
Push uses account-linked device identifiers and tokens. Receipt can be managed through app and OS settings. Opt-out, logout or account deletion stops use of the registration, and unnecessary information is destroyed. OS permission is not marketing consent.
SDKs and push providers may also process data. Entities, fields, purposes, periods and transfers introduced with SDKs are disclosed before actual use. SDK introduction alone is not blanket consent for new purposes.
Account-creation apps must offer in-app deletion requests and external web requests where platform rules require them. Deactivation or renamed profiles are not deletion. Related destruction and minimal lawful retention follow Sections 4–5.
Individuals may request access, correction, deletion, restriction and consent withdrawal; authorized representatives may act on their behalf. Applicable statutory portability and rights to reject, explain or review fully automated decisions may also be exercised under their legal conditions.
Use profile controls or Support. Only minimal verification shall be requested and statutory deadlines observed. Restrictions or refusals require legal grounds, reasons and appeal information. Use and disclosure of contested information shall be restricted during legally required correction/deletion handling.
Levels or points are not automatically legally defined automated decisions. Any fully automated decision materially affecting rights or obligations requires assessment and, where applicable, disclosure of criteria, procedures and rights.
Support also accepts access, correction, deletion or restriction requests concerning read-protection state and inquiries about incorrect limits. Limits are calculated automatically using join date and XP level or guest IP; sharing an IP may affect restrictions. Assess each request and applicable rights and explain the result.
Musecat does not accept member registration by children under 14 without the required parental consent/verification procedure. If processing of a child’s information is discovered, take lawful account restriction, processing suspension and deletion measures. Authorized parents may exercise rights through Support.
The Operator applies minimum necessary access, authentication/control, credential protection, transport security, restricted private storage/recovery copies and log management. Staff handling deletion identify original records, linked records and copies; hashes or renamed profiles are not presented as complete destruction.
Incidents require containment/recovery and statutory individual notification and regulatory reporting under applicable conditions/deadlines. Distinct external-app roles do not remove the Operator’s own duties.
The privacy officer is Baek Seung-hoon (백승훈), Team Leader. Privacy inquiries, rights requests and objection to the Terms amendment can be submitted through Musecat Support. General inquiries require neither registration nor login and are available after withdrawal. Reply email is optional; guest inquiries are retrieved using the browser’s inquiry cookie. If it is lost or another device is used, contact staff with minimal identifying details such as submission time/content.
Individuals may seek assistance from the Personal Information Dispute Mediation Committee or Personal Information Infringement Report Center.
This amendment was prepared on November 5, 2026. The current Policy took effect on July 1, 2024. Planned notice is November 9, 2026; comments and objections close November 23, 2026, 23:59; planned commencement is November 24, 2026, 00:00, all KST (UTC+9). If notice is delayed, announce adjusted commencement preserving current notice/objection periods.
Changes and dates shall be announced. Separate consent required for new purposes, optional data, disclosure or transfers shall be obtained separately from publication. Refusal shall not unfairly restrict unrelated basic functions.
Bulk-read protection is already deployed, and observation mode stores state. The planned Policy commencement is not its first collection date, and later publication does not retroactively establish legal grounds or satisfy prior notice duties. This Policy distinguishes current facts and legal bases; publication does not waive legally required separate consent or notification.
English and Japanese versions are convenience translations. The Korean version is the reference where meanings or interpretations differ, without excluding mandatory applicable law or statutory rights.