Privacy Policy

Last updated 29 June 2026. feederism.org is run by an independent individual who is finalising some formal legal details — legal-entity registration, a service address, and the choice of governing law — with professional counsel. For any privacy, data-protection, or legal question, email [email protected].

Effective date: 29 June 2026 Version: 1.0 Last updated: 29 June 2026

1. Summary — please read this first

This Privacy Policy explains how we collect, use, share, and protect personal data across the whole of feederism.org — including:

the blog (in-depth articles on the psychology, relationships, health, and self-acceptance side of feederism);
free membership (passwordless accounts you can create to save things and to use the forum);
the quizzes and tools ("What Kind of Feeder or Feedee Are You?", the "Couples Alignment Quiz", and the hub at /quizzes/);
the community forum at https://feederism.org/forum/;
our website analytics; and
the emails we send you.

A few things matter so much that we put them up top:

This site is for adults aged 18 or over only. It is not directed at, and may not be used by, anyone under 18. See Section 4.
feederism.org is a website about feederism — a feeding and weight-gain interest. Because of this, creating an account, taking a quiz, posting in the forum, or in some cases simply connecting to the site can reveal information about your sex life and/or sexual orientation. Under EU and UK data-protection law this is "special category" personal data that receives heightened protection. We explain this in Section 3, and we explain — purpose by purpose — exactly which legal condition we rely on for it in Section 6. We do not rely on a single condition for everything: we use your explicit consent for the things you actively choose to do (membership, quizzes, posting), the "manifestly made public" condition for what you publish in the forum, and the "substantial public interest" condition for the safety and moderation records we must keep even if you later object. This is set out in full in Sections 3 and 6.
The community forum is public and searchable. Your forum username and the text you post may be readable by other members and by anyone on the internet, including search engines. Please read Section 7 carefully before you post.
We deliberately collect very little, but the little we collect can be sensitive. Even an IP address combined with the fact that you connected to this site can, by inference, reveal something about you. We are honest about that throughout this document (see Sections 3, 5, 8, and 10) rather than understating it. We use no advertising cookies, no third-party trackers, no cross-site tracking, and no ad networks, and we never sell your personal data. Our analytics are cookieless.
You don't need a password. Membership uses passwordless "magic-link" sign-in by email — we do not store a password for you. (This removes one category of risk; it does not make the account risk-free — see Section 12.)
You are in control of your data. You can access, correct, export, or delete your data, object to certain processing, and withdraw your consent where our processing is based on consent. See Section 13. To exercise any right, email [email protected].

We are committed to handling your data lawfully, transparently, and with the special care this subject matter deserves.

2. Who we are (the data controller)

The "data controller" is the person or organisation that decides why and how your personal data is processed. For feederism.org, that is the independent individual who operates and publishes the site under the pseudonym "Clair."

Controller: the individual operating feederism.org under the pseudonym "Clair." A formal legal entity and registration are being finalised with professional counsel; until that is complete, all data-protection matters are handled directly and personally by the operator.
Trading name / service: feederism.org
Place of establishment: being finalised with professional counsel. (Our servers and database are hosted in Finland (EU); as explained in Section 2.1, hosting location is not the same as the controller's place of establishment.)
Service / postal address: available on request by emailing [email protected] (a formal service address is being finalised).
Contact for all privacy matters: [email protected]

About the name "Clair." The site is published under the name "Clair", a pseudonym used to keep the operator anonymous from the general public. The pseudonym is a public-facing byline; behind it stands a real, accountable individual who is legally responsible for your data and reachable for all privacy matters at [email protected]. We are formalising the legal-entity registration and a service/agent address with professional counsel so that legal accountability and the operator's anonymity from the general public are reconciled properly rather than left to a name and an email alone.

2.1 Which law applies, and where we are established

Our servers and database are hosted in Finland (EU). Hosting location is not the same as the controller's place of establishment — the law looks to where the controller is established, not merely where the servers sit. The controller's place of establishment is being confirmed with professional counsel and, once confirmed, will determine the matters that depend on it (representatives in Section 2.2; lead/competent supervisory authority and the one-stop-shop position in Section 17; and the governing-law clause).

Regardless of where the controller is established:

The EU GDPR applies because we offer the site to people in the EU and process their data (Article 3, including Article 3(2) where the controller is outside the EU).
The UK GDPR applies because we offer the site to people in the UK and process their data.

This Policy is therefore written to comply with both the EU GDPR and the UK GDPR.

2.2 EU and UK representatives (Article 27)

A controller established outside the EU that offers services to people in the EU must usually appoint an EU representative (Article 27 EU GDPR); the same applies for the UK (a UK representative) if the controller is outside the UK. The exemption in Article 27(2) does not apply to us, because our processing of special-category data is ongoing (not occasional) and is central to the service — so we cannot rely on the exemption.

A representative will be appointed where legally required, consistent with the place of establishment being confirmed under Section 2.1. In the meantime, contact [email protected].

2.3 Data Protection Officer (DPO)

A DPO is mandatory where the controller's core activities consist of processing special-category data on a large scale (Article 37(1)(c)). The core activity of feederism.org is the processing of special-category data (a sexual-interest community), which weighs toward appointment even at a modest user base; the principal open question is "large scale." Taking the cautious view appropriate to a dedicated Article 9 service, we appoint a privacy lead now and treat the DPO question as live rather than settled. Clair acts as the privacy point of contact at [email protected], and we re-assess the statutory DPO requirement in our DPIA (Section 15) and at defined growth thresholds.

3. The sensitive nature of this site (special-category data) — and how we lawfully handle it

This section is important. Please read it carefully.

EU and UK data-protection law gives extra protection to certain types of data, called "special category" data (Article 9 GDPR). These include data revealing a person's sex life and sexual orientation.

Because the entire feederism.org website is about feederism, data we hold can reveal special-category information about you even when, on its face, it looks ordinary. This is sometimes called sensitive data "by inference": courts and regulators have confirmed that data which is liable indirectly to reveal sensitive information — through comparison or deduction — is itself special-category data (Court of Justice of the EU, Case C-184/20, OT, 1 August 2022). In practice, for this site:

Connecting to the site at all (so that your IP address is associated, in a log, with a request to this domain) can suggest an interest in the subject;
Taking a quiz can reveal your preferences (even though, as Section 5.3 explains, your answers are processed in your browser and are not stored on our servers);
Creating an account links your email address to this site and therefore to the subject;
Posting in the forum discloses, in your own words, information about your interests, identity, relationships, or experiences.

We take that inference seriously, and we apply it consistently. Because by-inference sensitivity attaches to all of our processing — including server logs and analytics — we do not try to run any processing stream on an ordinary Article 6 basis alone. Every processing activity in this Policy has a valid Article 9 condition recorded against it in Section 6. Crucially, we do not use a single Article 9 condition for everything, because a single condition (consent) does not fit every situation. Instead we match the condition to the activity:

Explicit consent — Article 9(2)(a). For things you actively and knowingly choose to do where consent can be genuinely free and recorded: creating a membership account, using the quizzes, subscribing to the newsletter, and the act of choosing to post in the forum. Here you make a deliberate, specific, recorded choice, and you can withdraw it.
Data manifestly made public by you — Article 9(2)(e). For the continued storage and display of forum content you have chosen to publish to a public forum. We rely on this in addition to your consent so that your published posts have a sound basis even where consent might be questioned (see the hedge in Section 7).
Substantial public interest — Article 9(2)(g) (read with the relevant condition in UK/EU implementing law on safeguarding and unlawful-acts/safety processing): for moderation, safety, and abuse-prevention records that we must keep even if you object or withdraw consent — for example, to prevent ban evasion or to protect other users. Consent is not the right basis for records that have to survive a user's wishes, so we do not pretend it is.
Establishment, exercise, or defence of legal claims — Article 9(2)(f): available as a further condition where moderation or security records are needed in connection with a legal claim.

For our cookieless analytics, server logs, and core security processing, we do not rely on Article 9(2)(a) consent (which we could not validly obtain from an anonymous visitor — see Section 6 and Section 8). We rely on Article 9(2)(g) substantial public interest, framed around operating and protecting a lawful adult-content service and keeping it secure, supported by our Article 6(1)(f) legitimate-interests assessments. Where, on review, this condition is judged not to fit a given low-level technical processing activity, the correct response is to minimise that activity until it no longer turns on special-category inference (for example, by truncating or not retaining IP addresses) rather than to assert a condition that does not apply. We have designed the analytics to make that minimisation feasible.

How explicit consent is given. Where we rely on consent, you give it through a clear, specific, unbundled, non-pre-ticked action at the point of the relevant activity — when you create an account, when you start a quiz (if and where any Article 9 processing occurs server-side; see Section 5.3), when you subscribe to the newsletter, and when you join the forum and post. We record that consent so we can demonstrate it (Article 7(1)). We do not claim to obtain Article 9 consent from anonymous visitors at the 18+ gate; the gate is an age check, not a consent record (see Sections 4, 6, and 8).

How consent is withdrawn, and the "freely given" question. You can withdraw consent at any time, as easily as you gave it (Section 13). For the consent-based activities, withdrawing consent means we stop that processing and, where the account exists to deliver a consent-based feature, we may close the relevant account or feature — but this does not make consent invalid, because you can read the entire blog without an account and without consenting to anything beyond the unavoidable technical processing: membership, quizzes, and the forum are genuinely optional, additional services, so consenting to them is a real choice and declining does not deny you the core service. Withdrawal does not make past, already-lawful processing unlawful (Article 7(3)). For the safety/moderation records held under Article 9(2)(g)/(f), withdrawing consent does not delete those records, because they are not held on the basis of your consent in the first place; we keep them only as long as Section 11 allows.

We minimise by design. We collect very little; the forum is text-only; quiz answers are processed in your browser; analytics are cookieless and IP handling is minimised; and there are no advertising trackers.

We acknowledge the real-world risk. The most serious risk here is "outing" — sensitive information being exposed without your wish. We design the site and our security (Section 12) to reduce this, and we strongly encourage you to use a pseudonymous username and to share only what you are comfortable making public.

We maintain a Data Protection Impact Assessment (DPIA) for this processing (Section 15).

4. Adults only (18+)

feederism.org is for adults aged 18 or over. It is not directed at minors, and minors may not use it.

Entry to the site is gated by an 18+ age gate. When you confirm you are 18 or over, the site stores a small flag in your browser's local storage so it does not have to ask you again on every page. This flag stays on your device, is not a cookie, and is not sent to advertisers (see Section 8). Because this flag is stored only on your device and is not transmitted to us, it is not, and cannot be, a record of consent for data-protection purposes.
When you create an account, you are also required to confirm you are 18 or over.

Two different legal regimes — please don't conflate them. Satisfying the GDPR's "18+" expectation for this kind of content is not the same as satisfying the UK Online Safety Act (OSA). The GDPR question is about lawful basis and consent; the OSA question is about "highly effective age assurance" for adult content. We keep our age-assurance approach under active review with professional counsel, including whether stronger age assurance is required for UK users; if we adopt a third-party age-verification provider, that would introduce a new, highly sensitive processor and a likely new international transfer, which we would add to Sections 5, 9, 10, and our DPIA before deploying it.

If we become aware that we hold data relating to anyone under 18, we will delete it and close the associated access promptly. If you believe a minor is using the site, please contact [email protected].

5. What data we collect, by who you are

We collect only what we need. What we hold depends on how you use the site. Almost all of this data is collected directly from you. Where any data is not collected directly from you — for example, security and bot signals generated by Cloudflare about your connection — we identify it below and in Section 9, so that the Article 14 "source of data" position is clear; we do not buy, enrich, or otherwise obtain personal data about you from data brokers or other third parties.

5.1 Anonymous visitors (everyone, including people just reading the blog)

Data	Source	What it is / why
Cookieless usage analytics	Self-hosted Umami	Aggregate, privacy-friendly statistics: page views, events, referring site, approximate location derived from IP, and device/browser type. No cookies; no cross-site tracking; no third-party trackers. Umami processes your IP server-side to derive approximate location and is configured to minimise IP retention (Section 8).
Essential session cookies	The site (Ghost / Flarum)	Strictly-necessary cookies that keep a signed-in member or forum session working. Set only once you sign in. Named individually in Section 8.
18+ age-gate flag	Your browser's local storage	A small on-device flag recording that you confirmed you are 18+. Stays on your device; not transmitted to us. See Section 8.
Our server access logs	Our server (Hetzner, EU)	IP address, timestamp, request path, response code, and browser/User-Agent, processed for security, abuse-prevention, and debugging. Controller: us. Retention: Section 11.
Cloudflare connection & security logs	Cloudflare (see 5.1 note)	Separately from our own logs, Cloudflare processes your IP, connection metadata, request URLs, and bot/abuse signals as it proxies and secures traffic. Different controller arrangement, location, and retention from our server logs — see Sections 9, 9.1, and 10. Some of this is generated about your connection rather than provided by you (Article 14).

5.2 Members (free accounts)

Membership is free and passwordless. We currently operate no paid tiers and take no payments (there is no payment processor in use).

Data	Source	What it is / why
Email address	You, at sign-up	Used to send you a magic link to sign in, and to send service emails. We do not store a password.
Optional display name	You, at sign-up	Shown where relevant; optional.
Magic-link / session data	The membership system (Ghost)	Short-lived sign-in tokens and your logged-in session. A magic link is a bearer token — anyone who obtains the link can use it until it expires (see Section 12).
Account metadata	The membership system (Ghost)	Standard membership metadata such as sign-up date and last-seen / last-active time (note: last-seen reveals when an account on this site is active, which is itself sensitive — see Section 7).
Newsletter status & email engagement metadata	Ghost + SMTP2GO	If you subscribe: subscription status, plus delivery, bounce, open, click, and unsubscribe/complaint metadata generated when we send you email. We use this to run the mailing list and keep our sender reputation healthy; we do not use it to profile you.

5.3 Quiz and tool users

Our quizzes and tools (the feeder/feedee quiz, the couples alignment quiz, and the /quizzes/ hub) run in your browser (client-side):

Your quiz answers are processed locally, on your device. They are not transmitted to or stored on our servers as part of taking the quiz.
Only anonymous, aggregate usage of the quizzes is measured — for example, that a quiz was started or completed — via cookieless Umami. This aggregate measurement is not designed to capture the content of your answers.
Saving / unlocking your results is done by creating a free account (Section 5.2). Creating that account links your email address to the site. Where you choose to save a result into your member record, we treat that as Article 9 special-category data, capture your explicit consent at the point of saving, and apply the retention set out in Section 11.

5.4 Forum members

The forum at https://feederism.org/forum/ runs on the Flarum software. You sign in to it only through your existing feederism.org account, via single sign-on (Section 9.2); there is no separate forum password.

Data	Source	What it is / why
Forum username	Your account	Shown publicly on your posts.
Email address	Your feederism.org (Ghost) account, via SSO	Identifies your forum profile; used for forum notifications.
Post / thread text (incl. edit history)	What you type	The forum is text-only. Flarum retains edit history, and other members can quote your post. Your posts are public and may be indexed by search engines — see Section 7.
Last-seen / online presence	Generated by Flarum	Flarum can display when you were last active / whether you are online. This reveals when you use a sexual-interest site and is treated as sensitive.
IP address	Your connection	Used for security and abuse-prevention.
Moderation records (incl. third-party data)	Generated by us, and by other members when they report you	Flags/reports, warnings, bans, and moderator notes. These can contain another person's data: if you report someone, your identity and your report are stored in their moderation file, and vice versa. We treat these records with Article 9 care and hold them under Article 9(2)(g)/(f), not consent (Sections 3, 6, 11).
Anti-abuse / CAPTCHA challenge data	Anti-bot challenge provider, where used	If an anti-bot challenge is used at sign-up, login, or posting, the challenge provider processes connection and challenge-response data to tell humans from bots. Where such a provider involves an international transfer, it is covered in Sections 9 and 10. Where no challenge is used, abuse-prevention rests on IP-based and moderation controls only.

We do not require any special-category data beyond what you voluntarily provide. We do not sell your data, we do not use it for advertising, and we do not build behavioural profiles of you.

6. Why we process your data, and our legal bases

Under the GDPR we must have a lawful basis (Article 6) for each processing activity. Because of the by-inference sensitivity explained in Section 3, every activity below also has an Article 9 condition — and we deliberately use different Article 9 conditions for different activities, because no single condition fits all of them. We never leave an Article 9 column blank.

Purpose	Data used	Lawful basis (Art. 6)	Additional Art. 9 condition
Serving the blog and public pages; core security	Server access logs, IP, technical data	Legitimate interests (Art. 6(1)(f)) — operating and securing the site	Substantial public interest (Art. 9(2)(g)) — operating and protecting a lawful adult service; minimise IP retention where the condition is doubtful
Running the 18+ gate	On-device flag	Legitimate interests (Art. 6(1)(f)) — restricting adult content to adults	Substantial public interest (Art. 9(2)(g)). No consent is claimed here — the flag is not transmitted and is not a consent record
Creating and operating your membership account	Email, optional display name, session	Performance of a contract (Art. 6(1)(b)) — providing the optional account you asked for	Explicit consent (Art. 9(2)(a)) — captured at sign-up; the account is an optional add-on, so this consent is freely given (Section 3)
Running quizzes and tools	Processed in your browser; aggregate usage only	Consent (Art. 6(1)(a)) — for any optional quiz processing	Explicit consent (Art. 9(2)(a)) — captured at quiz start / at "save" if any result is persisted (subject to Section 5.3)
Publishing and storing your forum posts	Forum username, post text, edit history	Consent (Art. 6(1)(a)) for the optional act of posting	Data manifestly made public by you (Art. 9(2)(e)) for continued storage/display, and your explicit consent (Art. 9(2)(a)) at the act of posting — see the hedge in Section 7
Moderation, safety, abuse-prevention records	Post text, moderation records, IP	Legitimate interests (Art. 6(1)(f)) — keeping the community safe; legal obligation (Art. 6(1)(c)) where applicable	Substantial public interest (Art. 9(2)(g)); and, where a claim is in prospect, legal claims (Art. 9(2)(f)). Not consent — these records must survive withdrawal
Cookieless aggregate analytics	Umami data; minimised IP	Legitimate interests (Art. 6(1)(f))	Substantial public interest (Art. 9(2)(g)); processing minimised so it does not turn on Art. 9 inference where feasible (Section 8). Not consent — a valid Art. 9(2)(a) record cannot be taken from an anonymous visitor
Sending magic-link, transactional, and forum-notification emails	Email, delivery/engagement metadata	Performance of a contract (Art. 6(1)(b))	Explicit consent (Art. 9(2)(a)) — given when you create the account / subscribe that these emails serve
Sending the newsletter	Email, engagement metadata	Consent (Art. 6(1)(a))	Explicit consent (Art. 9(2)(a)) at subscription
Handling your data-subject requests and correspondence	Correspondence, account data	Legal obligation (Art. 6(1)(c)) for rights requests; legitimate interests for other correspondence	Substantial public interest (Art. 9(2)(g)) / legal claims (Art. 9(2)(f)) where the correspondence concerns special-category data; explicit consent where you volunteer such data to us

Why we don't put everything on consent. Consent only works where it is genuinely free, specific, and recorded. It is the right condition for things you actively opt into (account, quizzes, newsletter, posting). It is the wrong condition for (a) anonymous-visitor logging and analytics — we have no way to take or evidence a valid explicit consent from an anonymous visitor — and (b) safety and moderation records that must persist against a user's wishes (you cannot let a banned user delete the ban by withdrawing consent). For those we rely on substantial public interest (and, for safety records, legal-claims), with documented assessments.

No advertising, no tracking, no selling. We do not sell or rent your personal data; we run no advertising, no third-party trackers, and no cross-site tracking; and we do not share your data with ad networks or data brokers.

Legitimate interests. Where we rely on legitimate interests, we have carried out and documented a balancing assessment (LIA). You can object (Section 13), and we explain there which processing your objection actually reaches.

Automated decision-making. We do not carry out automated decision-making or profiling that produces legal or similarly significant effects on you (Article 22). Quizzes give you a self-assessment result, not a decision about you. See Section 14.

7. The community forum is public and searchable — please read before posting

This is the highest-risk part of the site, so we set it out plainly.

When you post in the forum:

Your forum username and the text of your post are public. They can be read by other members and by anyone on the open internet.
Search engines can index your posts. This means your username and what you wrote may appear in search results and may be copied or cached by third parties outside our control.
By posting, you are making special-category data about yourself public. We capture your explicit consent to this at the point of posting (Article 9(2)(a)), and we also rely on the condition for data you have manifestly made public (Article 9(2)(e)) for keeping and displaying what you publish.

An honest hedge on Article 9(2)(e). Regulators read "manifestly made public" narrowly. Because the forum sits behind an 18+ login wall and we encourage pseudonymous posting, it is arguable that posts are not "manifestly made public" by you in the strict Article 9(2)(e) sense. We therefore do not rely on 9(2)(e) alone: your explicit consent at posting is the primary condition, with 9(2)(e) as additional support, and Section 11 retention is set so that we are not dependent on a single contested condition.

What we do to limit the risk:

Forum threads are intended to be indexable, while member profile pages are set to noindex. This lets discussions be found while making it harder for search engines to aggregate a person's entire posting history under their identity.
The forum is text-only, which reduces the sensitive data (e.g. images with embedded location/EXIF) that could otherwise be exposed.

What you can do to protect yourself:

Use a pseudonymous username that is not linked to your real identity elsewhere.
Do not post self-identifying details (real name, workplace, photos, social handles, precise location).
Remember that once something is public, it can be copied before you delete it.

Deleting forum content — and its real limits. You can delete your posts and close your forum participation (Section 13). We will delete the content at source and, where appropriate, request that search engines de-index it, consistent with regulator guidance on the right to erasure for search results (EDPB Guidelines 5/2019). However, even within the forum, deletion has limits you should understand:

Other members may have quoted your post inside their posts; deleting your original does not automatically remove those quoted copies.
Flarum may retain edit history for operational and moderation integrity.
Once content has been public and indexed, we cannot guarantee its complete removal from third-party search caches or from copies others may have made.

We will take reasonable steps, including removing or redacting quoted copies on request where feasible; we cannot promise the impossible.

8. Cookies, local storage, and analytics

We keep the site cookie-light, and we do not show a cookie-consent banner because we do not set or read the kind of device storage that triggers the consent rule. Here is exactly why, and exactly which cookies exist:

Strictly-necessary session cookies only. When you sign in, we use essential session cookies to keep you logged in. These are exempt from consent because they are strictly necessary to provide the service you asked for. These comprise the Ghost membership session cookie (which keeps your member session signed in) and the Flarum forum session and CSRF-protection cookies (which keep your forum session active and protect form submissions). They are set only once you sign in and last no longer than needed to maintain your session. A current, itemised list of cookie names and durations is available on request by emailing [email protected].
Cookieless analytics (Umami). We run our own self-hosted Umami analytics. Umami does not set or read cookies and stores nothing on your device, so the device-storage rule that normally triggers a cookie-consent banner (ePrivacy / PECR) is not triggered — that rule is about storing/reading on your device, which Umami does not do.
But the IP is processed separately — and here is the honest position. Umami still processes your IP address on our server to derive an approximate location. The consent-to-store question (above) is not the same as the lawful-basis question for that IP processing. We do not claim "explicit consent" for it, because we cannot obtain valid explicit consent from an anonymous visitor. The IP/location processing rests on legitimate interests (Art. 6(1)(f)) with Article 9(2)(g) as its special-category condition (consistent with Section 6), and we minimise IP retention so that, as far as practicable, the analytics do not turn on identifiable Article 9 data. (This corrects any impression that analytics run under a site-wide "consent posture" — they do not.)
18+ age-gate local storage. The 18+ gate writes a small flag to your browser's local storage so we do not re-ask on every page. Storing this flag to deliver the adult-content gate you have effectively requested is strictly necessary, so it does not require a consent banner. It stays on your device and is not a consent record.
No advertising or tracking cookies. No social pixels. No cross-site tracking.

In the UK, the Data (Use and Access) Act 2025 introduced a statutory consent exemption for low-risk, first-party analytics, which supports our no-banner position for the device-storage limb. Two honest caveats: (a) we rely on this exemption only to the extent it is in force at the date we publish; and (b) the exemption addresses the consent-to-store question only — it does not resolve the Article 9 sensitivity of the IP-based inference, which we handle under Section 6 as described above.

We use a small number of trusted service providers, each acting under a written agreement. We do not sell your data, and we share it only as described here or where we are legally required to. We commit to notifying members of any change of sub-processor for the email and infrastructure services that handle identifiable data, where we reasonably can, so you can object before the change takes effect.

Recipient	Role	Location	GDPR status	Transfer safeguard
Hetzner	Server + database hosting; backups	EU — Finland	Processor (Art. 28 DPA)	None needed — data and backups stay in the EU
Cloudflare	CDN / reverse proxy / security; TLS-terminates (so it processes visitors' IPs and in-transit traffic, including request URLs that can reveal the subject)	United States (global network)	Processor for proxying on our instructions (Art. 28 DPA); independent controller for its own security/network logs — see 9.1	EU–U.S. Data Privacy Framework + UK Extension, with EU SCCs / UK IDTA as a contractual fallback — see Section 10
SMTP2GO	Transactional email + newsletter delivery (magic links, notifications)	United States	Processor (Art. 28 DPA)	EU SCCs / UK IDTA in its data-processing agreement, supported by Data Privacy Framework listing where applicable — see Section 10
Ghost (self-hosted)	Membership accounts / SSO	EU — same server, Finland	Our own system	Not an external transfer
Flarum (self-hosted)	Forum software / posts	EU — same server, Finland	Our own system	Not an external transfer
Umami (self-hosted)	Cookieless, first-party analytics	EU — same server, Finland	Our own system	Not an external transfer

Software supply chain. Ghost, Flarum, and Umami are open-source software we self-host on our EU server; we do not use Ghost(Pro) or any managed/hosted edition, and our backups are held on EU infrastructure (Section 10).

Other recipients — other members and the public. As explained in Section 7, content you post in the forum is disclosed to other members and, because the forum is public, to anyone on the internet, including search engines.

Legal disclosures. We may disclose data where we are legally obliged to (for example, a valid legal request), or where necessary to protect the safety and rights of members or the public — but we will resist any request that is not lawful and proportionate, and we keep your data minimal precisely so there is little to disclose.

9.1 Cloudflare's own processing

Cloudflare sits in front of the site and TLS-terminates traffic, so it necessarily processes the IP addresses and connection metadata of everyone who connects — including request URLs that, on this site, can reveal the subject by inference. For traffic it proxies on our instructions, Cloudflare acts as our processor under an Article 28 data-processing agreement. For its own network-security and abuse-prevention logging, Cloudflare acts as an independent controller under its own privacy policy and retains those logs under its own retention schedule, independently of ours (Section 11). We are not using "controller-like" as a status — Cloudflare is either our processor (proxying) or its own controller (its security logs), as stated. Please see Cloudflare's published privacy documentation for details of its independent processing.

9.2 Single sign-on between Ghost and Flarum

The forum (Flarum) authenticates you using your existing feederism.org (Ghost) account through a single-sign-on bridge that we operate on the same EU server. Passing your email and username between our own Ghost and Flarum systems is internal processing, not an external transfer.

10. International data transfers

Most of your data — and your backups — stay in the EU (Finland), because our server, database, membership system, forum, analytics, and backups are all hosted there.

Two providers — Cloudflare and SMTP2GO — are in the United States, so using them involves transferring personal data outside the EU and UK. Because of the subject matter of this site, data that transits the US (for example, IP addresses and request URLs handled by Cloudflare, and the member email addresses handled by SMTP2GO) can itself reveal special-category information by inference — the email list, which links a real address to this site, is the single most sensitive dataset we hold. We protect these transfers under Chapter V of the GDPR, and Article 13(1)(f) requires us to name the specific safeguard for each:

Cloudflare: the primary mechanism is the EU–U.S. Data Privacy Framework + UK Extension (Cloudflare self-certified), with EU SCCs / UK IDTA as a contractual fallback. We verify the Data Privacy Framework certification status at publication, and note that the EU adequacy decision for the Framework remains subject to legal challenge.
SMTP2GO: the transfer is governed by EU SCCs / UK IDTA in its data-processing agreement, supported by Data Privacy Framework listing where applicable, and we maintain a Transfer Impact Assessment that weighs the sensitivity of the member email list.

You can request a copy of the relevant safeguards by emailing [email protected].

11. How long we keep your data (retention)

We keep personal data only for as long as we need it, then delete it. Article 13(2)(a) GDPR requires us to state the retention period or the criteria used to set it.

Data	Retention period / criteria
Membership account data (email, optional display name, newsletter status)	While your account is open; deleted within 30 days of account closure or consent withdrawal
Email engagement metadata (delivery, bounce, open, click, unsubscribe)	12 months rolling, then deleted or aggregated
Magic-link / session tokens	Short-lived; expire automatically
Forum username and post / thread text (incl. edit history)	While your account is open; deleted within 30 days of account deletion or consent withdrawal (subject to the public-content limits in Section 7)
Moderation / safety records (flags, reports, warnings, bans, notes — held under Art. 9(2)(g)/(f), not consent)	While needed to keep the community safe and handle appeals, and for 12 months after an account closes (to prevent ban evasion); then deleted. Retained against withdrawal because the basis is not consent
Our server access logs (IP)	30 days, then deleted
Cloudflare's own logs	Held by Cloudflare as independent controller under its own schedule; we do not control it
Cookieless analytics	Aggregate only; raw IP minimised/truncated; aggregate retained 12 months
Transactional email metadata (SMTP2GO)	Set to the shortest workable period consistent with delivery and deliverability needs
Support / rights correspondence	12 months after the matter is closed
Consent records	While the consent is relied upon, plus 3 years afterwards, to evidence compliance (Art. 7(1)). We keep this minimal: enough to prove a valid consent existed, no more, because retaining sensitive linkage is itself Article 9 processing that must be necessary and proportionate
Backups	Backups are retained on a 30-day rolling cycle and then overwritten. When we delete your data from the live systems, it persists in backups only until the relevant backup rotates out; we do not restore deleted data from backup except to recover from a disaster, and we re-apply your deletion if we do (see Section 13)

Quiz answers are processed in your browser and are not stored server-side as part of taking a quiz. Where you choose to save a result into your member record, that saved result is retained on the same basis as your membership account data above.

12. How we protect your data (security)

We take security seriously, because the cost of a breach here could be high (Articles 5(1)(f) and 32). Our measures include:

Encryption in transit (HTTPS/TLS) for all connections.
Passwordless authentication for membership (magic links). This removes stored-password risk — there is no password database to leak. It is not risk-free, though: a magic link is a bearer token, so anyone who gains access to your email inbox, or who intercepts a link, could use it until it expires. Keep your email account secure; links are short-lived.
EU hosting on a server in Finland, with access controls, hardened configuration, and EU-resident backups.
Strict access limits — only the operator has application-admin access. (Note: infrastructure providers — Hetzner, Cloudflare, SMTP2GO — necessarily have their own staff/infrastructure access to the systems they run, under their own contracts and controls; we do not claim otherwise.)
Privacy-protective design — a text-only forum, cookieless analytics, minimised IP retention, no advertising trackers, and encouraged pseudonymity.
Written processor agreements (Article 28) with our providers.
A breach-response procedure (Section 16).

No system can be guaranteed perfectly secure, but we work to protect your data and to minimise how much sensitive data exists in the first place.

13. Your rights, and how to use them

Under the EU and UK GDPR you have the following rights. To exercise any of them, email [email protected]. Because our processing rests on different legal bases for different activities (Section 6), some rights apply to some activities and not others — we explain that below rather than imply every right reaches everything.

Right of access (Art. 15) — confirmation of, and a copy of, the data we hold about you. Where your record contains another person's data (for example, a moderation report that names someone else, or a post that quotes another member), we may redact that third party's data before disclosing, to protect their rights.
Right to rectification (Art. 16) — correction of inaccurate data.
Right to erasure / "right to be forgotten" (Art. 17) — deletion of your data, including your account and posts (subject to the public-content limits in Section 7). Erasure does not automatically extend to: (a) safety/moderation records we are entitled to keep under Article 9(2)(g)/(f) and Section 11 (e.g., ban records, to prevent evasion); (b) data we must keep to meet a legal obligation; and (c) copies in backups, which are removed when the backup rotates out rather than instantly (Section 11).
Right to restriction (Art. 18) — limiting how we use your data in certain cases.
Right to data portability (Art. 20) — receiving the data you provided in a structured, machine-readable format. This applies to data processed by consent or contract (your account details, your forum posts, your email/newsletter data). It does not extend to derived or analytics data or to logs, which are not "provided by you" and are not processed on those bases.
Right to object (Art. 21) — this right applies to processing based on legitimate interests, which here means our analytics, server logging, security, and moderation processing. It does not apply to the consent-based core (account, quizzes, newsletter, posting), where the corresponding right is withdrawal of consent, below. Note that some safety/moderation processing may continue despite an objection where we show compelling legitimate grounds (e.g., preventing abuse).
Right to withdraw consent (Art. 7(3)) — at any time, as easily as you gave it, for the consent-based activities (account, quizzes, newsletter, the act of posting). Withdrawing consent for a feature generally means we stop that feature and delete the associated consent-based data. It does not delete safety/moderation records held under Article 9(2)(g)/(f), and it does not affect processing already carried out lawfully before you withdrew.

Automated decisions (Art. 22): we do not make automated decisions or profile you with legal or similarly significant effects, so this right is not engaged; if that ever changes, we will tell you first.

How we handle your request:

Timing: we respond without undue delay and within one month. For complex or numerous requests we may extend by up to two further months, telling you within the first month and explaining why. Where we reasonably need clarification to act on your request, the time limit may pause until you provide it (a "stop-the-clock", as recognised under the UK Data (Use and Access) Act 2025).
Cost: free, unless a request is manifestly unfounded or excessive (when we may charge a reasonable fee or decline, with reasons).
Identity verification — by your account, not by ID documents. Because accounts are pseudonymous, we confirm requests through the account itself (for example, by acting only on a request from your registered email address or your logged-in session). We will not ask you to send government ID — demanding identity documents from a member of a sexual-interest site would force you to disclose more sensitive data than we hold. If account-based verification is genuinely impossible for a request, we will look for the least-intrusive alternative.

14. Automated decision-making and profiling

We do not carry out automated decision-making or profiling that produces legal or similarly significant effects (Article 22). The quizzes and tools produce a self-assessment result for your own use — they do not make decisions about you, rank you, or feed any automated judgement. If this ever changes, we will update this Policy and explain your rights before any such processing applies to you.

15. Data protection impact assessment (DPIA)

Because we process special-category data about a potentially vulnerable community, on a public and indexable forum, with "outing" as a foreseeable high-impact risk, we treat a Data Protection Impact Assessment (DPIA) under Article 35 as required, and we maintain one assessing those risks and the safeguards described in this Policy (including the noindex-on-profiles control, IP minimisation, the multi-condition Article 9 model, the OSA age-assurance exposure, and the US transfers). The DPIA is reviewed and updated as the service and our legal arrangements develop.

16. Data breaches

If a personal-data breach occurs, we will act quickly:

We will notify the relevant supervisory authority within 72 hours of becoming aware of it (Article 33), unless it is unlikely to result in a risk to people's rights and freedoms.
If the breach is likely to result in a high risk to you, we will also notify you without undue delay (Article 34). Because this site involves special-category data, we treat high risk as the default for any breach that exposes the link between a person and this site.

Notifying you without making things worse. A breach notice can itself out you. So we use the least-revealing method that is still effective — neutral wording, avoiding naming the site in a subject line or preview where possible, preferring an in-account/on-login notice where appropriate — following regulator guidance on safe breach communication.

We maintain an internal breach register and response runbook.

17. Complaints and supervisory authorities

If you have a concern, please contact us first at [email protected] — you have the right to complain to us directly (a route reinforced by the UK Data (Use and Access) Act 2025), and we would like the chance to put things right.

You also have the right to lodge a complaint with a data-protection supervisory authority:

In the UK: the Information Commissioner's Office (ICO) — https://ico.org.uk/.
In the EU: you may lodge a complaint with the supervisory authority in your own EU country of residence. Whether an EU "one-stop-shop" lead authority also applies depends on the controller's place of establishment, which is being confirmed with professional counsel (Section 2.1); we will state the confirmed position here once settled. Your right to complain to your own local supervisory authority is unaffected in the meantime.

You also have the right to an effective judicial remedy.

18. Children — 18+ only

As stated in Section 4, feederism.org is for adults aged 18 or over only, is not directed at children, and may not be used by anyone under 18. If we become aware that we hold data relating to a person under 18, we will delete it and close the associated access promptly. As noted in Section 4, the GDPR 18+ position and the UK Online Safety Act age-assurance duties are separate regimes.

19. Changes to this Policy

We may update this Policy from time to time. When we make material changes, we will update the "Last updated" date and notify members through the site or by email. For anonymous visitors, who have no contact address, we give notice by posting the updated Policy and a prominent on-site notice of material changes (for example, at the 18+ gate or as a site banner) for a reasonable period — so the visitor population is not left uninformed. If we ever materially change how we process special-category data on a consent basis, we will ask for your fresh explicit consent before that new processing applies to you.

20. Contact

For any privacy question or request — including data-subject rights and withdrawing consent — contact:

[email protected]

Controller: the individual operating feederism.org under the pseudonym "Clair" (formal legal-entity registration being finalised with professional counsel). Postal / service address: available on request by emailing [email protected] (a formal service address is being finalised). Representatives: a representative will be appointed where legally required; in the meantime, contact [email protected].

21. Definitions (glossary)

Controller — the person/organisation that decides why and how personal data is processed (here, the individual described in Section 2).
Processor — a service provider that processes data on the controller's instructions (e.g. Hetzner, SMTP2GO; Cloudflare when proxying).
Personal data — information relating to an identified or identifiable person.
Special-category data — sensitive data, including data revealing sex life or sexual orientation, given extra protection under Article 9 GDPR.
Explicit consent (Art. 9(2)(a)) — a clear, specific, affirmative agreement to a defined processing of special-category data.
Manifestly made public (Art. 9(2)(e)) — a condition for processing special-category data that a person has clearly chosen to publish; read narrowly by regulators (see Section 7).
Substantial public interest (Art. 9(2)(g)) — a condition for processing special-category data where necessary for reasons of substantial public interest under EU/UK law, subject to suitable safeguards (used here for safety records, logging, and analytics).
Bearer token — a credential (such as a magic link) that grants access to whoever holds it, until it expires.
Magic link — a one-time, short-lived sign-in link sent to your email, used instead of a password.
noindex — an instruction asking search engines not to index a page; applied to member profile pages as described in Section 7.

The in-browser tools

The pages under feederism.org/tools/ (the Agreement Builder, the Disclosure Letter Builder, and future tools marked as in-browser) are designed so that we cannot see what you type, even if we wanted to:

Nothing you enter is transmitted to us or to anyone. The tools run entirely in your browser. Your entries, drafts, and any documents you generate never leave your device unless you yourself print, download, copy, or share them.
Drafts live in your browser's local storage only, so you can pause and resume on the same device. Every tool has a one-click "erase" that removes the draft from your browser. Clearing your browser data does the same.
We count anonymous usage events only (for example: a tool was started, completed, or printed), with no content attached, via our self-hosted, cookieless analytics. We cannot connect these counts to you.
No account is required for any tool, and no tool ever asks for one.