ERDism beta

Privacy policy

Previous version — no longer in effect. This is the version of 2026-10-27. Read the current version.

Last updated: 2026-10-27

1. Who is responsible for your data

Cutaway Works, based in the Republic of Korea, operates ERDism and is responsible for the personal data described here. In this policy "we" means Cutaway Works.

Privacy officer. The person responsible for personal data at Cutaway Works is its representative, Lee Sang-mo. You can reach them at [email protected] or by telephone on +82-502-1921-2350 (0502-1921-2350 from within Korea). For anything about your data, write to that address.

2. What we collect

Account and sign-in. Your email address, whether it has been confirmed and when, and a status for the account. If you sign up with a password, we store a bcrypt hash of it and never the password itself. If you continue with Google or GitHub, we store the identifier that provider uses for you, the email address it reports, and whether the provider says that address is confirmed. The access token the provider issues is discarded and never stored.

Until you confirm your email address, an account signed up with a password can do only a few things: confirm the address, have the confirmation email sent again, correct the address, sign out, or close the account. An account whose address is not confirmed within seven days of signing up is deleted. If someone signs up with an address that belongs to an account nobody has confirmed yet, the new sign-up replaces that account.

Two-step verification and passkeys. If you turn on two-step verification, we store the secret your authenticator app uses, encrypted, the last time a code was accepted, and your recovery codes as bcrypt hashes (each is shown to you once, when it is created). If you add a passkey, we store its public key and identifier, the name you gave it, details your device reports about it (its model identifier, how it connects, and whether it is synced), and when it was last used. Your device keeps the private key; we never receive it, or your fingerprint or face.

Country and agreement records. When you sign up or sign in, we note one country for your account, estimated from the languages your browser asks for (for example ko-KR). It is used to count where the people who use ERDism are, and nothing else; it is not shown to other people, and you can ask us to correct or remove it (section 10). We also record which version of these terms and this policy was in force when you created the account, and when.

Profile. A display name, an optional short bio, avatar settings — either initials or the address of an image — and the interface language you chose. When an account is created the display name is taken from the part of the email address before the @, and you can change it afterwards. Nothing is copied from your Google or GitHub profile name.

What you create. Projects, diagrams, tables, columns, keys, indexes and relationships, the SQL that goes with them, any SQL you paste or upload, and the documentation pages you write.

Connected databases. If you connect a database to a project, we store the connection's name, the host name or IP address, the port, the database name, the user name, the TLS setting and any CA certificate you give, and the password. The password is stored encrypted (section 11) and is never shown again, not even to you. ERDism reads only the database's schema — the definitions of its tables — and never the rows in it. For each read we keep when it ran, whether it succeeded and, if not, a reason code, the server's version, the number of tables, a fingerprint of each table's definition, and the differences found between the database and the project. Each distinct version of the schema we read is stored as normalised SQL. When a read finds a difference or the database cannot be reached, we record who was told about it.

Views of a public link. When someone opens a project through its public link (section 9), or downloads its SQL from there, we record one line per view or download: which it was, the project and workspace it belongs to, when it happened, and the main language the viewer's browser asked for (for example en). The line holds no account, even if the viewer is signed in, and no IP address, browser details or link.

Activity records. Every edit is recorded, because the product shows a history and offers undo across a whole project. A record holds what changed, the state of the changed item before and after, which workspace member made the change, and any reason that person typed. Signing in and closing an account are recorded too. We also keep, per account, which workspaces and diagrams you opened recently (to show them on your home screen) and, once a day per project, the fact that you opened it (to count how many people use a project each month). Turning two-step verification on or off, using a recovery code, and adding, renaming or removing a passkey are recorded too.

Use of checks and database reads. Each time someone runs an SQL check, compares SQL with a project, or reads the schema of a connected database, we record that it happened, when, in which workspace or project, and which account did it — never the SQL or the schema itself. We use these records to run the service and, later, to measure how much a workspace uses for its plan.

Creating, changing, pausing, resuming and deleting a connected database is recorded too, with the connection's name, host, port, database name and user name — never its password.

Invitations. The email address a workspace invitation was sent to. It stays on the invitation while the invitation is open, and it is also written into the activity record of the invitation, shortened to its first letter and its domain (for example a***@example.com). Thirty days after an invitation is declined, withdrawn or expires, the address on the invitation is shortened the same way; on an accepted invitation it stays, because it is the address of the member who joined. When someone cannot be given editing rights because a workspace's editor seats are full, we keep a note of their address so that the owner can be told; thirty days later that note is deleted and the address in the owner's notice is shortened. Section 4 describes who can see these addresses.

Your inbox. Messages the service leaves for you inside ERDism — invitations, and notices such as being removed from a workspace or becoming its owner — with what happened, when, and whether you have read it. Service notices that we send to everyone, such as planned maintenance, appear there too; for each one we keep whether you have read it or removed it from your inbox. A notice of planned maintenance, when the service will be unavailable, is also sent by email to every account.

Live demo. Opening the live demo gives your browser a temporary demo session on our server with its own sample workspace. It is not linked to any account, and it is deleted, together with anything you did in it, once it has not been used for about thirty minutes.

Feedback you send. When you send feedback from inside ERDism (Send feedback, available once you are signed in), we receive it as an email to our own mailbox. That email holds what you wrote and the kind of feedback you chose, your email address and your account's public identifier (so that we can reply), the page you sent it from, the version of the app, your browser's user agent string (so that we can reproduce a problem you report), and the time it was sent. ERDism does not keep a copy of it in its database. If you write to [email protected] instead, we receive what you put in that email.

Usage analytics. Which pages you open and which features and buttons you use in ERDism, and how long an editing session lasts, recorded by our own server under a pseudonym rather than your account. Section 5 describes exactly what is recorded and how to turn it off.

Technical data. For each request the server writes a line holding the HTTP method, the path, the response status, how long it took, and the internal identifier of the signed-in account. That line does not record your IP address, your browser's user agent, the query string, or the request body. (Feedback you send is the one place your user agent is passed on, as described above.) Your IP address is used as a counter key for the limits on failed sign-in attempts, on emails the service sends on your request and on requests to public links; those counters live for one hour at most and the address is not kept anywhere else. To limit how many emails go to one address, we also keep a counter keyed by that email address, for one day at most. In the server log, the code in a public link's address is cut to its first four characters. When we send you an email, the log keeps only the domain of your address and a one-way hash of it. When you sign in with Google or GitHub, the log line about it holds the identifier that provider uses for you.

If an email we send cannot be delivered, or is reported as unwanted, Amazon SES tells us, and that report — which holds the address it was sent to — reaches our mailbox.

We do not collect payment details, a telephone number, a postal address, a date of birth, or an age. Once paid plans start, card and other payment details are handled by the company that processes payments, and they do not reach us.

3. Why we use it, and on what basis

We do not ask for your consent to any of the processing below, and nothing in ERDism today relies on consent. Each purpose rests on one of the grounds that the Korean Personal Information Protection Act ("PIPA") allows without consent, named after it. Creating an account means accepting the Terms of service and confirming that you have read this policy — it is not a consent to this policy.

  • To provide the service you signed up for — necessary to perform our agreement with you (PIPA Article 15(1)4). Your account, sign-in details, two-step verification and passkeys, profile, what you create, connected databases, invitations, your inbox, the activity records that make the history and undo work, the agreement record, the live demo, and the emails the service depends on. Showing your name, avatar and, to members, your email address inside a workspace is part of this (section 4).
  • To keep the service safe and working — our legitimate interest in a secure, working service, kept to what that needs (PIPA Article 15(1)6). Limits on failed sign-in attempts and on emails, the server log and its sign-in lines, and the records of security changes such as turning on two-step verification.
  • To run and size the service — our legitimate interest in knowing how the service is used (PIPA Article 15(1)6). The per-project count of monthly users, the records of SQL checks, comparisons and database reads, the views of public links, and your account's country.
  • To answer you — necessary to act on your request (PIPA Article 15(1)4). Feedback you send and email you write to us, so that we can reply and fix what you report.
  • To improve the product — usage analytics (section 5), which tells us which features are used and where people get stuck. It is recorded only under a pseudonym, for statistics, which PIPA allows without consent for pseudonymised information (Article 28-2). The key that makes the pseudonyms is kept apart from the records, and you can turn it off at any time.
  • To improve ERDism from what is built in it — totals, and patterns or shapes in which every name has been replaced by a placeholder, derived as section 9 describes, including to train machine-learning models. This knowledge does not identify you; where a law still treats it as personal data, we rely on our legitimate interest in improving ERDism (PIPA Article 15(1)6) and keep it to what section 9 allows.
  • To meet legal obligations — where a law requires us to keep or disclose something (PIPA Article 15(1)2).

If you use ERDism from the European Union or the United Kingdom, the same purposes rest on the GDPR's matching grounds: performing a contract, legitimate interests, and legal obligations.

The emails we send are all about your account or your workspaces: confirming your address, resetting your password, invitations and invitation reminders, and notices that you were removed from a workspace, that a workspace you belong to was deleted, that you became a workspace's owner, that a workspace's editor seats are full, or that a connected database you look after changed or cannot be reached, and notices of planned maintenance, which go to every account. We send no marketing email.

4. What other people in your workspace can see

A workspace is shared. The members of a workspace can see each other's display name, avatar and role, and every member except a guest can see the other members' email addresses.

The list of invitations sent from a workspace shows the email address each invitation went to. Only the owner of the workspace can open that list, and only the owner can send invitations. So if you were invited by email, the address the invitation went to stays visible to the owner of that workspace, including after you join.

The owner of a workspace can open every project in it, whether or not they were added to it as a project member. Inside a project, every role except Viewer can read and change the schema, the SQL and the documentation; Viewer can read them. The history is part of the project, so anyone who can open the project can see which member made which change, by display name.

While you have a project open, everyone else who has the same project open sees that you are there: your display name and avatar, whether you can edit or only view, which diagram you are on, whether your ERDism tab is in front or has been in the background for a while, since when you have been there, and which tables you have selected. Your pointer, what you type and what you see on screen are not shared. This is kept only while you are there: within about two minutes after you close the project, you disappear from the list, and nothing about it is stored afterwards.

If a project has a connected database, everyone who can open the project can see the connection's host, port, database name and user name, and the differences found. Only an admin of the project or the owner of its workspace can add, change or delete a connection. When it changes or cannot be reached, the project's admins and managers, and the person who added it, are told. Nobody can see its password.

A project can also be shown outside the workspace through a public link. Anyone who has the link can see the project's last published version without signing in — section 9 ("What is public") lists exactly what it shows. Only an admin of the project or the owner of its workspace can turn the link on, and either of them can turn it off. The link stops working from the next request when it is turned off, when it expires, when the project goes to the trash, or when the owner of the workspace turns off public links for the whole workspace. The admins of the project and the owner of the workspace can see how many times the link was viewed in the last 30 days, but not by whom.

Your profile has an email visibility setting with the values private, workspace and public. It currently has no effect. The setting is stored and you can change it, but nothing in the service reads it — your address is shown to the people above whatever the setting says.

5. Cookies and browser storage

ERDism uses three cookies: two are needed to sign you in, and one remembers the language you chose. None of them is used for anything else, and none of them tracks you.

  • Staying signed in (erdism_rt) — holds the token that keeps you signed in, so that you do not have to sign in again each time you open ERDism. It is sent only to the one address that renews your sign-in, never with other requests or to other sites, and only over HTTPS. It lasts until that token expires (14 days) and is removed when you sign out.
  • Signing in with Google or GitHub (erdism_oauth_bind) — ties that sign-in to your browser so that nobody else can complete it. It is sent only to the sign-in addresses and expires after ten minutes.
  • Interface language (erdism_ui_locale) — remembers the language you chose, so that the documentation, the home page and the app open in it. It holds only en, ko or ja, nothing that identifies you. It is set when you choose a language in the app, on the home page or in the documentation's language menu, and it is sent only to ERDism, never to other sites, and only over HTTPS. It lasts one year from when you last chose a language, is removed when you choose System default in your profile, and is not removed when you sign out. It is needed only to show the pages in your language.

The two sign-in cookies cannot be read by scripts on the page. The language cookie can, because the app writes it.

Usage analytics, on our own server. To learn which features are used and where people get stuck, the app sends a short record of what you do to ERDism's own server — never to anyone else. It sets no cookie and stores nothing in your browser for this. Each record holds:

  • the kind of page you open, written as a pattern — for example /workspaces/:workspaceId/members, never the names or identifiers in the address;
  • which listed buttons you press (for example the editor toolbar's Publish), and which features you use (for example "a table was created" or "SQL was imported");
  • when you sign up or sign in, whether you did it with a password or with Google or GitHub (not which of the two);
  • how long an editing session lasts and how many edits it had;
  • the time our server received it.

It never holds your diagrams, SQL, table, column, project or workspace names, your email address, your IP address or your browser details. Your account and workspace are stored only as pseudonyms — codes computed with a secret key kept outside the database, so the records alone do not say who you are. Individual records are deleted after 90 days; daily totals, which say nothing about any one person, are kept.

Before you sign in — on the home page, the live demo and the sign-in pages — only a page count is sent: which page was opened, with no identifier at all, added to a daily total.

To turn it off, go to Account › Account › Usage analytics and choose Turn off. The app stops sending, our server stops accepting usage analytics records for your account, and the records already collected for your account are deleted. If your browser sends Global Privacy Control or Do Not Track, nothing is sent at all, signed in or not. Nothing is sent either while an account is waiting for its email address to be confirmed.

Turning usage analytics off does not stop the records that are part of running the service, which section 2 lists: the activity records and history, the once-a-day record that you opened a project, and the record of each SQL check, comparison and database read. Those are not usage analytics and have their own basis (section 3).

Google Analytics is not used. It is turned off for the public beta: no Google Analytics script is loaded on any page, no Google Analytics cookie is set, and nothing is sent to Google. If we ever decide to use it, we will change this policy first, tell you as section 13 describes, and load it only for people who choose to allow it.

There is no advertising, and no other third-party script, font or stylesheet on any page.

The site keeps the following in your browser. None of it is sent anywhere unless the line says so.

In local storage:

  • Sign-in hint (erdism.session) — the identifiers of your account and when your sign-in expires, so that the app knows whether to ask the server to renew it. It holds no token. Removed when you sign out.
  • Unsaved editor work (keys beginning erdism:draft:) — one entry per project and editing area, holding work you have not saved yet. Discarded seven days after it was written, when you save or discard it, or when you sign out.
  • Interface language (erdism.uiLocale) — the language you chose (when you are signed in, a copy of the language in your profile). The language cookie above holds the same value.
  • Recently opened diagrams (erdism:recent-diagrams) — up to 24, with their names.
  • Live demo (erdism:demo:session) — the identifier of the demo session you opened, if any.
  • Preferences — how the home screen is sorted, which editor panels you collapsed, how table cards and relationship lines are drawn, group layout, the issues panel's filters, and which service notice you dismissed.
  • Diagnostic switches — flags that turn on performance or rendering diagnostics. You set them yourself in the browser console.

In session storage, which the browser clears when you close the tab: the workspace and project tabs you have open (erdism:workspace-tabs), which service notice you closed (erdism:system-notice:dismissed), where to bring you back after you confirm who you are with Google or GitHub (erdism.reauth-return), and a marker that stops the page reloading itself more than once after an update (erdism:stale-chunk-reload).

In IndexedDB (erdism-drafts): the draft of a new project — the form and any SQL you added to it — while you are creating one. It is discarded seven days after it was saved, when the project is created or the draft cleared, or when you sign out.

Signing out removes the sign-in hint and your unsaved drafts. If your sign-in simply expires, the drafts are kept so that you can carry on after signing in again. Signing out does not remove recent diagrams or preferences, so on a shared computer clear the site's data in your browser when you are done.

6. Who else handles your data

We use these service providers to run ERDism:

  • Amazon Web Services, in the Seoul region (ap-northeast-2), runs the server that hosts the application, its database and its cache, sends our emails (Amazon SES), and passes us alerts about the service and reports of emails that could not be delivered (Amazon SNS).
  • Cloudflare provides our domain name service and carries traffic between your browser and our server, encrypting it on the way.
  • Google Workspace holds our mailboxes: it receives the email you send to our addresses and the feedback you send from inside ERDism.
  • Google and GitHub, only if you choose to sign in with them. We ask Google for your identifier, email address and basic profile, and GitHub for your email addresses. We keep the identifier and the email address and discard everything else.

If your avatar is set to an image address, that address is stored with your profile. The security settings of erdism.com stop browsers from loading images from other sites, so no other site receives a request because of it.

We do not use Google Analytics (section 5), and our own usage analytics is not shared with anyone. There is no advertising network and no third-party error reporting service.

7. Where your data is stored

Your account, your content and the service's records are stored in Seoul, in the Republic of Korea, on Amazon Web Services' Seoul region (Amazon Web Services Korea LLC). Copies of the database are kept there too, and our emails are sent from there.

Some personal data leaves Korea, to the companies below. We do this because it is needed to provide the service under our agreement with you, and we disclose it here as PIPA Article 28-8(1)3 requires; we do not ask for a separate consent. In each case the data travels over the internet, encrypted, at the moment you use the part of the service concerned.

Cloudflare, Inc. (United States, and Cloudflare's network worldwide)

  • What: everything your browser exchanges with erdism.com, including your IP address, while it is on its way.
  • Why: to answer for our domain name, and to carry and encrypt the traffic between your browser and our server.
  • When and how: every time your browser contacts erdism.com, over an encrypted connection.
  • How long: Cloudflare handles it while carrying it. Any records Cloudflare keeps of requests follow its own policy.
  • Contact: [email protected].
  • If you do not want this: ERDism cannot be reached without it.

Google LLC — Google Workspace (United States)

  • What: email you send to our addresses, the feedback you send from inside ERDism (as listed in section 2), and the reports of emails we could not deliver, which hold the address they were sent to.
  • Why: to receive and keep our email so that we can answer you and keep our emails working.
  • When and how: when you write to us, send feedback, or an email to you cannot be delivered, by encrypted email.
  • How long: three years from when we receive it, and then deleted.
  • Contact: Google's privacy contact form, support.google.com/policies.
  • If you do not want this: do not email us or send feedback. Everything else in ERDism works without it.

Google LLC and GitHub, Inc. — signing in (United States)

  • What: only if you choose Continue with Google or Continue with GitHub: the fact that you are signing in to ERDism. Your browser goes to that company's sign-in page, and it sends us back what section 2 lists.
  • Why: to let you sign in with that account.
  • When and how: each time you choose that button, over an encrypted connection.
  • How long: under that company's own policy, as for any sign-in with your account there.
  • Contact: Google — the form above; GitHub — [email protected].
  • If you do not want this: sign up and sign in with an email address and a password instead.

8. How long we keep it

  • Sign-in tokens. An access token is valid for up to 24 hours, and a refresh token for 14 days. Both stop working at once when you sign out, change or reset your password, change two-step verification or passkeys, or close your account.
  • Confirmation and reset links. A confirmation link lasts 24 hours, a password-reset link one hour.
  • An account whose email address is never confirmed. Deleted seven days after it was created.
  • Rate-limit counters. One hour; the counter of emails sent to one address, one day.
  • Workspace invitations. An invitation can be accepted for seven days. Thirty days after it is declined, withdrawn or expires, the address it was sent to is shortened as section 2 describes.
  • Monthly usage counts. Thirteen months.
  • Drafts in your browser. Seven days, as described in section 5.
  • Usage analytics. Individual records 90 days. Daily totals, which say nothing about any one person, are kept. Turning usage analytics off deletes your records at once.
  • Trash. A deleted project or workspace is permanently deleted seven days after it was put in the trash, as described in section 7 of the Terms of service.
  • Connected databases. Kept until the connection is deleted. Deleting it — or permanently deleting its project or workspace — deletes, at once and together, the connection, its encrypted password and the key that protected it, every schema read from it, and its notices. While a connection exists, a read older than 90 days in which nothing had changed is deleted, except the latest successful one; a read that found a change is kept.
  • Views of a public link. Thirteen months.
  • A closed account. For thirty days you can reopen it. After that it is erased: the account and everything it alone owned are deleted, and where the shared history of a workspace still points to it, it is kept only as "Deleted user", without its email address, name or profile.
  • Activity records. These belong to the workspace, not to the person, so they stay when a member leaves, is removed, or closes their account, and the history keeps showing who made each change. They are kept for as long as the workspace exists, and deleted with it.
  • Feedback and email you send us. Three years from when we receive it.
  • Who is viewing a project. Only while you are there, as described in section 4.
  • Backups. Copies of the database are kept for seven days. A copy taken just before each update of the service is kept for seven days and then deleted.
  • Server logs. Ninety days.
  • Your agreement to automatic renewal. Once paid plans start, when you agree to a paid plan's renewal terms we record when you agreed, which wording you agreed to, and the IP address the agreement came from. We keep this for three years, or for one year after the plan ends, whichever is longer.

How we delete it. When a period above ends, or when you or we delete something, it is removed in the same way every time:

  • In the database, the rows that hold it are deleted. This is done by the service itself: the trash is emptied every hour, old records are removed by scheduled jobs, and some things — a connected database, or your usage analytics records when you turn them off — are removed as soon as you do so.
  • A connected database's password is destroyed by deleting the key it was encrypted with, so that no copy of it can be decrypted again.
  • Backups are not edited. Each daily copy is replaced by a newer one, so whatever was deleted is gone from those copies seven days later. A copy taken just before an update is kept for seven days and then deleted as a whole.
  • A closed account is erased by a scheduled job thirty days after it was closed, and an account whose address was never confirmed seven days after it was created (section 8). If you ask us to erase your account sooner, we do it on request.
  • Server logs are deleted when they are ninety days old. Email in our mailbox is deleted when it is three years old.
  • Shortening an address (section 2) replaces it in the database; the full address cannot be recovered from what is left.

We do not keep personal data on paper.

9. What we keep, and what we don't

What ERDism holds falls into three layers, and each has its own rule. We do not sell anything in any of them.

Your content — yours, and deleted when you delete it

  • What it is. Your schemas, diagrams, tables, SQL and documentation, the history of every change to them, and — if you connect a database — the schema we read from it. In a workspace it belongs to the workspace, as section 7 of the Terms of service says.
  • How we use it. To run the service for you and for the people you share it with, as section 6 of the Terms of service says. We never train models on it as it is; what we may learn from it is set out in the next part.
  • When you delete a project or a workspace. It goes to the trash and is permanently deleted seven days later, together with its history and anything read from a connected database. A backup copy can remain for up to seven more days (section 8). What stays is our own record that it was deleted and when, without its name or any of its content, and — for a workspace — the notice its members received when it was deleted, which names it.
  • When you delete a connected database. The connection, its password and every schema read from it are deleted at once (section 8). The activity record that it existed — its name, host, port, database name and user name — stays with the workspace's other records.
  • When you leave a workspace. What you created there stays with the workspace, and the history keeps showing you as the person who made each change.
  • When you close your account. The account and everything you own are hidden at once, and for thirty days you can reopen the account and get them back. A workspace that has other members has to be handed to one of them or deleted first, so it is never closed with you. After thirty days the account is erased as section 8 describes. If you want it erased sooner, ask us (section 10).

What we learn — patterns and totals, never your content as written

  • Today. We do not yet build anything from your content beyond what the service needs to run for you, and the record of each published SQL file described below under "Checking an exported SQL file". What we keep about use is the usage analytics in section 5 and the monthly usage counts in section 8, which record that something was used, not what you wrote. The rules ERDism uses to recognise two ways of writing the same column definition come from public database documentation and from database servers we run ourselves, not from anyone's schema.
  • What we may build. We plan to learn four kinds of things from what is built in ERDism. None of them exists yet. When we build each one, it will follow the rules on this page.
  • Common naming and type patterns — which names and column types tend to go together, to suggest names and types and to improve ERDism's checks. Only a pattern seen in at least a minimum number of separate workspaces is kept. A pattern seen in fewer is never recorded at all, not even for a time.
  • How issues are usually fixed — the shape of an issue ERDism found and of the change that fixed it, with every table, column and other name replaced by a placeholder. These shapes may be used to improve ERDism's checks and to train machine-learning models.
  • How schemas change — totals only, such as how often a kind of change is made or how often it leads to a problem.
  • How database engines behave — for databases people connect: totals only, such as how many connected servers run a given version or setting, or how often a given kind of statement is rejected.
  • The rules for all four. What we keep never contains your content as written, any name you chose, an email address, or anything else that identifies a person, a workspace or a project. We never train models on your schemas, SQL or documentation themselves. Because what we keep cannot be traced back to you, it stays after your content is deleted and after you close your account. We do not use it for advertising and we do not sell it.
  • Checking an exported SQL file. Each time a project is published, ERDism checks the published SQL and keeps a record of the result, so that a copy of the file can later be confirmed as coming from ERDism. The record holds only a fingerprint of the SQL (a one-way hash), its SQL dialect and version, when it was checked, how many tables and open issues it had, and what kind of thing was checked — never the SQL itself, and no workspace, project or account. Anyone who has the fingerprint can look these records up without signing in. The record stays after the project is deleted, so that a copy of the file can still be checked.
  • Anything else. If we ever want to learn something from what people create in ERDism that is not listed here, we will change this policy first and tell you as section 13 describes.

What is public — only what you choose

  • Nothing is public unless someone turns it on. An admin of a project, or the owner of its workspace, can turn on a public link for the project. Anyone with the link can see the project's last published version — its tables, columns, indexes and relationships with their comments and SQL, and how its diagrams are laid out. They cannot see unpublished or pending changes, the documentation pages, the history, or who is a member.
  • A public link can be ended. It can be given an expiry date and turned off at any time, and it turns off when the project goes to the trash. The owner of a workspace can turn off every public link in it at once.
  • There are no public profiles. Nothing about you as a person is published.

10. Your rights

You can ask us to:

  • tell you what personal data we hold about you and give you a copy;
  • correct it if it is wrong;
  • erase it;
  • give it to you in a form you can take elsewhere;
  • stop or limit using it, or object to how we use it.

Some of this you can do yourself: you can change your profile and password from your account page, export any project as SQL, and close your account. For the rest, write to [email protected] from the address you sign in with. Asking is no harder than signing up, and it costs nothing. People who never signed up — for example someone a workspace invited by email — can ask in the same way.

We answer within 10 days of receiving your request. If we cannot do what you asked, or need more time for a reason the law allows, we tell you within those 10 days why, and how you can object to that decision: by replying to our answer, and we review it again.

If you are not satisfied with our answer, you can complain to a data protection authority. In Korea you can contact the Personal Information Protection Commission, the Personal Information Dispute Mediation Committee (www.kopico.go.kr, 1833-6972) or the Personal Information Infringement Report Center run by KISA (privacy.kisa.or.kr, 118); elsewhere it is the authority where you live.

11. Security

Traffic between your browser and ERDism is encrypted with HTTPS. Passwords are stored as bcrypt hashes and never in a readable form; the database refuses a value that is not a bcrypt hash. Sign-in uses a short-lived token sent with each request and kept only in the page's memory; the longer-lived token that renews it is in a cookie that scripts cannot read (section 5). Failed sign-in attempts are limited, and the endpoints that cause an email to be sent are rate limited. Access to a workspace and to a project is checked against your role on every request. Email addresses, IP addresses and request bodies are kept out of the server logs.

The password of a connected database is encrypted with a key made for that connection alone, and that key is itself encrypted with a key kept outside the database. The password is decrypted only to connect to your database, and it is never sent back to anyone or written to a log. The connection only reads the schema. A public link is a long random code, and it is the only thing that opens the link.

If your personal data leaks. If we learn that personal data about you has leaked, or may have leaked, we will tell you within 72 hours of learning it — by email, or, if we cannot reach you, on our website for at least 30 days. We will tell you what data was involved, when and how it happened, what you can do to limit any harm, what we have done about it and how you can seek redress, and whom to contact. Where the law requires it — for example when at least a thousand people are affected or someone broke in — we also report it to the Personal Information Protection Commission or KISA within the same 72 hours.

If the service is attacked. If someone attacks the service (an intrusion, a denial-of-service attack or malicious code), we report it to the Ministry of Science and ICT or KISA within 24 hours of learning it. If such an attack interrupts the service for two hours or more, or may have exposed or altered your data, we will tell you without delay.

12. Children

ERDism is not for anyone under 16, and you must be at least 16 to open an account — the sign-up screen says so. We do not ask for a date of birth. If we learn that an account belongs to someone under 16, we close it and erase it.

13. Changes to this policy

When we make an important change to this policy, we will tell you at least 30 days before it takes effect, by email and inside the service. The date at the top of this page shows when it was last changed.

14. Contact

Questions about this policy or your data: [email protected].