Our posture on privacy
NOSIBLE is built around public written content, not personal profiles. Public availability does not remove privacy rights. NOSIBLE minimizes personal data in the index, keeps operational logs limited, gives customers private-key controls, and provides routes for objections, delisting, and removal (ICO).
- NOSIBLE indexes public written sources, not personal profiles or identity datasets.
- The search index is not designed to hold personal data or sensitive records.
- The crawler excludes PII, unsafe domains, adult sites, social platforms, and marketplaces.
- Website verification checks privacy and terms links for ownership, legal context, and rights routes.
- Public availability does not remove privacy rights under GDPR Article 6 and ICO guidance.
- Usage logs run for 24 hours. Request logs can be disabled with private API keys.
- Private API keys can be issued upfront or applied retroactively to existing keys.
- Request logs are encrypted with Fernet and keys are stored in Google Secret Manager.
- Websites and individuals can request removal, objection, erasure, or delisting under GDPR Article 17.
Privacy starts with what does not enter the index
NOSIBLE does not index personally identifiable information and does not hold personal data in the search index. The crawler also excludes unsafe domains, inherently pornographic sites, social platforms, marketplaces, and paywalled content. Privacy risk is reduced before content reaches the core product.
When public-source text still contains personal data, privacy law still applies. NOSIBLE relies on legitimate interests, necessity, minimization, public transparency, and case-by-case handling of objections or removal requests, consistent with GDPR Article 6, GDPR Article 14, ICO guidance, CNIL web-scraping guidance, and EDPB Opinion 28/2024.
Logs are separated by purpose and retention
| Area | NOSIBLE position |
|---|---|
| Search index | The index is for public written content and source metadata. It is not designed to hold personal data. |
| Website legal pages | NOSIBLE scans homepage links for privacy policies and terms of service so the source can be reviewed against public legal context. |
| Legal basis | Public-source processing is assessed through legitimate interests, necessity, minimization, and balancing under GDPR Article 6. |
| Transparency | Web-scale indirect collection relies on public notice and safeguards under GDPR Article 14 and the Article 14(5)(b) disproportionate-effort framework. |
| Usage logs | Usage logs are always enabled for rate limits and abuse prevention. They are retained for 24 hours. |
| Request logs | Request logs support search-quality improvement. They are stored per API key and can be disabled. |
| Private API keys | Private keys can be created upfront or applied to an existing key. Once private mode is enabled, request logging cannot be re-enabled for that key. |
| Deletion timing | When a key is made private, associated request logs are destroyed within one business day. |
| Access controls | Request logs are encrypted per API key and accessible only to a small number of authorized personnel under NDA. |
Source owners can ask to be removed from the index
If a website asks to be forgotten, NOSIBLE removes its data from the index and notifies affected paying customers. Individuals can also raise privacy objections or delisting requests where search results surface information about them. Those requests require a case-by-case balance between privacy, accuracy, source context, public interest, and the right to information under GDPR Article 17, Google Spain, GC and Others v. CNIL, Google LLC v. CNIL, and NT1 and NT2 v. Google.
Common privacy questions
Does NOSIBLE store personal data in the index?
No. NOSIBLE does not index personally identifiable information and does not hold personal data in the search index. The crawler is focused on public written source material, and pages that create personal-data risk are outside the intended search corpus. Privacy risk is reduced before content reaches the product.
Does public availability remove privacy rights?
No. Public availability is relevant to reasonable expectations, but it does not switch off privacy law. ICO guidance is explicit that personal data can remain protected even when it is publicly available (ICO). NOSIBLE handles that through minimization, source exclusions, public privacy information, and a route for objections, delisting, or removal requests.
What lawful basis applies to public-source processing?
For UK and EU privacy analysis, the relevant basis is legitimate interests under GDPR Article 6(1)(f). That requires a purpose, necessity, and balancing assessment. KNLTB v. Autoriteit Persoonsgegevens confirms that commercial interests can qualify, subject to strict necessity and balancing. NOSIBLE limits processing through source context, exclusions, minimization, and rights handling.
Why does NOSIBLE look for privacy policies and terms of service?
Privacy policies and terms help identify who operates a website, what jurisdiction may apply, and what public rights routes the source owner makes available. NOSIBLE uses homepage link scanning and strict URL matching to find those documents. They support source review, legal-entity extraction, jurisdiction checks, and case-by-case handling of removal or privacy objections.
Why is unsafe or adult content mentioned on the privacy page?
Those exclusions reduce data-handling risk before content enters the product. NOSIBLE checks domains with Google Safe Browsing and excludes inherently pornographic websites using known unsafe or NSFW lists. CNIL guidance also treats sensitivity-heavy sources as higher risk in scraping assessments (CNIL). These categories add privacy and safety risk without improving the search corpus.
What is the difference between usage logs and request logs?
Usage logs support rate limits and abuse prevention. They are always enabled and retained for 24 hours. Request logs are different. They record API requests for search-quality improvement and are stored on a per-API-key basis. A customer can opt out of request logging by using a private API key, but usage logs remain necessary to operate the service safely.
Can request logging be turned off?
Yes. NOSIBLE can issue a private API key upfront or make an existing API key private retroactively. Once a key becomes private, request logging cannot be re-enabled for that key. NOSIBLE confirms by email when the key is private and the associated request logs have been destroyed within one business day.
How do private API keys differ from normal API keys?
Private API keys use different prefixes and do not record request logs against requests made with that key. They are best created before a customer starts sending sensitive queries. Usage logs still remain separate because the service needs them for rate limits and abuse prevention.
Can request logs be turned back on after a key becomes private?
No. Once request logging is disabled for an API key, it cannot be re-enabled for that key. That one-way switch is useful because it avoids ambiguity. A customer knows private mode is durable, and NOSIBLE knows future requests from that key stay private.
How fast are request logs deleted after private mode is enabled?
Associated request logs are destroyed within one business day after the key is made private. That deletion applies to request logs for that API key. It does not turn off usage logs, because usage logs are still needed for rate-limit enforcement, abuse prevention, service reliability, and basic operational safety.
How are request logs protected?
Request logs are encrypted at rest on a per-API-key basis using Fernet. That means each API key has its own encryption key. Those keys are stored in Google Secret Manager. Request logs are accessible only to a small number of authorized personnel who have signed strict NDA agreements.
Can NOSIBLE provide anonymous API keys?
Yes. NOSIBLE can generate anonymous keys with no logging or tracking capabilities. Private API keys can also be created upfront with different prefixes and no request logs recorded against requests made with that key. Customers with sensitive query workflows can start with private logging disabled from day one.
How should customers request private logging?
Customers request private logging from the email address associated with the API key. NOSIBLE then makes the key private, destroys the associated request logs within one business day, and confirms by email. The request stays tied to the verified key owner.
Who can view API request logs?
Only a small number of authorized personnel can access API request logs. Those personnel are bound by strict NDA agreements. Encryption protects the records at rest, while access controls, limited internal permissions, and NDAs limit who can inspect them operationally.
Can a website ask to be forgotten?
Yes. If a previously indexed website asks to be forgotten, NOSIBLE removes its data from the index and notifies affected paying customers of the change. The process gives source owners a direct control path when they do not want their site indexed or surfaced through NOSIBLE search results, while keeping the operational change visible to customers who rely on that source.
Can an individual ask NOSIBLE to delist a result about them?
Yes. A person can raise an objection, erasure request, or delisting request when search results surface information about them. Search-engine privacy law requires a balance between privacy, accuracy, age of the information, public role, source context, and the public interest in access (Google Spain; GC and Others v. CNIL; NT1 and NT2).
How does NOSIBLE handle transparency when data comes from third-party sources?
NOSIBLE collects from published sources rather than directly from every person named in those sources. Individual notice at web scale can be impossible or disproportionate, but GDPR Article 14 still requires public information and safeguards. The Article 29 Working Party transparency guidelines require a documented analysis and public notice where Article 14(5)(b) is used.
What happens to delivery files and customer outputs?
Fast Search returns results in the HTTP response. Bulk Search returns a link to an encrypted JSON file when the job is ready. Crawl Feed publishes matching results to a private pub/sub channel, and Search Feed delivers results to S3 or a customer-selected storage system. Delivery setup controls customer-side access, retention, and handling.
What privacy issues should customers consider with delivery files?
Customers review where result files land, who can access that storage, and how long downstream systems retain the outputs. NOSIBLE can return results in an HTTP response, encrypted JSON file, private Pub/Sub channel, S3 bucket, or customer-selected storage system.