Privacy

A post stores the text typed into the box, the show, cast or find-my-drama page it was left on, and the name it was posted under. A post left on a show page can carry a star rating, stored as a rating as well. Replies store the same things.

The text of a post is sent to an AI service to be screened before it appears. The request goes through OpenRouter to the model provider with data retention and training disallowed.

A name is stored once per browser, alongside a four-character tag worked out from the identifier in the site’s cookie. That tag is not chosen and cannot be changed: it is what separates two people posting under the same name. Changing the name changes it on every past post; clearing site data loses the name.

Redeeming an invite code stores the code on that name record, which lifts the posting limits a new browser starts with. The code carries no name and no email address.

Reporting a post stores which post was reported and which browser reported it. A report is never published, and the person who wrote the post is not told of it. Liking a post stores which post was liked and which browser liked it; only the count is shown.

A star rating stores the score and the show it was left on. It carries no name and no account.

Site search stores the query typed into the search box and the number of results it returned. Search text is never published.

Each of those writes also stores an IP address and the random identifier held in the site’s cookie. Neither appears anywhere on the site: the tag beside a name is worked out from the identifier, and the identifier itself is not shown.

The site runs analytics on a separate service kept for it, on its own host rather than through an advertising or data-broker network. A page view records the path opened, the referring page, screen size, browser language, browser and operating system, and a country, region and city worked out from the IP address.

The address itself is not kept there. The analytics service reads it to work out the location, then stores the location and drops the address: its records carry no IP column at all. This is the one place on the site where an address is read and not retained in any form.

Tapping a link out to a platform records one more event, naming that platform and the show page the tap came from.

That stream lives with the analytics service, not in the site’s database. It sets no cookie.

Posts are stored so they can be published on the page they were left on. Ratings are stored so the average on a show page can be shown: that average is the sum of what visitors left. Search queries are stored to find what the catalog is missing. Page views are counted to see which pages get read.

The IP address and the device identifier exist for abuse prevention. Without them one person can submit ratings on a single show until the average is theirs alone, and one person can fill a page with posts.

The basis in law is legitimate interests: publishing the posts and ratings people leave, and keeping what is on file from being manipulated. No consent banner appears because nothing here follows a visitor onto another site.

An IP address is stored in two forms. The durable form is a one-way hash: that is what the spam and vote-stuffing checks read, and the address cannot be worked back out of it. The address itself is stored in a separate column, and the target for clearing that column is 30 days.

Clearing it is triggered by activity on the site, not by a clock. A sweep runs on a sample of submissions. It empties the raw column and leaves the hash in place. Because it rides on traffic, an address can sit past the 30 days through a quiet stretch, and gets cleared once submissions resume.

A submission that is turned away still leaves a record. That record holds the address hash and the device identifier, with the reason for the refusal beside them. The rate limits count those rows, so they are kept rather than cleared. An address hash that has been blocked stays on the block list.

A post can also be held rather than refused. A held post is stored with its text and the name it was posted under, and does not appear on the page. A post that readers report stays hidden until it is reviewed; nothing puts it back on its own.

One record has a stated limit: the raw IP address described above. Everything else is kept for as long as the site runs. That covers post text, handles, rating values, search query text, device identifiers, address hashes, the record of each submission, and the page-view stream.

Any of it can be deleted on request.

One cookie is set, and it is first-party. It holds a random identifier generated for the browser, and nothing else: no name, no email address, nothing typed elsewhere. It expires one year after it is set.

No third party sets a cookie here, and no advertising network is involved. Clearing site data in the browser removes it, and a later visit is issued a fresh identifier.

Two more records stay in the browser and never reach the site: the saved list on My shows, and the light or dark choice. The browser keeps both, and clearing site data removes them.

Short Drama Guide is run by Black Ember Labs, the data controller for everything described here. Everything below goes to [email protected].

Three requests are answered at that address: a copy of what is stored against a device, deletion of it, and an objection to it being stored at all. Naming the show page a rating was left on, or the name and tag a post carries, is what makes such a request actionable.

A complaint about any of this can go to a data protection regulator. In the United Kingdom that is the Information Commissioner’s Office. In the Netherlands it is the Autoriteit Persoonsgegevens.

None of this is sold. Nothing goes to an advertising network or a data broker, and nothing is handed to another company for its own use. The submission records sit in this site’s own database at its hosting provider, and the page-view stream sits with the analytics service named above.

Copyright and takedown terms are on the terms page.