Synth Antispam

Privacy Policy — Synth Antispam for WordPress

Last updated: 15 September 2026

Scope: the WordPress service only. This document covers the Synth Antispam plugin for WordPress and the classification service it talks to. It does not replace or cancel the general Synth service documents, which continue to govern the Telegram service: general Privacy Policy and general Terms of Use.

Companion document: Terms of Use — Synth Antispam for WordPress.

Who we are

LightApps OÜ, registry code 16712872, Vesivärava tn 50-201, Kesklinna linnaosa, Tallinn 10152, Estonia — trading as Synth Antispam.

For anything about data processing, write to support@synth.locker.

Our role: you are the controller, we are the processor

Synth Antispam is a comment classification service. When you install the plugin on your WordPress site, you remain the data controller for your commenters' data, and Synth acts as a processor — on your instruction, and only to the extent you set by installing the plugin and entering a site key. We do not decide the purposes of processing on your behalf.

One purpose is ours, not yours, and you should know it before you install. Besides returning a verdict on your instruction, we keep a copy of the comment data your site sends and use it to train and improve the Synth spam-classification models. For that purpose we act as a controller in our own right rather than as your processor. It applies to every site using the service, there is no setting that turns it off, and the copies are kept indefinitely. What is kept, and how to have it deleted, is set out under How long we keep it and Training our own model below.

The legal basis for sending the data is yours to choose as the controller. This document does not set it for you.

What we receive from your site

Exactly and only the following. This list is generated from a manifest in the plugin's own code rather than maintained by hand, so what you read here and what the plugin actually sends cannot drift apart.

Field	What it is and why it is sent
Request format and routing
`schema_version`	The version of the request format, so the service stays compatible with older and newer plugin versions at the same time.
`plugin_version`	The installed plugin version, for the same compatibility reason.
`surface`	A fixed label identifying that the request comes from the comment form, so future integrations can be told apart.
`object_type`	Whether the submission is a comment, a pingback or a trackback — the last two are machine-submitted and weighed differently.
The submission itself
`content.body`	The comment text as submitted, before WordPress applies its own HTML filtering, so a link that filtering would strip is still visible to the classifier.
`content.author_name`	The display name the commenter typed into the comment form.
`content.author_url`	The website URL the commenter typed into the comment form. On the traffic this plugin was built against this field carries a large share of the spam signal, most of which is not visible in the comment text at all.
`content.author_email_domain`	Only the domain part of the commenter’s email address, used to recognise disposable or throwaway address patterns. The address itself is never sent.
`content.author_id_hash`	A one-way hash of the commenter’s email address combined with a secret value belonging to this site alone. It lets the service recognise that two comments on this site came from the same address without ever receiving that address. Because the secret never leaves this site, the same commenter cannot be correlated across two sites — that is impossible by construction, not merely switched off.
Context, without identifying the commenter
`context.author_status`	Either “registered” (a logged-in user of this site) or “anonymous” (everyone else). Only these two values are ever sent: a commenter who already has an approved comment here is recognised as trusted and skipped before any request is built.
`context.is_reply`	Whether the comment is a reply to another comment.
`context.site_locale`	This site’s configured language, used as a hint for language-specific handling.
`context.client_ip_status`	Either “absent” or “direct” — whether the request carried an IP address at all. The address itself is never sent, in either case, and the plugin never tries to reconstruct a visitor address from proxy or CDN forwarding headers.
`context.has_user_agent`	Whether the browser sent a User-Agent string at all. The string itself is never sent.

Separately, and not about any commenter: each request carries your site key, the plugin version and your site's domain. That is how the service knows which site is talking to it.

What never leaves your site

Each of the following is enforced by the plugin's code, not promised by this document:

The full email address. Only the part after the @ is sent, and the pseudonym is a one-way hash — never the original value. The salt belongs to your site alone, so the same commenter cannot be matched between two sites: that is impossible by construction, not disabled by a setting. Deleting the plugin destroys the salt, after which not even your own site can link a previously sent hash back to an address.
The IP address. Only "absent" or "direct" is sent, and nothing more. The plugin does not try to reconstruct a visitor's real address from proxy or CDN forwarding headers.
The User-Agent string. Only whether one was present.
The title or body of the post the comment was left on; cookies; the referring page; and any form field other than those listed above.

How long we keep it

There are two separate stores, kept for two different lengths of time. Reading only the first would leave you with the wrong answer.

The verdict record. The verdict for each comment is stored for 24 hours and then expires automatically. Your site does not control that expiry — it happens on our side. This is the record your site collects its verdict from.

The training record. Separately, we keep our own copy of each request your site sends — the comment text and the author and context fields listed above, exactly as they were sent — together with the verdict our classifier produced and any later correction a moderator of your site makes to it. These copies are kept indefinitely. They have no expiry date, and no scheduled deletion runs against them.

They are stored as sent. They are not anonymised: the comment text, the display name and the website URL are kept in the form your site sent them. They are not aggregated and not reduced to statistics. The fields listed under What never leaves your site are not in them either, for the same reason as everywhere else on this page — we never receive those fields, so we cannot store them.

Training our models

We use the training records described above to operate and improve the Synth service: training and evaluating the spam-classification models that run it, and nothing beyond that. Synth is one platform serving several surfaces — WordPress today, further integrations over time — and the records from all of them are used together: a comment that teaches a model what spam looks like improves detection everywhere, not only on the site it came from. This is the one purpose for which we use your site's data on our own account rather than on your instruction, and we say so plainly here rather than leaving it to be inferred from the field list above.

What this means in practice:

Scope: every site. There is no opt-in, no opt-out and no setting on the plugin's screens that excludes a site. If this is not acceptable for your site, the choice available to you is not to install the plugin.
Moderator corrections are kept too. When you press Not spam or Spam on a comment, that correction is stored against the same record. It is the most useful signal we receive, which is why we ask for it and why we disclose that we keep it.
Not sold, not shared for advertising, not published. They are used to train our model and for nothing else. The sub-processing described in the next section is unchanged by this: it is the same set of fields, sent to produce a verdict.

Having them deleted. Write to support@synth.locker from the address associated with your site, naming the site. We delete the stored copies by site key, so one request covers every copy taken from your site rather than one comment at a time. We are building an operator tool for this deletion alongside the release that starts the collection; until it is in place the deletion is carried out by hand on request, and the address above is the route in either case.

Further processing

To produce a verdict, the service passes comment content to an external language-model provider acting as a sub-processor. Part of the list above reaches it: object_type, the comment text (in normalised form), the display name, the website URL, the email domain, context.author_status and the site language. What does not reach it: the per-site pseudonym, the reply flag, and the two presence flags for IP address and User-Agent. Those stay inside our own perimeter.

Payments. If you buy a paid allowance, the plugin sends you to the payment page of Stripe, which acts as a separate controller for the payment itself. Card details never reach your site, the plugin or this service: they are entered on Stripe's own page. We receive from Stripe only what is needed to attach the purchased allowance to your site key — the fact of a completed payment, its plan and its renewal date. No comment data is sent to Stripe, and buying is never required to use the plugin. Stripe's own terms and privacy policy govern that processing.

This section is the single maintained place where sub-processing is described. The current sub-processor list is available from support@synth.locker on request, and any change to it is published here, on this page, before it takes effect. Other Synth surface documents point to this section rather than keeping their own copy of the list.

Where your data is processed, and transfers outside the EEA

Our own processing happens in the European Union: the service runs in Amazon Web Services' eu-west-1 region (Ireland), and that is where site records and verdicts are stored.

The one exception is the sub-processing step described above. The language-model provider is established in the United States, so producing a verdict involves a transfer of the listed fields outside the European Economic Area. That transfer takes place under the European Commission's Standard Contractual Clauses, incorporated into our data processing agreement with that provider. The fields excluded from sub-processing — the per-site pseudonym, the reply flag and the two presence flags — are never transferred, because they never leave our own EU perimeter at all.

No transfer of any kind happens before you enter a site key: an installation with no key sends no request.

How we protect it

The measures below are properties of how the service is built, not aspirations:

In transit. Every request between your site and the service travels over HTTPS. The plugin refuses to be configured with a non-HTTPS address, so an unencrypted request cannot be sent even by misconfiguration.
Your site key is never stored in readable form. We keep only a SHA-256 hash of it, combined with a secret value held separately from the database. A copy of our database would not yield a working key for any site.
Automatic expiry rather than manual cleanup — for the verdict record. Verdicts are removed by a storage-level expiry after 24 hours; that deletion does not depend on a job someone has to remember to run. It does not extend to the training records, which have no expiry at all — see How long we keep it. The storage holding them is private, encrypted at rest, and closed to public access.
Separation from our other services. The WordPress service runs as its own functions with their own access roles, its own queues and its own provider credentials, separate from our other services. A fault or a traffic spike on one does not reach the other.
Least data by construction. The strongest protection for the email address, the IP address and the User-Agent string is that they are never sent — see above. Data we do not hold cannot be exposed by us.

Your rights as controller, and your commenters' rights

Data subject requests are addressed to you as the controller, and we are obliged to help you answer them. The plugin implements WordPress's standard personal-data export and erasure tools for the classification records it stores locally on your site.

On our side, the verdict record is removed by the 24-hour expiry described above. The training record is not: it has no expiry, so it is removed only when we delete it. Write to support@synth.locker, naming your site, and we delete every training copy taken from it. Deletion is by site key and therefore covers the whole site at once; we cannot currently delete the record of one individual comment while keeping the rest, and we say so rather than implying a granularity we do not have.

What we do not do

We do not sell your site's data, share it for advertising, or publish it.
We do not pass data to anyone other than the sub-processor named above.
We do not combine your site's data with any other site's data: cross-site matching of a commenter is impossible by construction, for the reason given above.

Changes to this document

When our processing changes, this page changes with it — not on an annual schedule. The date at the top is the date of the last substantive change. Changes to the sub-processor list are published here before they take effect.