Legal & Takedown — Removing Phishing Sites
Two legal workstreams the platform treats as first-class data: takedown enforcement against fraudulent content, from the request through to verifying that it is actually gone, and compliance with the LGPD, Brazil’s general data protection law — consent records and handling of data subject requests.
Takedown: From Request to Verification
Every case records its type (fourteen options, from phishing and fake profiles to fraudulent apps, data leakage, defamation and privacy violations), the target platform among 23 mapped providers — including Registro.br, Locaweb, Mercado Livre, OLX and Shopee alongside the global ones — and its priority.
The lifecycle has ten states: requested, notified, acknowledged, in progress, awaiting response, escalated, completed, partially removed, failed and cancelled. The last two exist by design: a takedown workflow that can only represent success is lying about its own effectiveness rate.
Legal basis is a required field, not a remark. The options name the law: DMCA, the Brazilian Internet Civil Rights Framework (Marco Civil da Internet, Lei 12.965/2014), the LGPD (Lei 13.709/2018), the Brazilian Child and Adolescent Statute (ECA), the Consumer Protection Code, the Copyright Act (Lei 9.610/1998), the Criminal Code, and the platform’s own Terms of Service. The notification method is recorded separately, with nine options ranging from e-mail and abuse forms to out-of-court notices and court orders.
That separation reflects Brazilian law. Under the Marco Civil, Art. 19, an application provider is only civilly liable for third-party content if it fails to comply with a specific court order to remove it; the exception in Art. 21 covers scenes of nudity or private sexual acts, which can be removed on notice from the person depicted. In practice, almost every takedown outside those situations depends on the platform’s own terms of use — which is why “Terms of Service” is a legitimate legal basis on the form, not a shortcut.
Evidence and infrastructure
The case stores the target URL, additional URLs carrying the same content, evidence URLs and screenshots. It also stores what backs the technical notice: DNS, WHOIS, SSL certificate data and hosting information — provider, ASN, IP and abuse contact. For fifteen platforms there is a direct link to the official abuse channel, which removes the manual hunt for the right form.
SLA and escalation
The deadline is tracked with a computed state: met, breached, critical (less than a day left), attention (less than three days) or within deadline. The “SLA breached” field exists precisely to record what was not met.
Escalation has four explicit levels — initial, supervisor, legal and judicial — with the reason recorded at each step. After completion the case stays alive: number of verification attempts, date of the last one, and the “content still online” field, because phishing that was taken down comes back.
Every action becomes an entry in the case history: creation, state change (with previous and new value), notice sent, response received, escalation, verification, note, evidence and owner assignment.
LGPD: Consent and Data Subject Requests
Consent records. Four categories — essential, preferences, analytics and marketing — with a granted or withdrawn action, the policy version in force and the origin (banner, modal, API, administrative correction, migration or reset after a policy change). Essential categories generate no record, because they do not rely on consent.
IP address and user agent are stored as salted hashes, never in the clear. That decision resolves a real tension: the law places on the controller the burden of proving that consent was validly obtained (Lei 13.709/2018, Art. 8º, § 2º), but keeping IP addresses in the clear to prove compliance creates a new store of personal data. The hash proves the association without retaining the identifier.
The client IP is resolved by counting from right to left in the X-Forwarded-For header, with the number of trusted proxies configurable — because a client can prepend any IP address on the left.
Data subject request (DSAR). A public form, no login required, with six request types: access, correction, deletion, portability, withdrawal of consent and anonymization. It is protected by Cloudflare Turnstile and by a limit of five submissions per IP per hour; consent recording has its own limit of thirty writes per IP every five minutes.
The moment it is opened, the request is created with a 15-day deadline — the deadline set by Art. 19, II of the LGPD for providing the data subject with a clear and complete statement — and with an identity verification token.
What the Module Does Not Do
- It does not send the notice for you. It records the text that was sent, the abuse contact used, the ticket number and the platform’s response. Sending is the analyst’s act.
- It ships no library of ready-made templates per provider. Notice content is drafted and filed case by case.
- It guarantees neither removal nor a removal deadline. The SLA is the deadline agreed with the customer, not a commitment made by the target platform.
- It does not replace a lawyer, does not issue legal opinions and does not draft pleadings.
- The verification e-mail for the public data subject request is not sent automatically yet — the token is generated and the request enters the verification queue.
- The case history is a complete record of actions, with author and date. Cryptographic chaining and WORM export belong to the Audit & Compliance module.
Integrations
- Cloudflare Turnstile on the public form
- Abuse channels for 15 platforms, with direct links
- OODA URLs (technical analysis of the target), OODA Investigate, OODA Reports and OODA Audit
SLA & Guarantees
Legal basis and notification method recorded per case · SLA with an explicit breach state · recurring post-removal verification