What is collected, why, and what you can ask for

Korat operates from Thailand and is subject to the Personal Data Protection Act B.E. 2562 (PDPA). This notice covers the Android app, the web app and this website. We ask for consent before an account is created, on a screen you have to scroll to the last line, and declining is a real option that stops the sign-up there. The controller can be reached at privacy@koratland.com.

What is collected

Account

email, password (hashed by our authentication provider — never stored readably), display name, nickname, your Korat ID, and the language you chose

Profile

whatever you choose to fill in: profile and cover photo, bio, gender, birth date, addresses, education and work history, skills and languages, interests, emergency contact, family or partner relationships. Every field has its own visibility: public / friends / private. There are 35 of them today, and they are not all enforced at the same layer — see per-field privacy below, which says how far each layer reaches

Content

posts, comments, stories, photos, albums, group memberships, and the messages you send including voice notes, files and shared locations

Commerce

orders, table sessions, room bookings, table reservations, appointments, packages, receipts and reviews — with the shop you transacted with

Health

only if you turn the Health module on: activities, distance and route, step counts, and daily entries you make such as water, weight or sleep

Dating

only if you turn Dating on: dating photos, prompt cards, filters, and approximate location used to compute distance

Devices

one row per install: device name, platform, app version, last-seen time and a notification token — so you can see and revoke your own sessions

Links

when someone opens a Korat share link the click is counted, with country, referrer and user agent. The person who made the link sees a count, not visitors

Support

what you write to us, and an audit record when an operator looks up your account

Sensitive data (s.26). PDPA s.26 requires explicit consent for certain categories — health, religion, race, disability, and data revealing sexual orientation. In this product that data sits in three places, not two, and the previous version of this notice described only two modules.

Sensitive profile fields

religion, how devout you are, sexual orientation, nationality, blood type, chronic conditions, regular medications, drug allergies, food allergies and disabilities — every one of them is blank until you type into it, none is needed to hold an account, and each can be cleared at any time. None of them sits behind any module switch, so the mechanism the previous notice relied on does not reach them, by its own definition. · From this version, religion, how devout you are and sexual orientation default to ‘private’, and blood type, chronic conditions, regular medications, drug allergies, food allergies and disabilities are not sent to other users at all — the detail, and the limits that remain, are in the next section.

Health module

activities, routes, step counts and the daily entries you log — there is no separate on/off switch. The data exists only if you record it, and does not exist if you do not.

Dating module

dating photos, prompt cards, filters and swipes, which reveal sexual orientation — this one does have a real switch, at Settings → Dating, and turning it off removes you from everyone's deck immediately.

Per-field privacy — where it is enforced, and where it does not yet reach

The previous notice said the value you set was “enforced by the screens, not by the database”. That sentence is now less than the truth in one place and still exactly the truth in another, so it is written out here as the three layers it actually is. There are 35 fields.

Enforced in the database — 3 fields

Education history · work history · shop verifications. These three live in tables of their own, and the database's own access rules filter the rows by the value you set ⇒ someone you have not permitted cannot read them, through the app, through the web, or by calling the API directly. · And the count is closed with the list: setting verifications to private used to remove the shops' names while leaving the number — “verified by 3 shops” — on the page, which is worse than not hiding it at all. Both are gone now.

Enforced by the profile reader — 21 fields

The rest of the profile: names, nickname, bio, gender, birth date and age, relationship status, interests, height, province, nationality, religion, how devout you are, sexual orientation, drinking, dietary restrictions, skills and languages. · Both the app and the web have stopped reading the users table directly and go through a server-side profile reader that drops what you have hidden before anything is sent ⇒ a value you have hidden never travels to the screen at all, rather than being hidden as it is drawn. (Your friend list has a reader of its own that works the same way.) But read the box below — this layer has not closed every door.

Sent to nobody, so there is no switch — 10 fields

Blood type, chronic conditions, regular medications, drug allergies, disabilities, food allergies, favourite foods, disliked foods and taste preferences are not in the profile reader at all, whatever your relationship to the person, and no screen draws them for anybody else. ⇒ There is nothing to configure, so the profile editor removed the switch and states the fact instead: a three-way control over data nobody can see is a padlock with nothing behind it. (Your résumé is in this group too, because it already has a switch of its own.)

Someone with no account cannot read a single column of the users table — measured from outside: the request is refused at the privilege layer rather than answered with an empty result. Everything in the limit above is about signed-in accounts, not about the public internet.

The defaults have changed, and they moved only narrower. Every field used to start at ‘public’, the same value for all of them ⇒ anyone who never touched a padlock — which is nearly everybody — had their religion, how devout they are and their sexual orientation public by default, on a screen that drew a padlock beside each one and so read as though something were protecting them. Now religion, religiosity and sexual orientation start at ‘private’, and full birth date, nationality, height and weight, drinking, dietary restrictions and your friend list start at ‘friends’. The default is applied when a value is read ⇒ we have not overwritten a single value you set yourself, and nobody is more exposed than before because of this change.

Search no longer matches on a field you have hidden. Being findable by a hidden field discloses it just as surely as displaying it, so a hidden value is not returned in search results — and on the web, someone who matched your query only through a hidden field is dropped from the results entirely. · The Android app cannot drop them yet: the value itself is hidden, but the account can still surface in a search through a name set to private. We write the two halves separately rather than claiming “search respects your settings”.

Whether filling in a sensitive field, or logging health data, meets the ‘explicit’ standard in s.26 is a legal question we have not had a specialist answer. So this page describes what the system actually does and does not write that answer itself.

What it is used for, and on which lawful basis

PDPA s.19 requires consent unless one of the s.24 exceptions (or s.26 for sensitive data) applies. So we name a basis per purpose, rather than putting everything under "consent" — which the PDPC's guidance says specifically not to treat as a catch-all.

Creating and running your account

contractual necessity (s.24(3))

Delivering messages, calls, posts and groups to the audience you chose

contractual necessity (s.24(3))

Placing an order, opening a table, taking a booking, computing a bill

contractual necessity (s.24(3))

Ranking your feed and suggesting friends

legitimate interest (s.24(5))

Sending the notifications you asked for

contractual necessity (s.24(3))

Telling you a new device signed in

legitimate interest — security (s.24(5))

Preventing abuse, fraud and spam

legitimate interest (s.24(5))

Enforcing age rules for alcohol and venue admission

legal obligation (s.24(6))

Keeping transaction records

legal obligation — accounting and tax (s.24(6))

Dating module

explicit consent (s.26) — new accounts start off, and turning it on is recorded with a timestamp

Health module and sensitive profile fields

explicit consent (s.26) — no switch: fill nothing in and log nothing, and there is no data

Marketing messages

see the next section

Korat does not sell personal data, and there is no advertising. No advertising identifier, no ad network, no data broker.

Marketing — and what does not exist yet

Three kinds of message are not the same thing. Service messages — order status, a booking confirmation, the alert that a new device signed in, a moderation decision, a password reset — cannot be turned off while you have an account, because they are the service, not marketing. Feature notifications — a message, a like, a comment, a friend request, a group post — have per-type settings in the app. Marketing is this section.

There is one account-level flag in the database for opting out, and when a campaign's recipient list is built, people who have opted out and people who are suspended are filtered out at the moment the list is written, not at send time — so someone ineligible is never written down at all. Audiences are structured criteria the server interprets, never SQL from a client, and an unrecognised criterion is rejected, not ignored: a silently dropped filter turns an audience of 200 into everybody, and that send cannot be recalled.

Who else can see it

Other users see what your privacy settings permit — public, friends, or nobody — within the limits the per-field privacy section above sets out layer by layer. A chat is readable by its two participants. A group post is readable by that group. A shop sees what it needs to serve you: your name on the table, what was ordered, and the address you gave for delivery. Dating deliberately shows less: a chat that came from a match shows your nickname, not your real name or email, until you are friends.

A shop you transact with is a data controller in its own right for the customer data it holds, not our processor, so the PDPA's obligations fall on it directly — and the terms, section 6, forbid a shop adding you to its marketing list because you ordered.

A shop cannot message you first — and that is a rule in the database, not a hidden button. The right to start a conversation with a shop is yours: while you have never sent that shop a message, its staff cannot message you, and cannot leave an empty chat room open either. A shop’s automated messages are under the same rule, with no exception even for messages about an order. · The direction is deliberately reversed for calls: a shop can call you only inside a conversation you opened, and you can call a shop only once it issues an invitation — which names the one member of staff who can be reached, is good for a single call, and expires by itself (24 hours by default). And a shop can only issue that invitation if you messaged it first, or the invitation would itself become a way to contact strangers.

Blocking is enforced in the database now, and it is enforced both ways. The app used to say «blocked» while the server enforced nothing whatsoever. Now, when a block exists, neither side can message, call, send a friend request, like in Dating, follow, or tag a relationship — and a notification between the two is never created in the first place, so nothing arrives on a lock screen. It is enforced by database triggers rather than by access rules ⇒ it binds even our own highest-privilege access. · Nothing is deleted and reads are untouched. The history stays intact on both sides, because that is what you need in order to report someone, and a room that vanished from one side would be a disclosure in itself. · The refusal is deliberately causeless: a blocked account, a suspended account and a deleted account all produce the same sentence. The sender learns the message did not arrive, and never learns why — because a refusal that says “you have been blocked” hands a harasser confirmation that they reached the right person. · There is no way, and there will never be a way, to ask who blocked you.

Otherwise we disclose personal data only with your consent, where the law requires it, or to protect rights and safety.

Where the data travels

Your data leaves Thailand. The primary database, authentication and file storage are with Supabase in Singapore; the website and edge endpoints are with Cloudflare on a global edge network; and push notifications and outbound email run through Google's infrastructure. They process on our instructions.

PDPA s.28 permits transfer to a destination with adequate protection, on a list the Personal Data Protection Committee issues. The Committee has not issued that list. Its two notifications of 25 December 2023 (the criteria under s.28 and under s.29) came into force on 24 March 2024, and no country has been designated adequate. Singapore is therefore not a recognised destination, and the transfer relies on appropriate safeguards under s.29 — standard contractual clauses.

How it is protected — and where that stops

Everything travels over TLS. Access is enforced by row-level security in the database, so a request for data that is not yours returns nothing, whether it comes from the app or from someone calling the API directly. Verification codes are stored hashed, and devices can be revoked one at a time.

PDPA s.37(4) requires a breach to be notified to the Committee without undue delay and, where feasible, within 72 hours of becoming aware of it, unless it poses no risk to the rights and freedoms of individuals; where the risk is high, the affected people must be notified too, with the remedial measures.

How long it is kept

Account and profile

while the account exists

Content — posts, comments, photos, messages

while the account exists, or until you delete it

Stories

expire by themselves

Transaction records — orders, bookings, receipts

held by the shop you transacted with, for as long as that shop's accounting and tax obligations require

Device rows and notification tokens

until the device is revoked or the account is deleted

Admin audit records

append-only — a database trigger rejects update and delete

When you ask for deletion we delete your account and your personal content. Records a shop is legally obliged to keep may remain in that shop's account, without your profile attached. Admin audit records cannot be erased, as above — that is deliberate security, and we say it here rather than let you discover it.

Your rights

Under PDPA s.30–36 you may access your data and ask for a copy (s.30) · ask for portability in a machine-readable form (s.31) · object to processing based on legitimate interest, and to processing for direct marketing (s.32) · ask for erasure or de-identification (s.33) · ask for restriction of processing (s.34) · ask for rectification so the data is accurate, current and complete (s.35) · and withdraw consent at any time (s.19), as easily as it was given. You may also complain to the Personal Data Protection Committee.

Deleting your account is something you do yourself, in the app and on the web — in the app at Settings → Delete account, and on the web at koratland.com/delete-account, which works with no app installed. Both are a request with a 30-day grace period: the account is given a deletion date, keeps working until then, and you can cancel it yourself at any point before that day. We notify the account the moment a request is filed, in case the person who filed it was not you.

Downloading your data is still a person reading email, not a feature. Write to privacy@koratland.com from the email on the account, or tell us your Korat ID. We verify who you are first — an unverified request is itself an attack — and answer within 30 days. The same address handles deletion if you can no longer sign in.

Three things you can do yourself, immediately, without asking: change the visibility of any profile field, album, post or story; turn Dating off entirely, which hides the module and removes you from everyone's deck; and block any account, which takes effect at once in both directions and is enforced in the database as described above.

Children

Korat is not intended for children under 13, and Dating requires you to be 18 or over. If you believe a child has created an account, tell us at privacy@koratland.com and we will remove it. The child-safety prohibitions, the reporting routes, the age gates that are actually enforced and the things we still cannot do are all set out on the child safety standards page.

Language and changes

The Thai text is the only authoritative version. The other nine languages are provided for convenience and have no independent legal effect; where they conflict, the Thai text governs. This notice may change, and a material change is announced in the app. Version 3.2 — it replaces version 3.1, and what changed is the description catching up with what the system now enforces, not a change in how we use your data: per-field privacy is set out as three layers, each saying how far it reaches; the sensitive fields now default to ‘private’ and the identifying ones to ‘friends’; the web honours per-field visibility as the app does; search no longer matches on a hidden field; and blocking, and the rule that a shop cannot message you first, are enforced in the database — the previous version mentioned neither of those two. The in-app consent screen still shows 3.1 until the next release; where the two numbers differ, this page governs.

Contact

privacy@koratland.com for anything about your data. hello@koratland.com for everything else.