Privacy
We see the question. We do not see who asked it.
This page has two parts: first, how the product handles data — the part that matters for your outsourcing review. Then the privacy notice for this website.
Part 1 — How the product handles data
The starting point is an uncomfortable observation: the mere fact that you are screening a particular name is confidential information. It can reveal a customer relationship, an acquisition target or an internal suspicion. The usual remedy is a promise in a contract. We consider that insufficient, and have removed the linkage from the method instead.
What the service sees
- The name screened and the country — both are required to carry out the research.
- The content of the articles retrieved and assessed during the research.
- Operational data such as the time, duration and result state of a job.
- The number of queries a customer draws per billing period.
What the service does not see
- Which customer submitted a given query. A redeemed token cannot be attributed to its issuance.
- Which specific tokens were issued to a given customer — they are signed in blinded form.
- Why you are screening a name. No case reference, matter number or internal trigger is submitted or requested.
- Your internal users. There are no per-handler accounts, because none are needed.
The method
Why the attribution is not possible.
The mechanism is RSA blind signatures per RFC 9474 — an established, standardised scheme, not something we invented. Four steps:
- 01
Generate
Your system generates the tokens itself
Every token starts as a random value created on your side, which never leaves your environment in that form. It contains no customer number, no counter and no structure — any structure would reintroduce attributability.
- 02
Blind
The value is blinded before it is sent
Your system mathematically conceals the value before it reaches us. What we receive is a string from which the eventual token cannot be derived.
- 03
Sign
We sign without knowing the content
The server signs the blinded value. It never sees what it is actually signing, and stores neither the transmitted value nor the resulting signature — it merely counts how many tokens you drew in the period.
- 04
Redeem
At redemption it only verifies its own signature
Your system removes the blinding and holds a valid token. On a query, the server verifies that the signature is its own — which is all it can establish. To prevent reuse, a hash of the token is recorded; that record contains neither the token itself nor any reference to you or to the content of the query.
What remains visible regardless
A privacy claim is worth only as much as what it concedes. These residual signals remain — they are inherent to the method, and none of them concerns the content of your queries.
| Visible | Why | What does not follow from it |
|---|---|---|
| That you are a customer | There is a contract and a billing relationship. | Which names you screened. |
| Queries drawn per period | The allowance has to be enforced. | Which tokens those were, or when they were redeemed. |
| The content of an individual query | Research is impossible without a name and a country. | Who it came from. |
| Network metadata of the connection | Every HTTP connection has a peer, and it is visible for as long as the connection is open. | A stored record of it. The API access log is formatted to hold no client address and no forwarded-for chain, so there is no connection history left to line up against a redeemed token afterwards. Diagnostic error entries are the one exception and are short-lived. For stricter separation still, reach the service through your own egress point or operate it in your own data centre. |
The short version: we see what was searched for, and we see how many queries you draw. We cannot connect the two.
Processors involved
The research is not performed entirely in house. Omitting that would omit the single most important fact for your outsourcing review.
Search provider
The generated query — and with it the screened name in its variants — is transmitted to a search service. That service sees the query, not your identity.
Language model provider
Article texts and the screened name are transmitted to a language model provider for analysis. Again: the provider sees the content, not who the research is for.
Websites retrieved
Articles found are fetched for full-text analysis. The websites concerned see a request from our infrastructure, not from yours.
Operation in your own data centre
If your outsourcing policy does not permit these transfers, deployment in your own environment is the intended route — connections to the services named then originate from your infrastructure under your contracts. Talk to us about it; the full list of processors with legal bases and locations is available for review.
Storage and deletion
Results
Screening results are cached for an agreed period so that a repeat of the same research can be answered immediately. After that they are discarded. The period is configurable and can be set to zero.
Redeemed tokens
What is stored is exclusively a hash per token, to prevent reuse — not the token, not the customer, not the content of the query. When an issuance period lapses, the associated records are removed entirely.
Expiry by key rotation
Tokens are bound to the issuance period in which they were signed. When a period is no longer honoured, every token belonging to it becomes invalid — with no per-token expiry date and no sweep job.
Failed jobs
Unanswerable jobs are stored for fault analysis and removed once assessed. That store holds the query parameters but no customer reference.
Access logs
The access log of the query interface records what was requested, how it ended and how long it took — deliberately without the client address and without any forwarded-for chain, and the address is not passed on to the application either. There is therefore no connection record that could be correlated with a redeemed token later. Diagnostic entries written when something actually fails can still contain an address, and are kept only briefly.
Part 2 — Privacy notice for this website
This website is an information site with no user accounts, no contact form and no analytics. One single page is the exception: under “Try it live” you can trigger a real query. Unless you do, nothing you read here goes back to us.
Controller
The controller within the meaning of the General Data Protection Regulation is DemandFlow GmbH, Friedrichstraße 11, 68723 Plankstadt, Deutschland. Contact for data protection matters: datenschutz@negative-news-search.com. Data protection officer: not appointed.
Server log files
When you access this website, the hosting provider (IONOS SE, Elgendorfer Str. 57, 56410 Montabaur, Germany, data centre in Karlsruhe (Germany)) processes technically necessary connection data: IP address, time, address requested, volume transferred, referring address and browser identifier. The legal basis is Art. 6(1)(f) GDPR; the legitimate interest lies in secure and uninterrupted operation. The data is deleted after a short period and is not combined with other sources. Excepted are the “Try it live” page and the queries it triggers — no address is logged there; see below.
No cookies, no analytics
This website sets no cookies, uses no browser local storage, embeds no analytics or tracking services, and loads no external fonts, scripts or third-party content. There is consequently no consent banner either — there would be nothing to consent to. That holds for the live demo as well: it pulls in nothing from third parties and stores nothing in your browser.
The exception: “Try it live”
Every other page is static — it serves text and images, and nothing goes back to us. “Try it live” is the only page where that differs, and even there only at the moment you actually submit the form. Merely opening or filling in the page transmits nothing. On submission, what is transmitted is exactly what the form holds: the name screened, the country, the report language you want and the token you paste in. Your browser talks solely to negative-news-search.com; the request is passed to the service server-side, and no connection to another host is opened. The research itself then runs like any other query — with the processors named in Part 1.
The demo builds no profile either
The same commitment applies to this route as to the API: the access log for the demo page and the calls it makes is formatted to hold no client address, and the address is not passed on to the service either. Above all, though, the demo changes nothing about the mechanism in Part 1 — the token you paste in was blind-signed, so we do not know who it was issued to. A query made through the demo is therefore no more attributable to a customer than one made through the API. Who searched for what cannot be answered here either, and not because we decline to release the answer, but because it is never created anywhere. An order to hand it over would consequently come to nothing.
What we concede
Two limitations we name explicitly, because they remain. First: diagnostic entries written when something actually fails can contain an address; they are kept only briefly. Second: the remaining pages of this website are logged normally (see “Server log files”). A page view shortly before a query therefore does not fully rule out an approximation by timing. If you need strict separation, call the service through the API from your own environment rather than through this demo — or operate it in your own data centre.
Getting in touch
If you write to us by email, we process your details in order to handle the enquiry and any follow-up questions. The legal basis is Art. 6(1)(b) GDPR for contract-related enquiries and Art. 6(1)(f) GDPR otherwise. We delete the correspondence once it is no longer needed and no statutory retention obligations apply.
Your rights
You have the right of access (Art. 15), rectification (Art. 16), erasure (Art. 17), restriction of processing (Art. 18), data portability (Art. 20) and the right to object to processing based on legitimate interests (Art. 21 GDPR). To exercise them, contact datenschutz@negative-news-search.com. Independently of this, you have the right to lodge a complaint with a supervisory authority, for example the Landesbeauftragter für den Datenschutz und die Informationsfreiheit Baden-Württemberg (LfDI), Lautenschlagerstraße 20, 70173 Stuttgart.
Version
This privacy notice is dated 14 August 2026. We update it when the processing changes.
Running an outsourcing review?
We provide the documentation for it: the processing overview, the processor list with locations, the operating concept and a description of the token method.