PRIVACY / 2026-10-19

Privacy Policy

The version in force from 2026-10-19 until the revision of 2026-10-20. See the policy in force and its revision history

Trinity MathsLab collects only the information needed for pilot and adoption inquiries, recruitment review and running the EduLab community.

Information collected

An inquiry records your name, organization, role, email or phone, inquiry type, product and subject interests and preferred contact method; student scale, campus count, current teaching workflow and message are recorded only if you fill them in. We also store the referral (the campaign values of the link you came from and the previous page address) and the page language. To limit spam we keep a one-way hash of the connecting IP address for 24 hours; the address itself is not stored.

Application information

For recruitment, we collect name, email, optional phone, portfolio link, relevant experience, and application message. Do not submit sensitive identity information.

EduLab community members

Joining the EduLab community records your email address, nickname, affiliation (only if you choose one), the time you confirmed you are 19 or older, and the version of the terms you accepted. If you join or sign in with Kakao, we receive from Kakao Corp. your Kakao member number, the number Kakao uses for you on this service, and, if you agree, the Kakao account email address Kakao has confirmed. We do not receive your Kakao nickname or profile picture. The member number is used only to sign you in and to link your account; it is deleted when you leave, and we then ask Kakao to unlink you. If you unlink at Kakao, we delete the link. While you use it, we keep the materials and comments you write and whether they are public, your reports (reason and note), your meetup sign-ups, a record of the operator's moderation (who did what and when, never the text), and a count of your writing and reports for rate limits (who, what, when). Signing in keeps a sign-in record (start and end times and how you signed in) and one-way hashes of your email address and connecting IP address for counting attempts. Each time a member leaves, a material or comment is deleted, published or hidden, writing is stopped or allowed again, a nickname or affiliation changes, or a meetup sign-up is made or cancelled, a restore ledger records the entry's number, the kind and number of what changed, the meetup's number for a sign-up, the kind of change, the hiding reason category and hiding time, and the time, so that a restore from a backup keeps the result. The ledger holds no email address, no text and no changed value. We do not collect birth dates, real names or phone numbers.

Access records

Under Article 15-2(2) of the Protection of Communications Secrets Act and Article 41(2)2 of its Enforcement Decree, each time a community member signs in, writes a material or comment, or reports one, we record the time and kind, the connecting IP address, and the email address and member number that identify the member. The community passes members' posts and comments on to others, a value-added telecommunications service, so we keep this record as the law requires. It is kept apart from other personal information for three months from the day each entry is made and then deleted, also for the rest of that time after a member leaves. It is provided to no one except investigative authorities requesting it under the law.

Purpose

The information is used to answer and acknowledge inquiries, for product guidance, pilot qualification, adoption planning, and recruitment review, and in the EduLab community to confirm members and sign them in, show who wrote a material or comment, manage meetup sign-ups, and handle reports and moderation. Access records and the operators' processing records are used only to meet the legal duties to keep and check them. The restore ledger is used only to keep what was already done (leaving, deletions, hiding, corrections) when the database is restored from a backup after a failure, and the encrypted copies of the ledger, the access records and the operators' processing records only for that and for keeping, checking and recovering those records safely.

Retention

Inquiry records are deleted automatically 12 months after the inquiry and related discussions end, and in any case 36 months after receipt. Application records are deleted 12 months after receipt, unless a longer period is required by law. EduLab community member information and the materials, comments and meetup sign-ups a member wrote are kept until the member leaves and deleted at once when they do. Sign-ups that never entered their code are deleted after 24 hours, pieces the operator hid 30 days after they were hidden, meetup sign-ups 30 days after the meetup, and resolved reports and moderation records after 12 months. Reports made by a member who left are kept for that time without the reporter. Sign-in records are deleted 7 days after the sign-in ends or expires, attempt hashes and the writing and report counts after 24 hours, and each access record three months after it was made. Records of an operator viewing or handling members' information are deleted one year after each entry is made. The restore ledger keeps each entry for eight days from when it is recorded, after which the hourly clean-up deletes it. Encrypted copies of the ledger, the access records and the operators' processing records are deleted 24 hours after they are made; the exceptions and their limits are under How information is destroyed. Records brought back from a copy are kept only for the rest of their period, counted from when each was first recorded.

How information is destroyed

Database records are deleted on their defined clean-up schedules once their retention period ends or their purpose is met, and the service does not restore them. Inquiry and application records are cleaned up once a day, everything else hourly. Emails in our business mailbox are not part of that clean-up: the person in charge deletes them under the periods given in Transfer abroad. The production database is backed up automatically once a day and each backup is kept for seven days, so deleted information is gone from the backups within seven days of its deletion. Until then the backups are used only to recover from failures, and they include the restore ledger. While restoring we stop the community, and we reopen it only after the ledger and its copy have been used to apply again the deletions, hiding and corrections already made. If what changed after the last copy cannot be established, existing community accounts are held, each with a notified confirmation deadline no later than 14 days after the hold starts; we do not delete unconfirmed accounts before that deadline. The community stays stopped from the start of the restore until the person in charge has done the final recovery checks: sign-in, joining, writing materials and comments, reports, meetup sign-ups and nickname and affiliation changes stop for every member, including those already confirmed, while reading and the requests under Your rights go on. It reopens only once every held account is confirmed or deleted, the clean-ups run again and have succeeded, a valid copy matching the restored state has its post-restore acknowledgement, and the requests received and the notice are checked; the last held account being settled does not reopen it by itself. Even without an account hold, reopening may wait until the next day for post-restore clean-ups to succeed; if an error or a check delays it further, we give the reason and the next update time. Held accounts cannot sign in, their materials and comments are hidden, and their meetup sign-ups and unfinished sign-ups are deleted, so restored information that has not been confirmed is kept out of ordinary use and admin work; only the person handling the recovery deals with it, as far as needed. When the community stops, we post a first notice without delay in the KakaoTalk open chat notice, which is separate from the site, and the same notice on the community's first page as soon as it is accessible; when a hold starts, we tell every affected member, through those notices and by email to registered addresses, why, which features stop, the deadline for confirming, what must happen before reopening, when the next update comes, and how to make requests about your information. We give back only accounts whose owners confirm from their registered email address who they are and that they want to go on: the operator checks one by one, before showing them, only the pieces the owner confirmed again, and only a nickname and affiliation the owner confirms again or enters anew are used. Unconfirmed pieces hidden by the hold are deleted, and meetup sign-ups are made again. Pieces hidden earlier because of a report or a rights infringement keep their own reasons and deadlines and are not shown when the hold ends. Once the restore has been compared, the clean-ups are turned on again and checked to succeed before the hold runs its course; accounts not confirmed by their deadline are deleted with their pieces at the hourly clean-up after it, and they stay unable to sign in until then, even if the clean-up is late. Accounts confirmed to have left, or whose deletion was asked for, are deleted at once without waiting for the deadline, and if every account is settled early the community reopens early, after the final checks. If the clean-up or the reopening is late, we post why and when the next update comes, and resolve it without delay. The 14 days are not a grace period set by law but the longest period we allow for members to see the notice and reply; the stop is not promised to end within them. During the hold you can still exercise your rights by email at the address under Your rights. The restore ledger, the access records and the operators' processing records are also kept as encrypted copies on a device we manage in Korea. A new copy is made about every five minutes when something changed and at least once a day, and each copy is deleted at the next clean-up once it is 24 hours old. While no new copy can be made, the newest one is kept for up to seven days from when it was made; when something looks wrong, such as the database going back in time, or an incident requires it, we stop deleting copies, with a stated reason and end date, for up to 30 days from the stop, within the 37-day limit below, and restrict access to them. Lengthening or setting a hold again does not start a copy's time over: a copy more than 37 days old is deleted at the next clean-up, hold or not. Pausing the copying does not stop copies past their time from being deleted. If the copying cannot run at all, for example because the device is off or its clock is far off, the clean-up stops too, so the person in charge fixes the device and runs the clean-up, or deletes the copies by hand, before that time is up, and records what was done. Legal records that survive only in a copy after the original is lost are brought back separately before that time, kept for the rest of their period counted from when each was first recorded, and the rest is deleted. Copy files past their time are deleted and not used again. Because pieces of a deleted file can remain on the device, we change the key that opens the copies every month, check that no copy locked with the old key remains, then destroy the old secret key and record the result. Until then, and while copies are kept from deletion, the old key is restricted to the work computer of the person in charge and the approved password-manager copy, and when no longer needed it is retired from both and from any recoverable copies under the documented procedure, and checked. Access records and the operators' processing records kept under the law are stored apart from other information and deleted the same way when their period ends. We do not keep personal information on paper.

Processors

We entrust processing to these companies. Vercel Inc.: operating the website, visit analytics, handling inquiry and application submissions, and running the EduLab community's pages and writing (submissions and writing are handled in its Seoul region). Supabase Pte. Ltd.: storing inquiry and application records and the EduLab community's member information, pieces and access records (Seoul region), and sending sign-in code emails for the community and the admin pages. Zoho Corporation Pte. Ltd.: providing the mail server for the sign-in code emails Supabase sends, for which it receives only the recipient's email address and the email's content (the code); it also hosts our business mailbox, which stores the inquiries and requests about your information exchanged with us, our replies, and a recovery's hold notices and confirmations. Solapi Co., Ltd.: sending the receipt for an inquiry or application that includes a mobile number, and the new-submission alert to our operator, as a KakaoTalk notification or text message; it receives only the recipient's mobile number and what the message contains (name, contact number, email for applications, inquiry or role type, receipt number). Solapi passes this to KT Corporation and LG Uplus for text messages and to Biztalk and DK Techin for KakaoTalk notifications. Each company's own sub-processors are listed by the company: Vercel vercel.com/legal/sub-processors, Supabase supabase.com/legal/customer-resources/subprocessor-list, Zoho www.zoho.com/privacy/sub-processors.html, Solapi solapi.com/privacy. Access is limited to the operators who need it.

Transfer abroad

Personal information is transferred abroad, or may be processed abroad, to run the service, to send sign-in code emails and to handle business email. Legal basis: for (1) and (2), and in (3) for the code emails and for business emails to the extent actually needed to conclude or perform our agreement with the person concerned, disclosure in this policy under Article 28-8(1)3(a) of the Personal Information Protection Act, as processing and storage entrusted for concluding and performing our agreement with you. (1) Vercel Inc., a US company; privacy contact privacy@vercel.com. Country: the United States, where Vercel's primary processing facilities are; it may also be processed in other countries where Vercel or its sub-processors have processing facilities, listed in the Vercel list above. The site's server processing and form submissions are handled in the Seoul region, and form contents are not kept at Vercel. Items: the connecting IP address, browser details, and the requested address and time recorded in request logs, and the visit information described under Analytics below. When and how: sent over the network each time you open the site. Purpose and retention: running and securing the website and analysing visits. The request logs we can see are kept for one day, and the visitor identifier of the visit analytics is discarded after 24 hours. How long Vercel keeps records it holds separately for security and operations, and records arising from use of its services that Vercel processes for its own purposes under its own policy, is not published. (2) Supabase Pte. Ltd., a Singapore company; privacy contact privacy@supabase.com. Its US company Supabase, Inc. shares operations and support. The database, sign-in data and backups are stored in the Seoul region. Requests to and from Supabase pass through the network of Cloudflare, Inc., which Supabase engages, and this site's requests are handled at that network's Seoul point of presence. However, when we ask for support or a security incident is handled, Supabase staff may access them remotely; support staff are in several countries, which are not published. Logs and service records kept to operate and secure the service are processed outside Seoul and stored in data centres in the European Union, in countries that are not published. Countries: Singapore, the United States, the European Union, and the countries where support staff are. Items: in remote access, what the database holds (inquiry and application records, the community's member information and pieces, access records and the operators' processing records); logs may contain the time and path of requests, the email address a sign-in code is sent to, and part of what a failed request carried. When and how: remote access when support or incident response requires it, and logs over the network each time the service is used. Purpose and retention: storage, operational support and security only. Remote access is limited to what the request requires and is itself logged. On this account's plan logs are kept for seven days; how long records kept longer for operations and security are kept is not published. What the database holds follows the retention periods in this policy. (3) Zoho Corporation Pte. Ltd., a Singapore company; privacy contact privacy@zohocorp.com. Country: the United States, where Zoho's data center for our account is. Items: the recipient's email address and the email's content (the code); and the addresses and contents of business emails exchanged with us (inquiries, requests about your information and our replies, and what a recovery's hold notices and confirmations need). When and how: sent over the network each time a code is requested for joining or signing in to the community or signing in to the admin pages, and each time an email is exchanged with us. Purpose and retention: sending the code emails, and handling inquiries, requests and recovery notices. No copy of a code email is kept in our sending mailbox. Business emails are deleted without delay once the inquiry or request has been handled and they are no longer needed. For a request about your information we keep only a minimal record of when it came, what was asked, what was done and when you were told, for as long as needed to answer an objection and at most one year. Records another law requires us to keep are kept separately for that period. Zoho keeps the recipient's email address, the subject and the time sent in the delivery logs of its mail administration, for a period it does not publish. If we delete our Zoho mail organisation, Zoho permanently deletes its data 30 days later. How to decline and its effect: (1) and (2) are needed to run the site, so declining them means not using the site; you can then send inquiries and applications to the address below. (3)'s code emails happen only when you request a code. They are needed when you join or sign in with an email code, or when a Kakao sign-up has to confirm the email separately; no code email is sent when you join with the email Kakao has confirmed or sign in through an already linked Kakao account. Anyone can read the community without joining. Business emails arise only when emails are exchanged with us.

Automated-submission check

The site's inquiry, application and community forms and its admin sign-in page do not use Cloudflare's automated-submission check (Turnstile), so nothing is sent to Cloudflare for such a check. If we use it again, we will first ask for a separate consent and update this policy.

Under 19

The EduLab community accepts members aged 19 or older. You confirm this yourself when joining. If we discover that a member is under 19, we stop their use and promptly destroy the related personal information as required by law. A child's legal representative may also write to the address below to have the child's personal information removed from a post.

Personal information in posts

We ask members not to post students' names, schools, grades or photos, or phone numbers and email addresses, and check each piece automatically before it is saved. Reported pieces are hidden or deleted, and a piece reported for student information is hidden at once until the operator has looked at it.

Sensitive information made public

Community materials and comments become public to anyone as soon as they are posted. A piece that looks like it holds a student's details, or one posted while the operator has turned on checking before publication, becomes public once the operator has checked it. Please do not post sensitive information such as health, beliefs or sex life. Anything you do not want public you can leave out, or delete at any time on your account page after posting.

Sign-in cookie

The EduLab community and the admin pages keep you signed in with one HttpOnly sign-in cookie in your browser. A member's sign-in ends after 30 days and the operator's after 12 hours. You can block cookies in your browser settings, but you then cannot sign in. Reading needs no cookie.

Inquiry drafts

An unfinished inquiry is temporarily kept in this tab’s browser sessionStorage so you can read the policy or change language. It expires 30 minutes after your last edit and is cleared after successful submission or when you clear the draft. Consent is not saved and the draft is not sent to our server before submission. Recovery is unavailable when browser storage is blocked.

Analytics

We use Vercel Web Analytics and Speed Insights to understand visits. Without cookies, they send Vercel only aggregate information such as the page address, the referrer, and the browser and device type, plus page performance; names, emails, phone numbers and messages are never sent as analytics. You can block this with your browser's tracking protection or a content blocker.

Security measures

Only the operators who need it can see personal information; they sign in with an emailed code or a passkey, and that sign-in ends after 12 hours. All traffic is encrypted with HTTPS. The website's server uses the database only through set functions, and ordinary users cannot read or write it directly. A separate account used only for the copies can read three things (the restore ledger, the access records and the operators' processing records); besides that it may only call a dedicated function that records when a copy was acknowledged, and it cannot change member information or the three records. The copy files are encrypted with a public key, and the secret key that opens them is kept apart from the device that holds them. Copies are opened only with the set tools, which record before and after each opening the time, the account and device of the person, what it was for, the file and the result. If there is no acknowledgement of a valid copy, or more than 24 hours have passed since the last one, or a restore has begun and the person in charge has not yet done the final checks, or accounts are still held after a restore, the website stops by itself sign-ins, joining, writing materials and comments, reports, meetup sign-ups, nickname and affiliation changes and the admin handling of members' information. Reading still works, and with a valid session you can delete your pieces, cancel a sign-up or leave. If you cannot sign in, for example while your account is held, you can make the same requests by email at the address under Your rights. Connecting IP addresses we store are handled as one-way hashes instead of the addresses themselves, except in the members' access records and the operators' processing records the law requires us to keep. Under Article 8 of the Personal Information Protection Commission's standards on security measures, each time an operator views the member list, meetup sign-ups or pieces awaiting review in the admin pages, or handles a member's piece or stops their writing, we record the operator's account, the time, the connecting IP address and the task, together with the numbers of the members, pieces and meetups it concerned. The record is written in the same database operation as the viewing or handling, so if it cannot be written nothing is shown or done. Operators see other members' unpublished or hidden pieces only in the review page that keeps this record. The record is kept apart from other information; the website's server cannot read, change or delete it, and only the database's clean-up job deletes entries past their retention period. It is checked every month and each entry is deleted one year after it is made, also for the rest of that time after a member leaves. The operator's moderation is recorded separately, and information past its retention period is deleted automatically.

Your rights

You may request access to, correction or deletion of your personal information, that we stop processing it, or withdraw your consent. In normal use, EduLab community members can change their nickname and affiliation on their account page and leave, which deletes their information. During a sign-in restriction, account hold or service interruption, you may still request withdrawal, deletion or other rights by email at the address below, without signing in or reclaiming an account. If you cannot use your registered email address, we confirm your identity another way, as far as necessary, and send the outcome through a secure channel agreed with you. Your legal representative or an authorised agent may also make a request; we confirm identity, representation or authority only as far as necessary. We give access within 10 days of receiving the request, and if we postpone or refuse it, we tell you why and how to object within that period. We correct, delete or stop processing without delay and tell you the outcome, or why we cannot do it and how to object, within 10 days of receiving the request. During an account hold or a service interruption we keep to the same periods, without waiting for other members' confirmations or the hold's deadline. Send objections to a request or its outcome to the address below. If we cannot do what you ask, for example for access records the law requires us to keep, we tell you why and how to object.

Privacy officer

Our privacy officer is the representative, 김성민. Send questions, complaints or requests for redress about personal information to the address below.