NMTS Privacy Policy

English is the canonical text of this policy. A Korean version of the same content is published alongside it, in full — neither version is a summary. If you are a consumer habitually resident in Korea, the Korean version is the one that governs for you. Section 16 has the whole rule.

Read this first#

• We do not hold your name, your email address, your phone number, your age or your date of birth. We do not ask for them. If you open a board profile you choose a nickname, which is public — choose one that is not your name if you would rather it were not.
• We cannot read the files you have stored, or their names. They are encrypted in your browser with keys we do not have. Your browser runs software we publish — section 4.3 explains the honest limit of that.
• There is one exception, and only you can make it. When you write to our support inbox you may choose to attach a list of your files. If you do, those names, folder paths and sizes reach us in readable form and stay with that message (2.5). The form starts with only facts about the software attached — what your browser says about itself, and which build you run — and "send nothing" is one press away. Your file list is never attached unless you tick it yourself.
• We can see how many files you have, how large each one is, and when each was created, changed or deleted. That is real information about you and this policy treats it as such.
• Your IP address is used while a request is being handled and is not stored by us in a form that can be turned back into an address. Our edge provider (Cloudflare) delivers the site, so it sees your IP address on every request.
• Readable text you write reaches our server in three places, and in three only: the support inbox, email you send to our address, and the board — where what you write is meant to be read by everyone and our server necessarily holds it in readable form (2.12). Nothing else you write does — your file contents, file names and folder structure are encrypted in your browser with keys we do not have. What our server holds about you in a form we can read is the records in section 2: your file sizes and times, who you shared with and when, your credit ledger, the note we write when we grant credits, and — if you open a board profile — your nickname and what you posted. (A form for reporting a file is described in section 2.9 and is not switched on yet; the board has its own, and it is switched on.)

We collect the minimum we need to run the service, and no more. What we do hold is listed in full below.

1. Who is responsible, and how to reach us#

1.1 NMTS is operated by one individual, under the name needmoretruth. That individual is the controller of the personal data described here, and is also the person who handles privacy matters.

1.2 Privacy contact — the privacy team (개인정보 보호 담당 부서), which the one operator staffs. We hold no phone line for this; email is the channel. Email: nmts@nmts.me

1.3 Write to that address for anything in this policy: to ask what we hold, to ask us to delete it, to complain, or to ask which countries your data is stored in. Messages are read by a person. There is also a shortcut inside the product: the account screen links to this section.

1.4 We hold no phone number for inbound contact and no postal counter. Email is the channel.

2. What we store, exactly#

This is the complete list of what our server holds — every kind of record, not a selection. If you find one we have not listed, tell us at nmts@nmts.me and we will list it. One thing is absent by design rather than listed: our server keeps no request log tied to you — its own log carries start-up and housekeeping lines, not who asked for what. Where this policy says a record is "encrypted", it means encrypted in your browser with a key we do not have. Where we hold the key, the sentence itself says so: that is true of the connection between your browser and us, and of the backup copies of our database (8.1, 9.3) — and of nothing else.

2.1 Your account record#

We hold no name, no email address, no phone number, no age, no date of birth, no postal address and no payment details. There are no columns for them.

2.2 Your devices and sessions#

No session record and no device record holds your IP address, your location, or anything your browser says about itself, beyond the encrypted device label above. The device list shows you only when a device was first seen and last used. The one place browser details can reach us is a support inquiry you chose to attach them to (2.5).

2.3 Your files — what the server holds#

File names and folder structure are not held in readable form in the database that runs the service. They were removed from it and now exist only inside the encrypted blob. The length of an encrypted name is not stored with a file either, because a length is a fingerprint. There are two exceptions and both are narrow: for a file you share, the name travels again encrypted to the recipient, and that copy is stored at its own length — so for shared files, and only those, the length is visible to us (2.4); and anything you attach to a support inquiry yourself is stored in readable form with that inquiry (2.5).

2.4 Sharing#

Our server therefore knows who shared which file with whom, and when. It does not hold the file's name in a form it can read, its contents, or any record of the recipient opening it — we do not count or log opens.

2.5 The support inbox#

This is one of the two places on our own server where readable text you wrote is stored; the other is the board (2.12), and the difference is that the board is written to be read by everyone while this box is written only to us. Email you send us sits with our mailbox provider instead (5.2). If you type your name, an email address or anything else about yourself into a message, we hold it — because you sent it, not because we asked. There is no email field on the form and we do not ask for one. Nothing beyond the two software sections is in the disclosure snapshot unless you tick it — and those two start ticked, with "send nothing" one press away — and the screen shows you what will go before it goes.

Please keep certain things out of this box. A support message is readable text on our server for 30 days and lives in an encrypted backup for longer (8.1). Please do not write here about your health, your beliefs, your politics, your sex life or anything else of that kind. We do not need any of it to answer you and the form does not ask for it. If you send it anyway we treat it as sent by your own explicit choice and we delete it with the rest of the message — but a plain-text inbox is the wrong place for it, and we would rather say so than let you find out afterwards.

If a message is about someone else. Sometimes a message tells us something about a person who is not you — a colleague you mention, or the person a report is about. We hold that for the same period as the message itself, we use it only to deal with the message, and we normally have no way to write to that person, because we hold no address for them. This paragraph is how we tell them.

Inquiries sent without an account. Since 10 August 2026 you can write to us without an account (/ask). An inquiry sent that way is linked to no account — no public code and no disclosure record are attached to it. What we keep is the text you wrote, the category you chose, a reference code, a check value of your reading code, and the timestamps. We do not hold the reading code itself: it is shown to you once as you send, and what remains on our side is a one-way check value. So if you lose it, we cannot open that inquiry for you either. This channel is limited to ten inquiries a day per address, and that count stores no IP address — it uses the daily-rotating, memory-only value described in 2.6. Retention is the same as for any other inquiry — the 30 days of section 8, or that section's 120 days if you send it under the "Board action" label. The page states what is kept before you write anything.

2.6 IP addresses#

2.6.1 Your IP address exists on our server only while a request is being handled. It is not written to a log and it is not stored in a form that can be turned back into an address.

2.6.2 What is stored, for rate limiting and for locking out repeated failed sign-ins, is HMAC-SHA256(salt, IP). The salt is generated from the operating system's random source when the server starts, lives only in memory, is generated fresh again at 00:00 UTC every day, and yesterday's salt is kept for one day so that counters do not reset at midnight. The salt is not written to disk, so once it is gone the value cannot be linked back. The second sign-in lockout counter described in 2.2 involves no address at all.

2.6.3 We do not use sha256(IP) for this. A plain hash of an IP address can be reversed by trying every address, so it would be no better than storing the address.

2.6.4 Our server sends your IP address to Cloudflare once per human check — that is, once for each of the moments listed in 5.1, including each free-trial application, and not once per session — so Cloudflare can verify the check result. Separately from that, the site is delivered through Cloudflare, so Cloudflare sees your IP address on every request — see section 5.

2.6.5 The file-report table described in 2.9 is built to store the same kind of daily-salted value for the person making a report. Nothing has been written to it, because the product has no way to report a file. The board's own report form is a different table (2.12) and it takes no IP-derived value from a signed-in reporter; where a report is sent while signed out, the human check of 5.1 runs and section 9.2 says what that sends.

2.7 Aggregate counts#

2.7.1 We keep service-wide totals: number of accounts, how many of them have ever stored a file and how many stored one in the last 28 days, the total size of the encrypted bytes stored (the size is a number we can read), number of files, an estimate of downloads, and daily visit and page-view counts copied from our edge provider's own totals — each daily row also names which provider counter it came from and when it was copied. These are totals for the whole service. There is no per-account figure in them. We publish these totals on the website — the basis for that is in the section 7.1 table, and 10.6 is your right to object to it.

2.7.2 When the service has few users, a daily total can be close to one person's activity. We say so rather than implying otherwise.

2.8 Credits and what they buy#

2.9 Abuse reports#

2.10 Operational records#

2.11 The free-trial programme's own records#

2.12 The board#

The board is the one part of NMTS where you write things our server can read, and other people can read them too. Everywhere else in this policy the server holds encrypted material it cannot open; here it holds your words in readable form, because a public board cannot work any other way. Nothing in this section happens unless you open a board profile, and the Board Terms — a separate document with its own acceptance — govern what the board does with it.

3. What is stored in your own browser#

3.1 This is on your device, not on our server. You can clear all of it from your browser at any time, and signing out clears the items marked "cleared on sign-out". The first block is needed for the service to work; the second only makes the site nicer to use, and the service runs without it.

Needed to run the service:

Kept only to make the site nicer to use:

3.1a A copy you can take with you. From your account screen you can download your file list as a file. Its payload is the same encrypted blob we hold: it opens only with your account code, and in that encrypted form it carries your file names, your folder structure and your file keys. Around it is a short plain header — the format, the version number of the list, when this device saved it, your public account id, and a note in English and Korean saying what the file is. Your file names are not in that header. Once the file is on your disk it is yours to look after: signing out does not clear it, because it is no longer in the browser.

3.2 Outside the items above, we store nothing on your device: no service worker, no cache of your data, no advertising or analytics storage of our own, and no cross-site tracking. One measurement script does run on our pages, and it is inserted by our edge provider rather than by us; it stores nothing in your browser (5.1 and 9.2).

3.3 "Remember this device" has two modes, and one of them has a real limit. With the passphrase mode, your code is encrypted with a passphrase only you know, and the disk alone will not open it. With the device mode, the wrapping key is stored in the same browser database, so someone who can read your browser profile files can recover your account code. The product says this on the screen where you choose.

3.4 One other cookie exists: nmts_admin is issued only to the operator for the support console and is not issued to you. Before launch, our edge provider set an access cookie for the closed beta; that lock is gone and so is its cookie.

3.5 The sign-in token is not a cookie. It is sent in a request header and normally lives only in the page's memory.

4. What we can see, and what we cannot#

4.1 We cannot decrypt the contents of your stored files, or their names. The keys come from your account code, which we do not hold. The one exception is the one you make yourself: names, folder paths and sizes you attach to a support inquiry arrive readable and stay readable for as long as that inquiry is kept (2.5).

4.2 We can see everything listed in section 2: how many files you have, the size of each, when each was created, changed and deleted, when you signed in, how many devices you have, who you shared a file with, and whatever you typed into the support inbox or attached to it.

4.3 The honest limit on 4.1: we also write and distribute the software that does the encrypting, and your browser runs the version we serve. A statement that we cannot decrypt stored files is a statement about the keys we hold today; it is not a promise about every future build. Section 12.4 carries this limit into the break-in analysis, where it matters most.

What we publish, and what publishing it does not prove. The encryption engine's source, the boundary that exposes it to a browser, the format specification and the conformance vectors — fixed inputs with their expected bytes committed — are published at github.com/needmoretruth/nmts-crypto under the GNU Affero General Public License v3.0. The server, the web interface, and the payment and storage logic are not published. Reading that source tells you what a browser should receive; it does not tell you what yours received. We do not yet build the software in a way that anyone else could repeat byte for byte, and we publish no fingerprint of each release, so nothing here lets you check that the code running in your browser at this moment is the code we published. That gap is real, and we would rather name it than let publication be read as more than it is.

4.4 We do not scan your files, because we cannot. We do not profile you, and we do not build advertising audiences.

4.5 What we hold, and where our power over it stops. We keep the minimum that running the service needs: the account records in section 2 and the encrypted list of your files. The files themselves are encrypted in your browser with keys we do not have, so we cannot read them. They are stored on Walrus, a public network we do not own or run, and we hold no key of yours — so what can be done to stored bytes is not decided by our policy but by who holds the storage object. Where you paid from your own wallet, the object is yours and only your signature releases it; where credits paid for it, the object is ours and we release it when you ask us at nmts@nmts.me (Terms 8.3, 12.6). Beyond releasing the object, nobody — us included — can require a storage node to discard a copy it has already taken. Section 8.4 says what we do instead.

5. Other companies involved#

5.1 Cloudflare. Our site is served through Cloudflare, so Cloudflare handles every request before we do. Because it terminates the encrypted connection, it can see the whole of each request and response — not only your IP address and the page you asked for, but also anything you type into the support inbox as it passes through. Specific things it does for us:

• The human check (Turnstile). When you create an account, sign in, send a support inquiry, apply for a free trial, report something on the board without being signed in, or when your session pass is renewed in the background, your browser loads Cloudflare's check and Cloudflare receives signals from your browser and your IP address. Our application server then sends Cloudflare the check result together with your IP address so it can be verified.
• Performance measurement. The edge inserts a small measurement script into our pages. It reports load times and page-view facts, sets no cookie and stores nothing in your browser, and we use it only to see where the product is slow on real devices. Section 9.2 sets out what is transferred.
• Network error reporting. Our responses carry a header that lets your browser report a failed connection to Cloudflare. Successful requests are not reported. You can block this in the browser; nothing stops working.
• Backup storage. Encrypted copies of our database go to Cloudflare's object store every day and, whenever the database has changed, every hour — section 9.3 describes that transfer in full.

Every outbound call our machines make, and which of them carries your address. The human-check verification above is the only one in which your IP address leaves our server. None of the others carries an address of yours: the backup uploads described in sections 8 and 9, which carry your records but encrypted by us before they leave; the calls that read visit totals from Cloudflare's own counters — one a day that copies them into our record, and a cached read when the statistics page is drawn — which carry nothing about you in either direction; the call that reads two coin prices from a public price service (CoinGecko), which carries nothing about you and is the same request for everybody; and, when a file is uploaded with credits, our own signing service submitting the storage payment to the Sui network and paying the upload relay from our wallet. That last one is not empty of you either: it carries the storage identifier, the size and the term, which our own ledger links to your account (2.8, 6.3, 9.4, Terms 10.11). One more, and only if you turn the board's storage mark on: our server asks a public blockchain reading service whether the storage objects you claimed exist and are yours. That call carries those public identifiers and no address of yours; the services we may use are the ones named in section 6, and which one is in use is a setting of the product, not a choice you make. And one that has nothing to do with your account at all: our server reads a single number — how many people are connected right now — from Discord's public information about our own Discord server, at most once every five minutes, so the page about our community can show it. It carries nothing about you and happens whether or not you are signed in. Your browser does not talk to Discord: we deliberately did not place Discord's own panel on the page, because that panel would make every visitor's browser connect to Discord and hand it their address.

If you decline the human check you cannot create an account, sign in, send a support inquiry, apply for a free trial, or report board content while signed out — signed in, reporting needs no such check, and that is the route to use if you would rather Cloudflare did not see the request. There is no alternative route, because the check is what stops automated abuse of an account system that holds no email address — and, on the trial, what stops one person's script from taking every place in the week. Declining the edge itself is not possible while using the site — every request passes through it; section 9.2 states the legal basis for that.

5.2 Our other vendors, all of them: the mailbox that receives email you send to nmts@nmts.me is run by our mailbox provider, Proton AG — if you email us, the text you wrote sits in that mailbox. Your browser also talks directly to the storage network's gateway services named in section 9.4. We use no analytics, advertising, customer-support, CRM or marketing vendors, and we send no email or push notifications to users.

5.3 We do not sell your personal information and we do not share it for cross-context behavioural advertising. There is no arrangement under which anyone pays us for data, and none under which we hand data over for advertising.

5.4 When an authority demands data. What can be compelled from us is what we hold — the records in section 2, including support text still inside its 30 days. What cannot be produced by anyone is the content of your files, because we do not hold the keys; and their names, except for any names you yourself attached to a support inquiry that is still being kept. For user-stored data we require a court order or judge-issued warrant, as the law governing cloud services provides; we do not hand records over voluntarily, to governments or to anyone else; we keep a record of every disclosure; and we tell you, unless a law or the order itself forbids it. The Terms, section 12.9, carry the full statement.

6. The public networks#

6.1 Your encrypted files are stored on the Walrus storage network, and payments and storage terms are recorded on the Sui blockchain. These are public, permissionless networks. We do not own or run them.

6.2 How your bytes travel. Your browser sends the encrypted bytes to an upload relay and fetches them back through an aggregator — two gateway services named in section 9.4. Those two see your IP address, the blob id, the size and the time. They pass the bytes on to storage nodes run by independent operators around the world, which hold the ciphertext, the blob id, the size and the time. Nobody in that chain receives file names, your account, or anything decrypted. The storage network serves stored blobs to anyone who asks by identifier — that is what makes revoking a share an incomplete remedy (Terms 9.5).

6.3 Transactions your wallet signs are public and lasting. Your wallet address, the amounts, the storage terms and the blob ids are written to a public ledger that anyone can read. We cannot edit or erase it, and neither can you. Think about this before you import a wallet that is linked to your identity elsewhere — importing means giving the product that wallet's private key, which stays encrypted on your device and is never sent to us (section 2.1). For an upload paid with credits the transaction is built and signed with our key and the storage object is registered at our address, so the public entry shows our wallet, with your file's size and timing inside it (Terms 10.11).

6.4 A wallet address is capable of identifying a person, so we treat it as personal data even though we do not hold it in our database.

7. Why we process this, and on what basis#

7.1 Our primary basis is performance of a contract with you (GDPR Art. 6(1)(b) for people in the EU and UK; in Korea, 개인정보 보호법 Art. 15(1)(4); the equivalent contract ground elsewhere). You asked us to store and index your files; we cannot do it without the data in section 2.

7.2 The legitimate interests in the last five rows, stated plainly. Keeping a service that holds no email address usable at all: without a rate limit and a human check, an account system with no email address can be flooded by scripts, and without the refusal count a free giveaway can be swept by mass-produced accounts before anyone real reaches it. Being able to say publicly how much the service holds. Being able to say why we gave somebody credits we were not asked for. And being able to show afterwards what an operator did. We use the least identifying method we could find in each case — a value derived from an IP address with a salt that is destroyed daily, a count of accounts rather than of attempts, totals with no per-account figure — and we judge those interests to outweigh the intrusion for that reason. Section 10.6 is your right to object to any of them.

7.3 We rely on your consent for two things and no others, and both of them are on the board: quoting a post of yours where we promote NMTS, and displaying the storage mark. Both are off unless you turn them on, both can be turned off in the same place at any time with no reason given, and turning either off costs you nothing — the board works the same afterwards. Everything else in the table above stands on a contract, a legal obligation or a legitimate interest, and that is deliberate: consent that is required in order to use a service is not freely given. The two exceptions are switches you can live without, which is exactly what makes consent the honest basis for them. Both are for people 14 or older, which is what the board asks you to state, and we still do not hold your date of birth.

7.4 Two decisions about you are taken by machine, and here they both are. The first acts on content you wrote: on the board, where content has been reported and hidden pending review, a clock runs, and if the matter has not been decided within the period the Board Terms set, the machine restores or removes according to the reason it was hidden under, without a person looking at it that day. The second acts on a report you sent: a report still open 12 months after it arrived is closed on that day by the machine, whether or not anybody ever told you the outcome (Board Terms 7). Nothing else about you is decided this way — rate limits, the human check and the trial pause can block a request, but they decide nothing about you.

The board clock, which acts on content.

• Who it applies to: an account that has written on the board.
• What it reads: the account identifier, the time the content was hidden, the reason number it was hidden under, whether a formal procedure has been recorded against that content and the date such a procedure holds it until, and whether a rebuttal is standing beside it. It reads nothing you wrote and nothing outside the board.
• How it decides: by the passage of time and by the reason number. A recorded copyright procedure or a live court case stops it entirely — while either stands it decides nothing at all; where the procedure is recorded as suspended it waits for the date given, and resumes on that date by itself. Where it removes content that had a rebuttal beside it, the rebuttal goes with the content and both the writer and the person who asked for the rebuttal are told. There is no scoring, no profiling and no sensitive information anywhere in it.
• What you can do: you can refuse the outcome and ask us to explain it, and you can ask for a person to decide instead. The road is the support inbox under the "Board action" label, and our answer must reach you within 30 days, which the law lets us extend twice by 30 days each where the matter requires it and we tell you why (Enforcement Decree of the Personal Information Protection Act, art. 44-3(5)).
• Where you are told: the notice box marks a step the machine took, so you can tell the two apart without asking.

The 12-month closing, which acts on a report.

• Who it applies to: anyone who has reported board content — from an account, or with only a contact address.
• What it reads: the day the report arrived, whether a person has decided it, whether the outcome has been told, whether an account or a contact address is attached to it, and whether we have been told of a live dispute about it.
• How it decides: by the passage of time alone. On the 12-month day it closes the report — carrying the decision a person had already handed over where there is one, and otherwise as "the period ended", which is not a dismissal and does not say the report was wrong. Your contact address is erased in the same step, and where the outcome had not been told the record keeps that fact. A report carrying no account, no contact address and no decision is deleted outright instead, because there is nobody it could ever be answered to. Where a live dispute has been notified to us the row itself is held past the deadline — but the contact address still goes, because a dispute needs the report and how it was handled, not the address of the person who sent it.
• What you can do: the same road — the support inbox under the "Board action" label.
• Where you are told: if you reported from an account, the closing lands in your notice box and says the period ended rather than claiming a judgement nobody made. If you left only a contact address, nothing reaches you — the address is erased in the same step that closes the report. We would rather write that down than let you assume an answer is still coming.

7.5 If we ever process your data for a new purpose, we will say so in a new version of this policy before we start. This version starts no new processing at all — every change in it corrects what an earlier version said about processing that was already running, and none of it changes what the software does. Two earlier moments are worth keeping on the record rather than letting them pass. The preview-channel record (2.1) began on 5 August 2026 and was first written down in the version effective 11 August 2026, after it had begun; no account had entered the preview channel by then. The board (2.12) opened on 11 August 2026 with that same version, which is the version that first described it — and none of the processing in 2.12 happens until you open a board profile.

8. How long we keep things#

8.1 Backups are the honest exception, and here is all of it. We take encrypted copies of our whole database — everything in section 2, including support text that is inside its 30 days at that moment — and store them off-site with Cloudflare (R2 object storage), so that a fire or a failed disk does not end the service. There are two schedules, not one: a full copy every day at 03:30 UTC, and a further full copy at five minutes past every hour whenever anything has changed since the last one. So a record that existed for an hour is very likely to be in a copy. A backup taken before you deleted something still contains it, and can be kept for longer than the periods above. Two more facts you should have. For the first 90 days after a copy is written, the store refuses to let it be deleted or altered — we measured that refusal with our own keys, and the lock exists exactly so that an attacker who took our credentials could not destroy the backups. The price of that is that an erasure you ask for cannot reach a copy inside that window. After the lock, a rule the storage service runs by itself deletes each copy: an hourly copy 91 days after it was written, a daily copy 52 weeks (364 days) after. Those two are the only copies that contain the records in section 2, and keeping either longer would take a deliberate act rather than forgetfulness. Backups are encrypted before they leave, held apart from the live system, and used only to restore the service. One small file is uploaded beside them without encryption — the record of whether a backup run succeeded, which holds object names, byte counts and failure messages, and holds no record from section 2. Section 9.3 covers where all of this goes.

8.2 What deleting a file does, in full, is set out in section 8 of the Terms of Service. The short version: we destroy the key; the encrypted bytes stay on the storage network until the term you paid for ends, and cannot be read. They can also be destroyed outright before then — 8.4 says by whom, and how.

8.3 What deleting your account does, and what nothing can stop. In one transaction we hard-delete from the live database: the account record and your sharing identity, your terms acceptances, your preview-channel record, your file records, storage parts, grouped storage blobs and extensions, your encrypted file list and its previous version, your encrypted device labels, your sessions, your shares in both directions, your credit grants and spending, your sponsored-storage rows, any voucher you redeemed, any abuse report about one of your files, your refused trial applications, your board profile and notice address, your posts and comments, your nickname history, your board terms acceptance and consent ledger, your notice box, your writing and verification counters and your storage-mark records, and every support inquiry linked to your account with everything attached to it. There is no condition in our database today that can refuse an erasure or leave it half done. In the same transaction we take your public code out of the operator action log, so that what an operator did stays on the record and the pointer to you does not.

Six things it does not reach, and we would rather name them than let you assume otherwise: the storage network and the public ledger (8.2 and 6.3); the backups, until they age out on the schedule in 8.1; our treasury's own money ledger, which records what we spent buying storage and carries no reference to any account at all; the IP-mixed sign-in counter of 2.2, whose key we cannot reconstruct once the day's salt has rotated — it is swept on the schedule in section 8 instead; a board bar standing against the account, which survives deletion on purpose and ends on its own day (2.12, section 8) — an account identifier is derived from your account code, so a measure that died with the account could be cleared by deleting the account and creating it again; and the quote ledger, which holds no nickname and no account identifier and is the proof that a quotation of yours was taken down when you withdrew the switch.

8.4 What we do about the copies we cannot reach. Where a law gives you the right to have us pass a deletion request on to others holding the data, here is what we can and cannot do. Where the recipient is a company we can reach — Cloudflare, for the backups; the gateway services in 9.4, for what they hold — we pass your deletion on, and we tell you who they were if you ask.

The storage network is different, and the difference is narrower than it sounds. The network does have a delete command and we use it: every blob this product registers is registered as deletable, so whoever holds the storage object can destroy it. For an upload you paid for from your own wallet the holder is you, and the product does it from your wallet. For an upload paid with credits the holder is us, and we will destroy it if you ask us at nmts@nmts.me — an operator runs that release by hand, and it is not automatic. What the network gives nobody is a way to order an individual node to discard a copy it already took, or an address list for the node operators. So beyond deleting the object there is no message we can send, and we do not pretend otherwise; what we do instead is destroy the key, stop paying for the term where you ask us to, and keep a record of the fact that the network offers no per-node deletion channel. If it gains one, we will use it.

8-A. How destruction actually runs#

So that "deleted" is a procedure and not a promise: expired trash rows, expired file-list versions, expired support inquiries and refusal rows older than eight complete ISO weeks are removed by hourly sweeps that hard-delete the rows; file deletion destroys the wrapped key (Terms 8.2); account deletion hard-deletes the rows listed in 8.3 in one transaction; and backup copies age out as described in 8.1. Where a preservation duty applies to a specific item, that item is excluded from the sweep and the exclusion is recorded with its legal ground.

One limit belongs here as well as in 8.1, because this is where a reader looks for it: a backup copy written before you deleted something still contains it, and for the first 90 days after it was written nobody, us included, can alter or delete that copy. Deleting a file, withdrawing an inquiry or closing your account therefore takes effect at once in the running service and works its way out of the backups as they age — 91 days for an hourly copy, 364 for a daily one.

What happens if we ever restore from a backup. A restore brings the database back as it was when the copy was taken, so it can bring back records you had already deleted — the deletions made between that copy and the failure. A restore is therefore not finished when the service comes up. Before we open the service again we re-apply every such deletion we can identify from the restored database itself; where we cannot identify one, we say so on the notice board (13.2) with the window the restore covers, so that anyone who deleted something inside it can tell us and we delete it again at once. A backup is allowed to delay your deletion. It is not allowed to undo it.

9. Data leaving the country#

9.1 We will not pretend this is tidy. Here is what actually happens — in four separate flows, because they have different destinations and different rules. One fact first, because everything below is measured against it: our own server — the machine that holds every record in section 2 — is in the Republic of Korea. If you are in Korea, your records on our server do not leave the country except in the flows below. If you are in the European Union, the records our own server holds are covered by the European Commission's adequacy decision for the Republic of Korea of 17 December 2021 ((EU) 2022/254), which applies to recipients in Korea that are subject to the Korean Personal Information Protection Act together with the supplementary rules in its Annex I. We are such a recipient: we are subject to that Act. Annex I also limits what we may do when we pass data on again, and we would rather be exact about where we meet that and where we do not. For our backups and the edge the recipient is one company, and 9.2 names the instrument we rely on. For the gateway services in 9.4 and the storage network in 9.5 we hold no contract with anyone, so for those two flows we do not claim to satisfy Annex I's onward-transfer rule by contract; what we rely on there is written into 9.4 and 9.5 themselves, and 9.6 states the risk that leaves. We would rather you read that here than come upon it four paragraphs later. If you are in the United Kingdom, the equivalent United Kingdom adequacy regulations for Korea apply on the same footing; they are a separate instrument from the European one.

9.2 The edge and the human check. Every request to the site passes through Cloudflare, and the human check sends it your browser's signals. This is an overseas transfer of personal data.

• What is transferred: the whole of every request and response, because this provider ends the encrypted connection before we see it. On every request that means your IP address, your browser's check signals, the address you requested and page-performance figures; and when you write to the support inbox it means the text you typed and whatever you chose to disclose with it, in readable form, on its way to us (2.5). That is the only readable text this service ever handles, and it crosses this border with every message. The board crosses it too: a post, a comment or a report is readable text, and it passes through this provider on its way to us and on its way back out to every reader. The performance figures come from a measurement script (Cloudflare Web Analytics) that the edge inserts into our pages: it reports load times and page-view facts, it sets no cookie and stores nothing in your browser, and we use it only to see where the product is slow on real devices. The check signals go once for each of the moments listed in 5.1, including each free-trial application and each board report sent while signed out — not once per session.
• Who receives it: Cloudflare, Inc., 101 Townsend St, San Francisco, CA 94107, USA — privacyquestions@cloudflare.com — and its global network. The country is the United States, plus wherever Cloudflare's nearest edge to you is.
• When and how: at each request, over encrypted connections, from your browser and from our server.
• Why, and for how long: to deliver the site and to verify that a request comes from a person. Retention follows Cloudflare's published data- processing terms.
• The legal ground we rely on: for people in Korea, 개인정보 보호법 Art. 28-8(1)3(가) — this section is the disclosure that provision requires. For people in the EU and the UK, the ground is the standard contractual clauses adopted by the European Commission, and their United Kingdom counterpart, which form part of the data-processing terms this provider publishes. It is one recipient and one set of terms, so the same clauses stand behind the edge, the human check and the backup storage in 9.3 — we will not describe those flows differently from one another, and we will not put a version of this policy into force that claims a safeguard we have not put in place. Ask us at nmts@nmts.me and we will tell you which version applies and send you the published text.
• How to refuse, and what happens: the human check — do not create an account, do not sign in and do not apply for a trial. On a board report the refusal has somewhere to go: sign in and report from there, and no check runs, so you can make the report without this transfer. The edge — it cannot be refused while using the site, because every request passes through it; the only refusal is not to use the site.

9.3 Our backups. The encrypted copies of our whole database described in 8.1 are uploaded to Cloudflare R2 object storage.

• What is transferred: everything in section 2, encrypted by us before it leaves, including support text inside its 30 days at dump time.
• Who receives it: Cloudflare, Inc. (same details as 9.2). Destination country: the United States and Cloudflare's storage network.
• When and how: once a day at 03:30 UTC, and at five minutes past every hour in which the database changed, over an encrypted connection.
• Why, and for how long: only to restore the service from the backup after a disaster; retention as in 8.1 — 91 days for an hourly copy, 364 days for a daily one, and neither can be deleted for the first 90.
• Safeguards: the copy is encrypted before it leaves us, with a key Cloudflare does not have — the one protective measure here that does not depend on anybody's paperwork. For people in the EU and the UK the transfer rests on the same standard contractual clauses as 9.2, on the same terms and the same condition. In Korea, the ground is 개인정보 보호법 Art. 28-8(1)3(가), and this section is the required disclosure of the 위탁·보관.
• How to refuse, and what happens: this transfer cannot be refused separately while you hold an account, because it is the copy that lets the service survive a fire or a failed disk and it is taken of the database as a whole. The way to end it is to delete your account: from then on no new copy contains you, and the copies already written age out on the schedule above.

9.4 The gateway services we chose. Your browser reaches the public networks through a small, fixed set of services that we picked and pinned in the published build; they change only with a new release. One of them is also reached by us, not only by your browser: when a file is uploaded with credits, our own signing service submits the storage payment to the Sui network through the same RPC service and pays the upload relay from our wallet. What travels in those calls of ours is the storage identifier, the size and the term, and our wallet address rather than yours. Those identifiers are not nothing of yours: our own ledger links them to your account (2.8), and the public entry they create carries your file's size and timing (6.3). For those calls we are the sender, and we treat what they carry as data about you.

• Who receives it, at the effective date: the Walrus upload relay and aggregator, operated by Mysten Labs, Inc. (Palo Alto, California, United States — privacy@mystenlabs.com), and a Sui RPC service, Suiscan, a product of Staketab (support@staketab.com). Staketab does not publish the country its infrastructure runs in, so we do not state one: see the next point but one. If we change any of them we say so on the notice board (13.2) before the change takes effect.
• What is transferred: to the relay and aggregator, your IP address, blob ids, sizes and times (6.2); to the RPC service, your IP address, your wallet address and the full contents of transactions you sign or balances you read.
• Which country, and when: we do not know and cannot promise which country each of them runs in — their infrastructure is theirs and we do not control it. Each is reached over an encrypted connection at the moment you upload, download or read a balance.
• For how long: we ask none of them to keep anything for us. What they retain is theirs to state, not ours.
• What we have with them, and what that means in law: nothing. We have no contract with any of these services and we do not instruct them. Each decides for itself what it does with what it receives, which in law makes it an independent controller of that data. We are naming them because that is the disclosure we owe you; we are not representing that we have processor agreements or standard contractual clauses with them, because we do not. Who sends what matters here, so we separate it: what your browser sends reaches them straight from your device, and we neither receive it nor pass it on; what our signing service sends for a credit-paid upload goes from us, and for those calls we are the party that disclosed the data. We will not dress either arrangement up as an outsourcing in order to claim the disclosure route in 개인정보 보호법 Art. 28-8(1)3, because that route is for processing entrusted to a contractor and for storage, and this is neither; and we do not rely on your consent (7.3). So we tell you plainly: for these flows we cannot point to a ground in Art. 28-8(1) that we are satisfied covers them, and a regulator could conclude that they do not meet the overseas-transfer rules. What we can tell you is what actually protects you: nothing readable leaves — the content of a file and its name are encrypted before any byte goes — what reaches these services is an address, an identifier, a size and a time, and there is a working complaint route in 1.2. If we find a way to run the service without them, or a ground that honestly fits, we will change this paragraph and say that we did.
• How to refuse, and what happens: these are the only route to the storage network, so refusing them means not uploading, not downloading and not reading a balance. Your account, your existing file list and support still work.

9.5 The storage network itself. Your ciphertext goes to storage nodes run by independent operators in countries we do not choose and are not told in advance.

• We are not able to name a destination country in advance, because the node set is open and changes. The network also moves the encrypted pieces between nodes on its own schedule; each of those movements is a further transfer, and we have no more control over it than over the first.
• There is no adequacy decision covering this, and there are no standard contractual clauses in place for it: for the node set there is no counterparty to sign them, because the nodes are not our vendors and we have no contract with them. What we rely on instead, for people in the European Union and the United Kingdom, is Article 49(1)(b) of the GDPR — the transfer is necessary to perform the contract you made with us, which is to put your file on this network, and there is no version of that contract in which the ciphertext stays here. Where you pay from your own wallet you also place it yourself, having read this section and 9.6, which is the explicit consent Article 49(1)(a) describes. We state the limits of that ground as well: it is written for transfers that are necessary for your contract rather than for a standing arrangement, and a supervisory authority may take a narrower view of how far it stretches for something this routine. 9.6 says what that leaves.
• The Korean position, stated rather than implied: 개인정보 보호법 Art. 28-8(1) forbids an overseas transfer unless one of its listed grounds applies, and its Enforcement Decree, Art. 31(1)2, requires this policy to state the ground we rely on for each transfer. For the storage network we cannot state one. We do not have your separate consent for it and we will not manufacture consent in order to let you use a service; there is no treaty; the node set is not our processor and holds no certification; and no adequacy recognition covers it. 9.6 says what follows from that, and what we did instead.
• What travels is ciphertext, a blob id, a size, a time — and, for the upload or download itself, your IP address, which is seen first by the gateway services in 9.4 and can be seen by whichever node serves or receives the bytes. The IP address is the one item in this flow that encryption does not cover; the mitigation is that we neither choose nor record which node sees it.
• What we did instead of the impossible paperwork: the data is encrypted on your device before any byte leaves — encryption in transit and at rest is one of the safeguards the Korean decree requires for an overseas transfer (Enforcement Decree Art. 29-10(1)1, which points to Art. 30(1)), and it is the one we can actually guarantee here — and a working complaint route exists (section 1.2).
• Who places it there. For an upload you pay for, the ciphertext goes from your browser to the network: you place it, with your wallet and your signature, and we supply software. For an upload paid with credits that is not true and we do not argue that it is — the transaction is built and signed with our key and the storage object is registered at our address (Terms 10.11), so for those files we are the party that placed the ciphertext on the network.

9.6 You should know the residual risk, and we are not going to hide it. For the storage network, because we cannot name the destinations and cannot put safeguards in place with the nodes, a regulator could conclude that this arrangement does not meet the transfer rules. Our answer is that what leaves is encrypted with a key we do not hold, and that the alternative — not storing the file — is not a service at all. That is an argument, not a ruling. We keep a written assessment of this transfer and its residual risk, and we update it when the facts change.

9.7 Asking which countries your data is in. You can ask us, at nmts@nmts.me, which countries hold your stored information — the Terms, section 7.9, make this a right under your contract too. When you ask, we read the current set of storage nodes and the locations they declare about themselves on the public ledger, and send you what they say, together with the time we read it. We pass those declarations on unverified, because we have no way to check them; the set can also change after we send it.

10. Your rights#

10.1 We give every user the same rights, wherever you live. In many places the law already requires them — in Korea, 개인정보 보호법 Arts. 35 (access), 36 (correction and deletion) and 37 (suspension and withdrawal); in the EU and UK, GDPR Chapter III — and where it does, this section is how we meet it. Where a law gives you more, it applies on top of this.

10.2 You can:

• Ask what we hold about you. We will send you the rows we hold for your account — including the ones in section 2.8's credit ledger, operator note and all — together with: what we use them for, how long we keep them, who receives them (sections 5 and 9, including recipients outside your country and what safeguards, if any, stand behind those flows — today the honest answer is in section 9), where the data came from if not from you, and a reminder of the rights in this section. Encrypted values will be sent as they are — we cannot open them, but you can.
• Get a copy in a usable form. Two things. Your files are already yours: you can download any of them at any time with your own keys, without asking us. And the records about you that we hold because you gave them to us — your account record, encrypted file list, share records, device labels, terms acceptances, preview-channel record and credit ledger — we will send as a single structured file that another service can read, so you can take them elsewhere. Encrypted values go as they are.
• Correct something. In practice there is very little to correct, because you did not give us a name or an address. What can be corrected is what you can change in the product — your device labels, your settings — and anything you wrote into the support inbox.
• Delete. You can delete individual files, empty the trash, withdraw a support inquiry, and delete your whole account, all from inside the product and without asking us. Section 8 says exactly what each of those reaches, and what it does not — including the one limit we cannot lift, which is that a backup already written keeps what it holds until it ages out (8.1, 8-A).
• Freeze instead of delete. You can ask us to stop using a record but keep it — for example while we check something you dispute, or while an objection under 10.6 is being worked out.
• Complain. Section 15.

If we refuse a request, we tell you why, and that you can complain to an authority (section 15) and go to a court where you live.

10.3 How we check it is you. Your account code is the only credential we have and we do not hold it. So a request about a specific account has to come from a signed-in session for that account, or quote your public code from the inquiry it relates to. We will not accept an identity document instead — asking for one would mean collecting exactly the personal data this service is built to avoid. If you have lost your account code, we have no way to tell that an account was yours, and we will say so rather than guess. A legal representative can act for you — a parent or guardian, or someone you authorised in writing. We ask for what shows the relationship (in Korea, the commission form the PIPC publishes), we read it, we act on it, and we destroy it as soon as the check is done — we do not keep it.

10.4 How we answer, and how fast. Requests reach us through the support inbox or by email, and a person answers them by hand; there is no automated export button today, and we would rather say that than imply one. We answer without undue delay, and at the latest: in Korea, within 10 days; in the EU and UK, within one month, which can extend by up to two further months only for complex or numerous requests — and if that happens we tell you why within the first month. Everywhere else, where the local law sets a deadline we follow it; where none applies we do not promise one of our own, and we still answer without undue delay.

10.5 There is no charge for any of this.

10.6 Your right to object — stated on its own, because the law says it must be. You can object at any time to any of the legitimate-interest processings in the section 7.1 table: the abuse-prevention counters, the refused-application records, the credits we grant on our own initiative and the note we write with them, the service-wide totals, and the operator action log. Tell us at nmts@nmts.me. We will stop unless the interest demonstrably prevails for your specific situation, and we will tell you which it was. Two honest answers in advance: for the rate limit, we may not be able to keep your account open without it; and for the operator action log we will not stop, because a record of what an operator did that its own subject can switch off is not a record — we will say so plainly rather than pretend otherwise. The product also does not yet show you this right at the moment the human check runs; until it does, this policy is where it is stated.

10.7 Do Not Track and Global Privacy Control. We do not collect information about what you do over time and across other websites, so there is nothing for a DNT or GPC signal to switch off, and we have no arrangement with anyone to do so. What Cloudflare collects in delivering the site is governed by its own published terms (section 5).

Whether anyone else does it. No other party collects information about what you do over time and across other websites when you use this service. The only code on our pages that comes from another company is our edge provider's — the human check and the measurement script in 5.1 — and neither reports to us about anything you do elsewhere. We use no advertising or marketing vendor, and there is no other third-party tag on any page (3.2, 5.2).

10.8 For readers checking against the California Online Privacy Protection Act's list for posted privacy policies (Cal. Bus. and Prof. Code section 22575(b)): the categories collected and the third parties involved are in sections 2, 5 and 9; how to review and request changes is in 10.2; how material changes are announced is in section 14; the effective date is at the top of this page; our Do-Not-Track answer is 10.7, and so is our answer on whether any other party collects information about you across other websites.

11. Children#

11.1 The service is not directed to children. There is nothing here aimed at children: no child-oriented subject matter, characters, music, or advertising, and nothing that would make it attractive to a child in particular.

11.2 We do not knowingly collect personal data from children. We hold no age data and we cannot verify anyone's age, so what this means in practice is: if we learn that an account belongs to a child below the minimum age in section 3 of the Terms of Service, we stop serving it and delete the records we hold for it. Where we can reach the account holder or the parent — an open support thread, or the address a parent wrote to us from — we say so first and leave a reasonable chance to download the files, unless a law forbids that. Terms 16.3 is the limit of our reach: we hold no email address, so there are cases where we cannot say anything beforehand, and we would rather write that than promise a warning we cannot send. When we write to a child, or to a parent about a child, we write it plainly and simply.

11.3 If you are a parent or guardian and think your child has created an account, write to nmts@nmts.me with anything that lets us find the account — its public code, roughly when it was created, or the reference code of any support inquiry sent from it. If we can identify the account we act as in 11.2, and before we stop serving or delete anything we run the legal-representative check in 10.3; if we cannot identify it, we tell you so rather than guess. If you would rather see what we hold before deciding, ask for that instead — 11.5 says what you would get.

11.4 We do not build the service on consent (7.3), which is deliberate: it means we are not put in the position of needing to verify a child's age in order to know whether a consent was valid. The two exceptions are the board's two switches, and they are handled by keeping them away from children rather than by asking anyone's age: the board asks you to state that you are 14 or older before you can accept its terms at all, and both switches sit behind that statement. If we learn that someone on the board is below 14, we act as in 11.2, their board profile is closed, and a row stays behind that stops the same account opening another one — it holds no content and no nickname (2.12).

11.5 Our written retention rule for information about children. This paragraph is that rule, written out rather than assumed.

• What we would hold, and why. We do not ask for anyone's age, so we hold nothing that is marked as a child's. If an account turns out to belong to a child, what we hold for it is the same as for anybody: the account record in 2.1, file sizes and timestamps in 2.3, any share records in 2.4, and anything written into the support inbox. The purpose is the same too — running the account the person asked us to run.
• Why we would keep it at all, and for how long. Only for as long as the account exists — with one exception we have to name here, because it is precisely a record about a child. When we learn that an account belongs to a child we stop serving it and delete its records under 11.2, and we do not wait for the schedule in section 8: that deletion is immediate. What stays is the under-14 board bar. It outlives the board profile and it outlives the deletion of the account, for 5 years from the day it was made, or until the earlier day we lift it because you have told us you have turned 14. It holds which account, which reason, and the day it ends — no nickname, no content, no age and no date of birth. It stays because an account identifier is derived from the account code, so a bar that died with the account could be removed by deleting the account and creating it again.
• The honest limit, which a rule has to state. Deleting a record from the live database does not reach the encrypted backup copies in 8.1 — the disaster-recovery copies, encrypted with a key we hold. Those cannot be altered at all for 90 days, and are deleted automatically 91 days after they were written for an hourly copy, or 364 days for a daily one. So a child's account record can survive in a backup for that long after we deleted it, and there is no step we can take to shorten it. We are not able to call that deletion, so we describe it instead.
• A parent can see what we hold before, or instead of, asking us to delete it — write to nmts@nmts.me as in 11.3 and we will send the rows themselves, exactly as 10.2 provides for anyone.

12. Security, and what a break-in could and could not expose#

12.1 What protects your files is not a promise, it is the design: they are encrypted in your browser, with keys derived from a secret we do not hold. Your sign-in secret is stored as an argon2id verifier with a per-account random salt, so the secret itself is not in our database. Sign-in tokens are stored as SHA-256 hashes. Sessions expire. IP addresses are handled as described in 2.6. Operator access to the running system is limited to keys the operator alone holds, and actions taken through the product's administrative routes are recorded (section 2.10).

12.2 If someone got everything on our server — or the cloud account that holds our backups — they would have: your account id, your argon2id verifier and salt, your key-derivation version, timestamps, your encrypted device labels, your file sizes and timestamps, your encrypted file list, your encrypted key blobs, your sharing identity, your share records, your credit ledger, the identifiers of chain transactions your wallet signed for term extensions, and the readable text of any support inquiry, with anything you attached to it, that was inside its 30 days when a copy was taken — and because a copy is taken every hour the database changes, that is very nearly every message; in an old copy it can be older than 30 days by now.

12.3 They would not have your account code, your file keys or your file contents. Those are not on our server, or in any backup, in a form that can be opened without your code. They would have any file names, folder paths and storage addresses you chose to attach to a support inquiry that was still being kept — the same readable text as 12.2.

12.4 So the truthful summary is: a break-in would expose real information about you — how much you store, when you are active, who you shared with, and anything you wrote to support or attached to it — and it would not expose the files you have already stored. One further limit, the same one as 4.3: an attacker who could also change the code we serve could harvest what people type from then on, including account codes at sign-in — that is a risk to what happens after such a break-in, and it is the reason the encryption engine's source and the format are published at all (4.3). We do not claim any of this makes the first list matter less, and 4.3 states plainly what that publication does not prove.

12.5 We do not describe our security with slogans. The format is published so that it can be judged on its own terms.

12.6 Two honest concentrations of risk exist today, and we would rather name both. First, the encrypted backups, the wrapped key that opens them, and the passphrase that unwraps that key are all held with a single provider (Cloudflare), in separate services of one account; someone who could compel or fully compromise that provider could assemble all three. Second, a working copy of the key that opens the backups is kept on the same machine that runs the service, because that is what makes a restore possible without waiting on anyone — so someone who fully compromised that machine would have the live database and the copies going back as far as 8.1 says they are kept. What either of them would then have is 12.2's list — never your files or your account code.

13. If something goes wrong#

13.1 If personal data we hold is exposed, lost, or accessed by someone who should not have it, we will say so — unless, and only for as long as, a law or a binding order forbids us from saying it.

13.2 How we will tell you. We hold no email address for you, so we cannot write to you individually, and we will not pretend to have a channel we do not have. The law allows a public notice instead where individual notice is impossible or would take disproportionate effort, and that is the route we use: we post the notice on the notice board — a page inside the product and on the website, readable without an account, where every notice carries the date it was posted and stays there. The board is linked from the foot of the first page you see, whether or not you have an account, and it is not the update log, which lists what changed in each release. We keep a breach notice up for at least 30 days. While it is current, a line above every signed-in screen points to it until you dismiss that line, and if you have an open support thread we reply there as well. Where a law requires more — for example notice to statewide media in California — we do that too.

13.3 What the notice will say: what happened, when and how it happened, which categories of data were involved, what we have done about it, what you can do — including the one step that genuinely protects you here: create a fresh account and move your files to it, and we will explain how — and how to reach the person handling it (section 1.2).

13.4 When we tell you. Without undue delay after we establish what happened. In Korea we must notify you within 72 hours of becoming aware; in California, affected residents within 30 days of discovery. Everywhere else we hold ourselves to the shorter of those that could apply to you.

13.5 When we tell the authorities. Separately from telling you, and on their own clocks: in the EU and the UK, the supervisory authority within 72 hours of becoming aware; in Korea, the authority within 72 hours where the legal trigger is met; and any other competent authority within its own deadline.

13.6 Interruptions and security faults. If the service is interrupted without warning for ten minutes or more, or if we find a security fault, we post a notice on the notice board (13.2) without undue delay, keep it up for at least 15 days, and include: what happened, what caused it, what we have done, what you can do, and how to reach us. It stays up for half as long as a breach notice because an interruption is over when the service returns, while a breach may still call for something from you weeks later — and the person who signs in rarely is exactly the person that longer period is for.

14. Changes to this policy#

14.1 Every version has a version string in the form YYYY-MM-DD-vN and an effective date, both at the top of the page. Effect begins the moment that day's release goes live (UTC); the update log records the minute.

14.2 We do not edit a published version in place. A change means a new version string. We keep every version we have published, with the dates it was in force, and will send you any of them within seven days if you ask at nmts@nmts.me; the product displays the version in force and does not yet display the earlier ones.

14.3 We announce every new version of this policy before it takes effect, on the notice board (13.2), and the announcement is posted as a dated entry you can read and keep. A new version of this policy alone has the same effect as a new version of the Terms: the four requests named in Terms 15.5 wait until the acceptance record for the new pair (Terms 5.4) has been made.

14.4 We keep this policy continuously posted on the website, linked from the foot of every page, in both languages.

15. Complaints#

15.1 Please write to us first: nmts@nmts.me. We would rather fix something than argue about it.

15.2 You can also complain to a data-protection authority. You do not need to come to us first.

• Korea — Personal Information Protection Commission (개인정보보호위원회), and the 개인정보 침해신고센터 run by KISA. You can also apply, free of charge, to the Personal Information Dispute Mediation Committee (개인정보 분쟁조정위원회) — often the fastest route.
• European Union — the supervisory authority of the country where you live, where you work, or where the problem happened. The list is published by the European Data Protection Board.
• United Kingdom — the Information Commissioner's Office. UK law also gives you the right to complain to us directly. Where that law applies to us, we acknowledge and handle such complaints as it prescribes.
• United States — the Federal Trade Commission, and the Attorney General of your state. If you are in California, the California Privacy Protection Agency also takes complaints.
• Anywhere else — your national data-protection or consumer authority.

15.3 Wherever you are, you can also bring a claim in court; in the EU, the UK and Korea, the law guarantees you can do that where you live.

16. Language#

16.1 English is the canonical text of this policy. The Korean version is a full version of the same content, not a summary.

16.2 Where there is doubt about the meaning, the reading more favourable to you prevails, and the mandatory law of the country where you live prevails over both language versions. If you are a consumer habitually resident in Korea, the Korean version prevails for you. Subject to those rules, if the two versions genuinely conflict, the English version is the reference text.