Compliance, Abuse Handling & OSINT Service Information

Contents

1) Service Overview

Service Sherlock OSINT (sherlock.st) is an OSINT-oriented service that helps users perform research based on publicly available information from open sources.

What the service is

• OSINT only: the service is designed to work with information that is publicly accessible in open sources.
• Evidence-oriented: where feasible, results are intended to be attributable to a public source (e.g., a public webpage or public listing).
• Safety-first: we maintain policies and operational controls to prevent misuse and to respond to credible complaints.

What the service is not

• Not a doxxing service: the service is not intended for harassment, stalking, intimidation, or publishing private information for abuse.
• Not a breach-data marketplace: we do not position the service as a repository of stolen/leaked databases.
• Not “proven malicious” by infrastructure alone: the presence of a webhook endpoint or a reverse proxy does not demonstrate unlawful content.

2) Scope & Sources

sherlock.st operates with a strict scope: Russian Federation open sources only (“RF-only scope”).

RF-only scope statement

• We focus on open sources relevant to the Russian Federation and do not intentionally target non-RF jurisdictions.
• We do not market the service as an EU/EEA/US “people-search” product.
• If a report shows that a record creates a safety risk or is unlawful, we review it via the process below.

Definition of “open sources”

• Publicly accessible webpages and public resources where access does not require bypassing authentication or security controls.
• Information available without hacking, credential stuffing, malware, intrusion, or circumvention of protections.

Explicitly excluded sources

• Stolen/leaked databases, hacked dumps, breach repositories, credential lists, or content obtained via unauthorized access.
• Private communications or non-public data behind authentication intended to be private.

3) Acceptable Use Policy

Use of sherlock.st is subject to strict safety and compliance rules. Violations may result in restrictions or termination of access.

Prohibited uses (non-exhaustive)

• Doxxing, harassment, stalking, threats, intimidation, or facilitating violence.
• Blackmail, extortion, coercion, or targeted reputational attacks intended to harm individuals.
• Identity theft, account takeover, fraud, or evasion of law enforcement actions.
• Targeting minors or vulnerable individuals.
• Attempting to obtain or disseminate passwords, payment credentials, or unlawfully obtained sensitive identifiers.

Enforcement & response

• We may apply rate limits, feature restrictions, suspensions, or terminations when credible misuse is detected or reported.
• We maintain operational logs to support security and abuse investigations (subject to minimization and retention controls).
• We cooperate with lawful requests where required and legally valid.

4) Privacy & Data Handling

This section provides a reviewer-friendly summary of our privacy posture. It is not a substitute for legal advice, but it describes our operational process for complaints and requests.

Principles

• Minimization: collect/process only what is necessary for service operation and safety controls.
• Security: encryption in transit, access controls, monitoring, and incident response practices.
• Accountability: a single continuously monitored mailbox for abuse/privacy/provider communications.

Privacy / data subject requests

Notice-and-action approach (targeted, evidence-based)

• When provided with a specific record/result and evidence, we can review for suppression/correction.
• If information originates from a third-party publisher, we may also provide guidance to contact the original source.
• Emergency safety concerns should be marked URGENT with supporting evidence.

GDPR and “privacy law” allegations in bulk complaints

5) Abuse Reporting (Actionable Reports Only)

To investigate quickly, reports must be actionable. Reports that provide only a domain name, “webhook URL”, or general accusations without evidence are commonly non-actionable.

Submit a report

Email: abuse-sherlockosint@proton.me

Report template (copy/paste)

Subject: Abuse Report – sherlock.st – [short description]

1) Alleged violation:
   - (e.g., harassment, unlawful disclosure, impersonation, fraud facilitation, etc.)

2) Location (required):
   - Exact URL(s)/endpoint(s)/identifiers:
   - Date/time observed (timezone):

3) Evidence (required):
   - Screenshot(s) or exact output text:
   - Steps to reproduce:

4) Reporter contact:
   - Name / organization:
   - Email:
   - Jurisdiction (if relevant):

5) Requested action:
   - (e.g., suppress a specific record/result; investigate a specific account/session; etc.)

6) Provider / Registrar Checklist (Triage Guidance)

If you are considering action against sherlock.st based on a third-party complaint, we request evidence-based review and direct contact. This helps avoid mistakes caused by report-bombing and template claims.

Cloudflare / reverse proxy is not evidence of intent to evade accountability

• We may use reverse proxy/DDoS protection for security and uptime (industry standard).
• Masking origin IP is a common security feature and does not imply unlawful conduct.
• Accountability is provided via a continuously monitored contact mailbox and documented processes on this page.

7) Integrations, Webhooks & Infrastructure (Clarification)

Template complaints often cite “Observed webhook URL” to imply unlawful content. This section clarifies what that means.

Webhook endpoints

• A webhook is a technical endpoint used to receive update payloads from an integration (e.g., a messaging platform).
• A webhook URL does not itself demonstrate unlawful content and often does not expose user-facing content.
• Actionable complaints must include demonstrable harmful output, not just an endpoint.

Proxies and DDoS protection

• We may use security services (e.g., reverse proxy) to prevent DDoS and abuse.
• This is a protective measure for service continuity and does not indicate wrongdoing.

8) Security & Reliability (Business Safety Enhancements)

This section lists security practices that improve provider confidence and reduce false-positive enforcement. It also improves business resilience against report-bombing and technical abuse.

Operational measures that reduce abuse risk

• Single accountable mailbox: all abuse/privacy/provider communications go to abuse-sherlockosint@proton.me.
• Evidence-first handling: we request URL/ID + timestamp + proof; we can take targeted action when specific results are provided.
• Rapid provider routing: providers should include PROVIDER in the subject line to prioritize triage.

Recommended (high-value) additions for universality

Security incident & vulnerability reporting

9) FAQ