Position statement

The law and Rotector

The legal basis for what we do, the answers to the questions we hear most often, and the commitments we accept on requests we receive.

Last updated: April 28, 2026

Rotector identifies Roblox accounts whose patterns indicate involvement in the production or coordination of child sexual exploitation content. We do this without first asking the flagged account holder, and we keep the flag in place even when the account holder asks us to remove it. People reasonably wonder whether that is lawful. This page is our answer.

Most of the data we process is already public; the rest is data we collect on properties we operate. The lawful basis is the legitimate interest of children using the platforms we observe, and the people who look after them. The right to erasure is not unconditional, and we rely on the carve-outs in European and UK law the way they were written to be relied on.

Part one

The formal position

Article I

Lawful basis: legitimate interests

We treat all the data we hold about an identifiable person as personal data within the meaning of of the General Data Protection Regulation, regardless of whether the source was public. The "public" framing in this document refers to where the data came from. It is still covered by GDPR.

Our lawful basis for processing it is : processing necessary for the legitimate interests of a third party, where those interests are not overridden by the rights and freedoms of the data subject. The third-party interest is the safety of children using a platform whose user base is materially populated by minors.

requires three things in sequence: a legitimate interest, the necessity of processing for that interest, and a balancing exercise weighing the interest against the rights and freedoms of the subject. The interest we rely on, child safety on Roblox, is recognised in regulator guidance as the kind of interest the provision was written for. Necessity means we cannot achieve the protective effect through less-intrusive processing; we work with the minimum data needed to flag the specific conduct, drawn from public profile fields and other lawful sources. We run the balancing test on every objection. The EDPB Guidelines 1/2024 on Article 6(1)(f) set out this three-step framework in detail.

Article II

Why we do not ask for consent

consent is one lawful basis among six. It is not required, and for safety processing it is not workable. A platform that asked accounts engaged in CSE conduct whether they consented to being flagged would receive predictable answers, and the resulting system would protect no one. The same logic applies to fraud detection, anti-phishing tooling, and platform anti-abuse work generally.

Consent is also incompatible with the structural posture of this system. We are not a service the flagged account uses; we are a third-party safety annotation about that account, surfaced to other people. was written for exactly this kind of relationship.

Article III

The right to erasure and its carve-outs

of GDPR establishes a right to erasure, and lists the situations in which the right does not apply. covers processing necessary for the establishment, exercise, or defence of legal claims, and we apply it where a flag record is part of an actual or threatened legal proceeding, a platform safety referral, or a law enforcement referral. For ordinary processing outside those situations, we rely on balancing rather than on .

We do not rely on . That subsection covers controllers vested with official authority or processing necessary to comply with a Union or Member State legal obligation, and we are neither a public authority nor under a statutory mandate to flag accounts. The work we do is in the public interest in the ordinary sense of those words, but requires more than that.

Where does not cover a request, we still weigh it under (the right to object), where the test is whether we have compelling legitimate grounds that override the rights and freedoms of the subject. That is a balancing exercise, not a blanket refusal, and we run it on every objection.

Article IV

The right to object

gives data subjects the right to object to processing based on . The controller must then stop, unless it can demonstrate compelling legitimate grounds that override the interests, rights, and freedoms of the subject, or the processing is for the establishment, exercise, or defence of legal claims.

Child protection is the kind of compelling ground was written for. We do not treat that as a free pass. Each objection is read on its own facts, including how recent the conduct was, whether the subject has been cleared by Roblox or by us, and whether the flag turns out to be wrong.

Article V

Children as data subjects

Some flagged accounts are operated by minors. of GDPR requires heightened care for children's data, and the EDPB has stated that children's interests can outweigh a controller's legitimate interest where the two are in tension.

Our position is that this raises the bar for retention of child-subject data, but does not move the bar to zero. The balance still leans toward retention where the subject's own conduct produces an active, current risk to other children. Where the conduct is dated, where the account has been cleared, or where a verified parent or guardian asks for erasure, we treat the request as presumptively granted. See "Limits we accept" for the operational version of this.

In the United States, COPPA governs the collection of children's information by online services. We treat the applicability of its specific exceptions to a third-party safety classifier of our shape as counsel-reviewed rather than settled. What we can say is that our processing is bounded to data we have a lawful basis to hold and is not used or disclosed for any unrelated commercial purpose.

Article VI

UK-specific position

Under UK GDPR, our substantive position is the same as for EU GDPR. UK law also provides a statutory exemption that operates independently of and that strengthens our position for UK subjects in specific cases.

provides an exemption from various subject-right provisions of UK GDPR to the extent that applying those rights would be likely to prejudice the prevention, investigation or detection of crime, or the apprehension or prosecution of offenders. Our processing is for the prevention and detection of conduct that endangers children, which the exemption recognises as a basis for limiting subject rights on a per-request basis. The exemption is not a categorical refusal: it is assessed per-request, and we apply it only where applying the right to that specific request would prejudice the work the exemption protects.

We have read ICO guidance, including the Children's Code, and use it as a reference where its provisions speak to what we do.

Part two

Common objections, plain answers

These are the questions we are asked most often by flagged users, by their parents, and by people writing to us through the support chat. The framing reflects the messages we actually receive.

"I have a right to be forgotten under GDPR. Why won't you delete me?"

The right to erasure is not absolute. of GDPR carves out processing necessary for the establishment, exercise, or defence of legal claims, which is the carve-out we rely on. UK subjects are also covered by the crime-prevention exemption at . That said, we do not refuse erasure requests reflexively. Where the flag is wrong, where the conduct is dated, where Roblox has deleted the account, or where the requester is a verified parent of an under-18 subject, we act.

"Your reason text says I did X. I didn't. That's defamation."

GDPR gives you the right to ask us to correct inaccurate data. The route is the support chat at rotector.com with a description of which part of the flag is inaccurate. If we got it wrong, we clear it.

We treat the reason text we publish as our own statement, not the data subject's. That means rectification is on us, and we own the consequences of getting it wrong.

"You're showing my Discord identity to anyone who asks. That's a privacy violation."

We surface the Discord accounts and tracked-server memberships associated with a flagged Roblox account when someone queries that account through the lookup API. The Discord-side data we hold comes from public servers that participate in our reporting program or from publicly observable activity. We do not read direct messages, and we do not access servers we have not been invited into. The recipient class is broader than just people who share those Discord spaces: API access requires authentication and is rate-limited. Restricting the linkage to moderators only would not protect children encountering the same actor across both platforms, which is the harm the linkage is there to prevent.

The legitimate-interest balance for this linkage is: a flagged account using a Discord identity to coordinate harm against children should not be able to escape that link by switching usernames. We accept this is uncomfortable for someone whose link is wrong, which is why rectification is fast.

"Your tool says these other accounts are 'alts of mine'. They're not."

The associated-accounts list reflects accounts we have observed using the same Discord identity as the queried account. Two unrelated people rarely share a Discord identity, so the link is a strong signal we stand behind in most cases. There are edge cases: a shared device, a sibling, a Discord account passed between hands, a previously-stolen account. If you believe the inference is wrong on a specific case, send us the IDs through the support chat and we will look at the underlying signals and adjust where the facts support it.

"I'm a member of a flagged group but I had no idea. Now your tool tells everyone I am."

Our group-tracking output lists members of groups we have classified as inappropriate. If you joined a group like that unknowingly (for example, before it was flagged, or because someone else added you) and you are not yourself flagged, the group membership alone is a low-confidence signal and is supposed to be displayed accordingly. If you believe your appearance there is producing a wrong impression about you, contact us. We will look at the specific case and adjust either the group classification or your association with it.

"I'm a parent. My child's account is flagged. Take it down."

Where we can verify that the requester is the parent or guardian of the underlying account holder, we treat the request as presumptively granted. The child's interest under of GDPR carries weight that an adult flagged subject's would not, and our default is to act on the request through the support chat.

The hard case is where the same account is the subject of a current law-enforcement referral. There we coordinate with the referrer before acting. We will tell you that this is happening; we will not silently refuse.

"I cleaned up my act years ago. The flag is old. Why is it still there?"

Tell us. We look at older flags on the facts: how dated the conduct is, whether the account has been quiet since, whether anything has surfaced that re-confirms the original concern. If the conduct is genuinely historical and the account has been clean for a meaningful stretch, removal is on the table.

"Why do you store my messages or my activity?"

Where we retain messages or activity records, the source is either a public channel readable by anyone in the server, or activity on a property we operate. We do not log direct messages on either Roblox or Discord. Retention is bounded to what is needed for the flag and any related referral, and we look at erasure requests for these records on a case-by-case basis.

"I'm in Canada / the UK / the EU. Don't you have to do something specific?"

We process subject rights requests under whichever regime applies to you. UK and EU residents are covered by the GDPR analysis on this page. Canadian residents outside Quebec: where PIPEDA applies, we honour the rights it provides. Quebec, Brazilian (LGPD), and other-jurisdiction residents: same intake, we apply the local regime.

"You're scraping Roblox without their permission. Isn't that already illegal?"

We use Roblox's public APIs to read public profile data, which is the same data any logged-in Roblox user can see by opening a profile. Whether our use of those APIs complies with Roblox's developer terms is a separate question from whether data protection law allows us to process the data we hold. The two questions have different forums and different remedies, and we treat them that way.

"Combining a public username with a behavioural label still produces personal data. Your 'public data' defence fails."

We agree it produces personal data, and we have always treated what we hold as personal data within the meaning of of GDPR. That is not the question we are answering. The question we are answering is whether we have a lawful basis under to process that personal data without consent. We do, and the basis is . The "public" framing in our copy describes where the data came from, not whether it is covered by data protection law.

"Claiming general safety is not enough for legitimate interests."

True for vague appeals to "safety." Not true here. requires a legitimate interest, the necessity of processing for that interest, and a balancing exercise. Our processing is bounded to one specific category of conduct: the production and coordination of child sexual exploitation content. The data we collect is bounded to what's needed to flag that conduct. We run the balancing test on every objection and keep the assessment on file. That is what Article 6(1)(f) was designed to permit, applied with the seriousness it requires.

"I am objecting in advance to any future processing of my data."

You can. lets you. We will record the advance objection. It does not switch our processing off automatically, because itself sets the test: the controller must stop unless it can demonstrate compelling legitimate grounds that override the rights and freedoms of the subject. We apply that balance on each new instance. If the balance still tips toward processing in the future, we process and document why; if it does not, we do not. A blanket pre-emptive objection does not bypass the balancing exercise the GDPR designed.

One related point that comes up: if we erase your data and you later engage in fresh conduct of the kind we flag, the resulting record is fresh processing on fresh facts, not continuation of the processing you objected to. The advance objection is on file, but it is weighed against the new conduct, not against the old. We do not promise never to flag you again regardless of what happens after the erasure, and any controller that did would be making a commitment the GDPR does not require it to make.

Part three

Limits we accept

The legitimate-interest defense is not a license to retain everything forever. These are situations where, on receiving a verified request, we act rather than litigate.

  • Verified parental erasure on a minor's flagged account.Requests reach a human moderator through the support chat. Where we can verify the requester is the parent or guardian, our default is to act on the request.
  • Confirmed false positive.The flag is cleared on a verified rectification request.
  • Roblox-side account deletion.Where we are made aware that Roblox has deleted an account, we redact our record so the flag is no longer visible.
  • Erasure of verbatim chat content absent an active referral that names those messages.On a verified subject request, we will look at which specific records you want removed and act case by case. The flag itself can stay even where the underlying message text comes down.
  • Backer access and deletion.If you have ever sent us a Ko-fi tip, subscription, or membership, contact us through the support chat and we will tell you what we hold tied to your contact details. We will revoke any active API keys and remove the contact details we are not legally required to retain for tax and financial-record purposes.

How to exercise your rights

The route is the support chat on rotector.com. State which right you are exercising (access, rectification, erasure, restriction, objection, portability) and the account or accounts at issue. We prioritise parental requests on minor accounts and confirmed false-positive flags.

Sources