OwnRemote Privacy Policy

This is the policy for the trial. OwnRemote is being tested, and this policy is a draft not yet reviewed by a lawyer. Items still in brackets ([ ]) will be filled in before the public launch, and the content may change. Changes will be announced on this page.

Article 1 (Read this first: the Company does not see your screen)

The video and sound of your PC's screen, and the input sent from your phone (touches, text, microphone sound, clipboard text), travel between your PC and your phone encrypted (WebRTC, DTLS-SRTP).
Even when a direct connection is not possible and the traffic passes through the Company's relay server, the Company cannot decrypt it. The relay server forwards the encrypted data and counts only its volume (number of bytes).
The Company does not store screen content, sound, input or clipboard content.
Your PC PIN never leaves your PC. The phone proves to the PC that it knows the PIN using a method that does not send the PIN (SPAKE2). The Company's server receives neither the PIN nor any value derived from it, and cannot set or turn off the PIN (Article 3).

Article 2 (Personal information the Company processes, and why)

The Company does not collect names, phone numbers, postal addresses, resident registration numbers, location information, advertising identifiers or device identifiers. Sign-up takes an email address and a password, and the email address is confirmed with a code the Company sends to it. The only emails the Company sends are confirmation codes (sign-up, password reset, email change) with the notes that go with them, and notices about the Service that are strictly needed (breach notices, changes to the terms and the like); it sends no marketing email. The ID that identifies the account inside the server is generated by the Company (a part derived from the email address plus random characters). Accounts created before email accounts sign in with the user ID the user chose until they add an email address. If the user chooses, they can also sign up and sign in with a Google account or a Kakao account ("Information received from sign-in providers" below).

Category	Items	Purpose	When
Account	Email address and when it was confirmed, user ID (generated by the Company, or chosen by the user before email accounts), password hash (Argon2id — the password itself is never stored), sign-up time, account status (active/suspended), the number of PCs the account may register	Sign-up, sign-in, identity verification (email confirmation), password reset, notices about the Service (security and breach notices and the like)	When signing up on the website (or when an operator creates the account), and when the user changes the email address
Email confirmation codes	A hash of the code (HMAC — the code itself is never stored), what the code is for (sign-up, password reset, email change), when it was made, the number of wrong tries. Records for counting the sending limits (the address sent to, the IP address of the request, the time)	Confirming that an email address belongs to the user, preventing code guessing and mail abuse	When a code is requested
PC	PC name, PC identifier, hash of the PC authentication token, last connection time, program version and file hash, certificate fingerprint, PC settings (policy)	Registering PCs, brokering connections, update notices, verifying the PC	When a PC is registered and connects
App list	Name, executable path and arguments of each app the user registers (a path may contain the Windows user name), icon, per-app settings	Showing the app list on the phone and launching apps	When an app is registered
Live connection information	Whether a PC or phone is connected, the server it is connected to, the PC's direct-connection address (local IP address and port) and certificate fingerprint, the PC's app list (if the user turns on "show open windows", also the titles and executable names of the windows open on the PC), the PIN information the PC announces (whether it has a PIN, the version of the PIN method, the salt — a non-secret value)	Letting the phone find and connect to the PC	Kept in the server's memory and connection table only while connected; deleted when the connection ends
Session records	Session times (start and end), PC used, user ID (for sessions made directly to the PC, the name signed in to that PC), route (through the server / directly to the PC), whether a relay was used, number of bytes relayed, amount charged for the session	Billing, usage history, incident response	Every session. For sessions made directly to the PC, the PC reports them when they end
Window choices	What the user picked on the phone as "the app's window": the file name of the program the app starts, the chosen window's program file name, its kind (window class), its relation to the started program (the program itself, started by it, same folder, already running, other), and its program's signer (when there is one). Never the window title	Opening the same window on all the user's PCs next time without asking	When the PC cannot tell an app's window, the phone asks "Which window is it?" and the user picks one
Window-detection statistics (anonymous, can be turned off)	The file names of the started program and of the chosen window's program, their relative paths only when they are under Program Files or the Windows folder, the SHA-256 hash of the program file, its signer, file version, window class, relation, who decided (the user / the PC's own rules), the number of candidates, and the date (no time). Not linked to the account, PC or IP address. Window titles, document names and paths in the user's folders are removed on the PC and never sent	Improving the automatic detection of app windows	When the user picks a window, or when the PC decided with low confidence. Not sent when the user turns it off
Direct-connection statistics	Connection path (same network / direct over the internet / relay), bytes exchanged, session length, video codec (AV1/VP9), resolution band (720p or lower / 1080p or lower / higher), time received. For same-network and direct-internet sessions a pseudonymous value instead of the user ID; for relayed sessions the account and session number	Improving service quality, planning prices and server capacity	Sent by the PC when a session ends
Billing	Top-up, deduction, adjustment and refund history (amount, time, reason), balance, payment ID, gross payment amount, tax, net amount and currency, payment fee, country of payment (only when Paddle provides it)	Prepaid top-ups and deducting relay charges, settlement, refunds, tax	On top-up, relay use and refunds
Wrong PC PINs	For each PC, the number of wrong PINs (since the user last acknowledged), when the last one was, when a lock ends, the streak count	Letting the user know someone is guessing the PIN even when away from the PC, preventing account takeover	When the PC reports it, from the 3rd wrong PIN in a row and at every lock. Cleared when the owner clicks "Got it"
Security records	Successful and failed sign-ins (the email address or user ID entered), email confirmations and email changes, password resets, wrong email codes (the email address entered), operator two-factor authentication, PC registration and pairing-code attempts, forged and expired tokens, blocks and unblocks, wrong PC PINs (`pc_pin_failed`) and their acknowledgement (`pc_pin_alert_ack`), payment notifications, account deletion, diagnostics sent and opened, social sign-ins, their refusals, linking and unlinking (`social_login`, `social_login_fail`, `identity_linked`, `identity_unlinked`: only the provider is recorded, not the email address or the provider's tokens), operators' administrative actions — time, user ID, IP address, reason	Preventing account takeover and attacks, investigating incidents	When such an event occurs
Server logs	Request time, IP address, the address requested, the kind of browser or app (User-Agent, in the web server's access log), user ID or email address (sign-in, sign-up, PC registration, sending mail and so on), error details (passwords and tokens are never logged)	Incident response, security	While the Service is used
Diagnostics (only when the user sends them)	The PC program's recent log (about the last 1.5 MB, and 256 KB of the setup log; it may contain times, the executable names of apps, and session and connection errors), the program and Windows versions, the CPU and graphics adapter names, the PC name and identifier, the program's settings (policy, names and executable names of registered apps, numeric settings). The connection token, passwords and their hashes, certificates' private keys, the PIN file and apps' executable paths are left out; paths in the log are cut down to the file name; the Windows user name in paths, the names used to sign in to direct access and anything that looks like a token are masked; and of IP addresses only the kind (local, public and so on) is kept. The screen, window titles, typed text and clipboard content are not in the log to begin with	Customer support the user asked for (finding the cause of a problem)	Only when the user clicks "Send diagnostics" in the PC's notification-area menu, reads what will be sent and clicks "Yes". Never sent automatically
Support records	Time, PC and reason (a short word set by the Company's server) of connections that did not start. Hashes of authentication tokens a PC no longer uses, with that PC, why and when they changed. Why and when a PC's connection ended (quit, Windows shut down, sleep, connection lost and so on). The phone app's kind (android) and version and when it last connected. The PC's network conditions (the kinds of connection candidate and the NAT judgement of its last session, whether it connects from a public address, its direct-access state)	Answering enquiries that a connection does not work, finding faults	When a connection is requested, when a PC or phone connects or disconnects, when a session ends
Social sign-in links (only if the user chooses)	The provider (Google or Kakao), the unique number the provider gives that account (Google's account ID `sub`, the Kakao member number), the email address the provider gave, when the link was made	Sign-in, linking to the account with the same email address	When the user clicks "Continue with Google" or "Continue with Kakao" and agrees on the provider's page
Operator two-factor authentication	Authenticator-app secret (stored encrypted), hashes of recovery codes	Protecting operator sign-in (operator accounts only)	When an operator sets it up
Inquiries and reports (only what the sender gives)	The contact the inquiry or report came from (an email address or whatever the sender chose), its content, any user ID or PC name the sender included, how it was handled. For an abuse report: the reported account and those of its security and session records the investigation needs	Answering inquiries; investigating and acting on reports of abuse such as fraud or unauthorised access (Terms Article 5-2); handling disputes	When a user or anyone else writes to [Inquiry and report contact]

Window-detection statistics are not linked to the account. The server does not store individual votes: it only counts votes with the same features per date, in a table that has no account, PC, IP address or time. So that an account counts once per app per day, it keeps a value for that day only (an HMAC made with the server's key), deleted within an hour after the day ends. To estimate how many people voted on an app it marks one of 256 slots, which cannot tell which account voted. Users can turn it off at any time with "Don't send window-detection statistics" in the phone app's "Window choices" menu and in the web console's "Settings" (on by default). Once off, the PC neither makes nor sends them, and the server does not accept them.
Direct-connection statistics contain no IP addresses. Instead of the account, they store a pseudonymous value: an HMAC computed from a key only the server holds and the current month, so it changes every month and only shows whether two records within the same month come from "the same user". (Because the Company holds the key, it can recompute the pseudonym of a given account; this is therefore pseudonymization, not anonymization.) Records of relayed sessions, however, are linked to the account, because of billing. The monthly totals contain neither accounts nor pseudonyms.
Diagnostics are opened only by the operators who handle customer support. Each time an operator opens one, who opened it and when is kept in the security records. Users can download what they sent, and delete it, in the web console on the PC's page under "Diagnostics sent".
Support records contain no IP addresses, and no error text sent by the PC or the phone. Operators see them only on the customer-support page, and every opening of that page is kept in the security records. The phone app sends no device identifier.
Update check: a phone app downloaded directly from the website asks the Company's server for the number of the latest version once each time the app is started, after sign-in (a request that carries no sign-in or account information). If there is a new version it says so, and if the user taps "Download", the phone's browser downloads the installation file (APK) from the Company's website. Android asks for and verifies the installation. An app installed from Google Play does not make this check and is updated through Google Play. For this request too, the server logs keep the IP address and time.
The public address told to the PC: when a PC connects to the server, the server tells the PC the public IP address that connection comes from (to guide direct access). This address is used only while connected and is not stored.
The Company does not use advertising or analytics tools (SDKs) or crash-reporting tools.

Information received from sign-in providers (2026-10-10). If the user chooses "Continue with Google" or "Continue with Kakao", the provider gives the Company the following, within what the user agreed to on the provider's page.

Provider	Received	Received but not stored	Contact
Google LLC (USA)	The Google account's unique number (`sub`), its email address, whether Google has verified that address	Google's access and ID tokens. The web sign-in does not request the name and profile picture (scope `openid email`). The ID token the phone app's Google sign-in (Credential Manager) gives does contain the name and picture; they are not stored and are discarded with the token	[Google privacy contact] (to be confirmed) · https://policies.google.com/privacy
Kakao Corp. (Republic of Korea)	The Kakao member number (`sub`), the Kakao account's email address, whether Kakao has verified that address	Kakao's access, refresh and ID tokens. The nickname and profile picture are not requested	[Kakao privacy contact] (to be confirmed) · https://www.kakao.com/policy/privacy (to be confirmed)

Purpose: sign-in and account linking. The provider's unique number and the email address are linked to the account, and from then on that number signs the user in to the same account.
Linking rules: (1) if the provider account is already linked, the user is signed in to that account. (2) Otherwise, if an account has the same email address as the one the provider verified, the provider account is linked to it automatically (the provider has confirmed who owns that address). (3) Otherwise a new account is created after the same consent step as /register (Terms, this policy, 14 or older). That account has no password; the user can set one through "Forgot your password?". The account's email address is the one the provider verified.
Tokens: the tokens the provider gives are used once to confirm the information above and then discarded. The Company does not use them to access the user's Google or Kakao account again.
Unlinking: users can unlink in "Settings" in the web console. Unlinking is refused if it would leave no way to sign in (no password and no other link).
What the user does on the provider's page (signing in, consenting) and the records the provider keeps itself are governed by that provider's privacy policy. What the Company sends to the providers is set out in Article 7(5).

Article 3 (Information kept only on the user's devices)

The following is stored only on the user's PC and phone and is not sent to the Company's server.

PC
- The PC PIN is not stored. Only a value derived from the PIN with Argon2id and a salt (a random value) are kept, in a file only the PC's user can read. Whoever has this file can try to guess the PIN, so the user must keep the PC's Windows account safe (Terms, Article 6).
- The count of wrong PINs and the PC's direct-access records (the name signed in, PIN success, failure, setting and clearing, times, the connecting address) stay in files on the PC (up to 5 files of 10 MB, oldest deleted first).
- The program's log (errors and status, executable names; it may contain sign-in names and addresses; up to 4 files of 10 MB). Only when the user sends diagnostics does part of it go to the Company, masked as in Article 2.
- The result of the measurement that decides whether this PC uses AV1, with the CPU and graphics adapter names at that time (it goes with diagnostics when they are sent).
- The PC authentication token, the certificate for direct access and its private key, and the copy of settings received from the server.
Phone (Android app) — kept in the app's private storage and excluded from Android backup and device transfer.
- The last server and PC addresses and email address (or user ID) for the sign-in screen, settings (microphone, clipboard sync, screen size and so on), the PC list the server provided (name, local IP address and port, certificate fingerprint — to connect directly to a PC when the server cannot be reached), and the certificate fingerprints accepted when connecting directly to a PC.
- The sign-in token is kept in memory only while the app is running, and never saved.
- Sign-in with Google uses Android's account picker (Credential Manager, Google Play services) to show the Google accounts; the app receives the ID token of the account the user picks and sends it once to the Company's server. The app does not save that token. Sign-in with Kakao goes through Kakao's sign-in page in a browser tab opened inside the app (Custom Tab) and returns to the app. The Kakao sign-in state (cookies) in that tab belongs to the phone's browser and to Kakao. The app contains no Kakao SDK.
- If fingerprint/face sign-in is turned on, the password is kept encrypted with a key in the Android Keystore. That key opens only after a strong biometric check each time, and becomes unusable when new biometrics are enrolled. The app never sees or stores fingerprint or face data (Android checks them).
- If "Remember with fingerprint" is chosen for a PC PIN, not the PIN but the value derived from it is kept for each PC, encrypted the same way with a second Keystore key. If not chosen, it is kept in memory only while the app is running.
- For each PC, a non-secret note that "this PC has proved a PIN before". It is there so that if a PC suddenly stops asking for its PIN (someone may have turned the PIN off, or the connection may have been intercepted), the app asks the user before connecting.
- Signing out deletes fingerprint sign-in, the remembered PIN values and the PIN notes. Uninstalling the app deletes everything.
Permissions of the phone app: internet, network state, microphone, biometrics. The microphone is used only when the user turns it on in a session (off by default), and its sound goes only to the PC. Clipboard sync (on by default, can be turned off on the session screen) moves clipboard text between the phone and the PC only during a session, and does not send text Android marks as sensitive. The camera, location, contacts and notification permissions are not used.

Article 4 (Retention period and destruction)

Item	Retention period
Account (including the email address), PCs, app list, wrong PC PIN records	Until the account is closed or the item is deleted. Deleted items are erased immediately
Social sign-in links (provider, unique number, email address)	Until the user unlinks or deletes the account; erased at once then
Accounts whose email was never confirmed	7 days after sign-up; deleted if the code has not been entered by then
Email confirmation codes	10 minutes (invalid at once when used or when a new code is issued). The records for counting the sending limits: [while the limits are counted (1 hour), to be confirmed]
Records of sent mail kept by the mail provider (Resend)	[Resend's retention] (to be confirmed) (Article 6)
Live connection information (direct-connection address, PIN information and so on)	While connected
Window choices	Until the user resets them or deletes the account; then deleted at once
Window-detection statistics	Records of apps fewer than 5 people voted on are deleted 90 days after their date. Apps with more are kept as daily totals, and detection rules an operator approved (hints sent to every PC) are kept until withdrawn. The value that counts one vote a day is deleted when the day is over. The totals and rules cannot identify anyone
Direct-connection statistics	Raw records 90 days. After that only monthly totals remain (number of sessions, bytes and time per month, path, codec and resolution band). The totals cannot identify anyone
Diagnostics	30 days. Up to the latest 20 per PC, and the latest 60 and 100 MB per account. Erased immediately when the user deletes them or closes the account
Security records	90 days (including the user IDs and email addresses entered and IP addresses)
Records used for blocking decisions, such as failure counts	1 day (pairing-code attempts 1 hour, blocks until they lift)
Support records	Connections that did not start and old tokens: 30 days. The phone app's version: 90 days after its last connection. A PC's reason for going offline and its network conditions: until that PC is deleted (replaced when new information arrives). Erased immediately when the account is closed
Server logs	30 days (the server's journal, including the web server's access log). Copies sent to the monitoring service: 14 days (free tier, to be confirmed) (Article 6)
Session records	5 years after the session
Billing and payment records (top-up, deduction and refund history, payments)	While the account exists, and 5 years after it is closed (Act on the Consumer Protection in Electronic Commerce: records of payment and of supply of goods 5 years, records of consumer complaints and dispute handling 3 years). After closure they are kept separately for this purpose only
Pairing codes	10 minutes (1 more hour if entered but not yet collected by the PC)
Database backups	7 days. Deleted information in a backup disappears when that backup does
Inquiries and reports	[3 years] after they are handled (the Electronic Commerce Act's records of consumer complaints and disputes). If an abuse report was passed to an investigative authority or is in dispute, until that procedure ends

When the period ends the server deletes the records automatically (security, support and statistics records every hour, session and billing records once a day). Records in the database are deleted so that they cannot be restored.
Whether the Protection of Communications Secrets Act's duty to keep communication confirmation data (access records) applies to the Company is under review (Review notes). Today the server keeps IP addresses in the security records for 90 days and in the server logs for 30 days, as in the table above.

Article 5 (Entrustment of processing)

The Company entrusts processing of personal information to the following providers in order to operate the Service.

Recipient	Work entrusted	Location
The Constant Company, LLC (Vultr)	Hosting the servers, the database and backups	Republic of Korea (Seoul data center)
Grafana Labs, Inc. (Grafana Cloud)	Service monitoring: keeping and searching server metrics and server logs, fault alerts	Japan (ap-northeast region, to be confirmed) — outside Korea (Article 6)
Resend, Inc.	Sending email: sign-up confirmation codes, password reset codes, email change codes and the notes that go with them	United States — outside Korea (Article 6)
[Operations alert channel provider]	Delivering messages that tell operators of security events (blocks, chargebacks, pairing-guess alarms). The messages contain the user ID and IP address	Outside Korea (Article 6)

If the Service grows and places servers outside Korea (Europe, the US), the Company will amend this table and Article 6 and announce it before it takes effect (Article 15).
The uptime monitoring service (UptimeRobot) calls the public web address and the server's health-check address every 5 minutes only to check that the Service is up. It receives no personal information about users.
In its entrustment contracts the Company requires the providers not to use personal information beyond the work entrusted, to keep it secure, to limit re-entrustment and to return or delete it when the contract ends, and supervises their compliance.

Article 6 (Transfer abroad)

The Company transfers personal information abroad as follows (Personal Information Protection Act, Article 28-8).

	Grafana Labs (service monitoring)	Paddle (payment and reselling)	Resend (sending email)
Recipient	Grafana Labs, Inc.	Paddle.com Market Limited	Resend, Inc.
Contact	privacy@grafana.com (to be confirmed)	[Paddle privacy contact]	[Resend privacy contact] (to be confirmed)
Country	Japan (Grafana Cloud ap-northeast region, to be confirmed)	United Kingdom	United States
Items transferred	Server logs (request time, IP address, user ID or email address, error details) and server metrics that contain no individual	The Company's account number (a number placed in the checkout). The email, payment method, address and so on that the user enters in the checkout are given by the user directly to Paddle	The recipient's email address and the content of the mail (subject, confirmation code, notes)
When and how	Continuously while the Service is used, over an encrypted network (TLS)	When the user opens the top-up checkout, over an encrypted network (TLS)	Each time a mail is sent (when the user asks for a code), over an encrypted network (HTTPS API)
Purpose	Fault monitoring and response	Payment, tax handling, refunds and dispute handling	Delivering the codes and notes for email confirmation, password reset and email change to the user
Retention	14 days (the Grafana Cloud free tier's retention, to be confirmed)	As set out in Paddle's privacy policy	[Resend's retention] (the plan's log retention, to be confirmed)

Payments: top-ups are processed by Paddle as the seller (Merchant of Record). The user enters payment details such as the card number directly with Paddle; the Company does not receive them. From Paddle the Company receives only the payment ID, amount, tax, fee, currency and, when Paddle provides it, the country of payment. What the user gives Paddle is governed by Paddle's privacy policy.
How to refuse, and what follows: the user may refuse the transfer abroad by contacting the privacy officer below. If the user refuses the transfer to Paddle, the user cannot top up (direct connections remain free to use). If the user refuses the transfer to Resend, [the user cannot sign up by email, reset the password or change the email address] (there is no other way to send the mail). The transfer to Grafana Labs is needed to run the Service safely; if the user refuses it, [the Company will look into leaving that user's ID and IP address out of the monitoring logs, and if that is not feasible, will explain that the Service may not be able to be provided].
To [Operations alert channel provider] only the security alerts sent to operators (kind of event, time, user ID, IP address) are sent, when such an event occurs, over an encrypted network. The recipient's country and retention are those of [Operations alert channel provider].
The database and backups are kept in Korea.

Article 7 (Provision to third parties)

The Company does not provide users' personal information to third parties, except with the user's consent, where a law specifically provides for it, or where an investigative authority or similar body requests it through the procedure the law prescribes. Even then the Company holds only the items in Article 2; it does not have screen content, sound, input or PC PINs.
Requests from investigative authorities and similar bodies: the Company checks that a request follows the law (a warrant, the procedures of the Protection of Communications Secrets Act or the Telecommunications Business Act, and so on), and gives only the items necessary within the scope the request states. A request with no basis in law, or one that goes too far, is refused or the Company asks for it to be narrowed. Unless the law forbids it or it would harm an investigation, [the Company tells the user concerned that their information was provided]. What the Company cannot give: the content of the screen, sound, input and clipboard (the Company cannot decrypt it and does not store it) and PC PINs.
Reports of fraud and other abuse: when someone reports that another person's PC was accessed without permission, or that someone was deceived under the pretence of remote support, the Company investigates under Terms Article 5-2 and may block the account. The person who reported it is told only the outcome and is not given the reported account's personal information (where a procedure under paragraph 2 exists, that procedure is followed).
Transfer of business or merger: if the Company transfers all or part of its business, or merges, and personal information has to move with it, the Company announces on the website and in the web console, before it moves, that it will, the recipient's name and contact, and how a user who does not want the transfer can withdraw consent (Personal Information Protection Act Article 27).
Sign-in providers (Google, Kakao): the Company regards Google LLC and Kakao Corp. neither as processors it entrusts with personal information (Article 5) nor as third parties to which it provides personal information (this Article) or recipients of a transfer abroad (Article 6). The provider gives the Company information at the user's request ("Information received from sign-in providers" in Article 2); what the Company sends to the provider is only what a sign-in request needs — the Company's app identifier (client ID), the address to return to, a random single-use value and the authorization code received — and never the user's email address, account, PCs or session records. The provider does, however, learn from its own records that the user signed in to OwnRemote, which is governed by that provider's policy. [This judgement to be confirmed by the lawyer, review note 18]

Article 8 (Users' rights and how to exercise them)

Users may at any time ask to see, correct or delete their personal information, or to suspend its processing.
What users can do themselves in the web console (https://ownremote.app/dashboard): view and delete PCs and apps, change PC names and settings, change the password, view and change the email address (confirmed with a code sent to the new address), view session records, view the balance and top-up and usage history, view, download and delete diagnostics sent, acknowledge wrong-PIN alerts, view and reset window choices, turn window-detection statistics off (also in the phone app), view and remove Google and Kakao sign-in links (not possible if it would leave no way to sign in).
Deleting the account (closing it): done by the user in the web console under "Settings" → "Delete account", by entering the password again (an account created with Google or Kakao that has no password confirms by typing its email address). The phone app's menu item "Delete account" opens this page. A request to the contact below also works.
- Erased immediately: the account (including the email address), window choices, Google and Kakao sign-in links, email confirmation codes, PCs, app list, PC settings and support records, wrong-PIN records, diagnostics sent, the phone app's version record. All PCs and phones are disconnected and all sign-ins become invalid.
- Kept separately: session records (including the user ID, 5 years after the session), billing and payment records (5 years after closure), security records (user ID or email address and IP address, including the record of the deletion, 90 days), direct-connection statistics (90 days; only relayed sessions are linked to the account), window-detection statistics already sent (not linked to the account, so they cannot be picked out and deleted; the periods of Article 4), server logs (30 days), the monitoring service's logs (14 days (the Grafana Cloud free tier's retention, to be confirmed)), the mail provider's records of sent mail ([Resend's retention], to be confirmed) and backups (7 days), and inquiries and reports sent ([3 years] after handling). They are deleted when these periods end.
- An account with a remaining balance cannot be deleted. Ask for a refund under Article 8 of the Terms to bring the balance to zero, then delete it.
- What is left on the phone and PC (Article 3) disappears when the user signs out of the app or uninstalls the programs.
Requests to see, correct or suspend processing, and requests that cannot be made on the pages above, go to the privacy officer below. The Company acts within 10 days and tells the user the result. Records the law requires to be kept are kept for that period even if deletion is requested, and the Company explains why.
Requests may also be made through a representative, who submits a power of attorney.

Article 9 (Children under 14)

The Service is not directed at children under 14 and does not accept their sign-up. If the Company learns that a child under 14 has signed up, it deletes the account.

Article 10 (Cookies and browser storage)

The Company's website and web console do not use cookies, with one exception: when a sign-in with Google or Kakao starts, the server sets a cookie for that one sign-in (ownremote_oidc_google or ownremote_oidc_kakao). It holds only what proves that the request coming back from the provider belongs to a sign-in started in the same browser (random values, their expiry and the server's signature), nothing that identifies the user. It is sent only to the provider sign-in paths (/auth/…), deleted as soon as the sign-in returns, and gone after 10 minutes at the latest. Scripts cannot read it (HttpOnly) and it is not sent with requests from other sites (SameSite=Lax).
The web console keeps the sign-in state (a token usable for 12 hours) in the browser's session storage (sessionStorage), which is cleared when the browser tab is closed.
If you choose a language (English/Korean) on the website, only that choice is kept in the browser's local storage (localStorage). This value is not sent to the server and remains until it is cleared in the browser.
The Company does not collect behavioural information (visit history, usage patterns) or use it for targeted advertising.

Article 11 (Automated decisions)

The Company makes no decision that significantly affects users' rights or obligations by fully automated means. For security, if sign-ins or requests are excessively frequent or forged tokens are used, the server automatically blocks that IP address or account for a set time, and a PC briefly refuses connections after consecutive wrong PINs (from 60 seconds after 5, at most 1 hour). These blocks lift when the time passes, and users may ask the contact below for an explanation or for the block to be lifted.

Article 12 (Security measures)

Encryption: all communication is encrypted with TLS or DTLS. Passwords are kept only as Argon2id hashes. PC PINs never reach the server. Operators' two-factor authentication secrets are encrypted with AES-256-GCM. Database backups are encrypted.
Access control: server administration rights are given to as few people as possible. Operators sign in only with a password and two-factor authentication (authenticator app), never with Google or Kakao sign-in (the server refuses it). Operators cannot connect to users' PCs or see their screens either. Operators' administrative actions, and every opening of the customer-support page and of diagnostics, are kept in the security records.
Preventing attacks: lockout after failed sign-ins, IP blocking, request rate limits, blocking of forged tokens, a limit on PIN attempts for each PC.
Testing: external security testing (penetration testing) before launch and periodically afterwards.
Minimal collection: screen and input content is encrypted so that it cannot be decrypted even when it passes through the server, and is not stored. Metrics contain no accounts, PCs or addresses.
If an incident happens: when the Company learns that personal information has leaked, it tells users within 72 hours what leaked, when and how, what they can do to limit the harm (for example change the password, change the PC's PIN), what the Company is doing, and where to report or seek advice; and, where the law requires, it reports to the Personal Information Protection Commission or the Korea Internet & Security Agency (Personal Information Protection Act Article 34). It tells users who have an email address at that address; as some accounts have no email address (created before email accounts and not yet given one), it also posts the notice in the web console and on the website [for at least 30 days], and tells separately other users whose contact it has (such as those who sent an inquiry). If the server's secrets leaked, it invalidates every sign-in (signs everyone out) and says so in the same notice.

Article 13 (Privacy officer)


Privacy officer	[Privacy officer name and contact]

Questions about personal information, requests to see, correct, delete or suspend processing, and complaints go to the officer above.

Article 14 (Remedies)

Reports of and consultations on infringements of personal information can also be made to the following bodies:

Personal Information Infringement Report Center (privacy.kisa.or.kr, dial 118 with no area code)
Personal Information Dispute Mediation Committee (www.kopico.go.kr, 1833-6972)
Supreme Prosecutors' Office, Cyber Investigation Division (www.spo.go.kr, dial 1301 with no area code)
Korean National Police Agency, Cyber Investigation Bureau (ecrm.police.go.kr, dial 182 with no area code)

Article 15 (Changes)

When this policy is changed, the Company announces it on the website (/privacy) and in the web console 7 days before it takes effect. Changes important to users' rights (new items collected, provision to third parties, a new transfer abroad and the like) are announced 30 days before.

Company: [Company name] · Representative [Representative] · Business registration number [Business registration number] · Address [Address]
Announced: [Announcement date]
Effective: [Effective date]