Privacy policy

How a search works

You type one query into the universal search box. DuckINT classifies it as a username, email address, domain, IP address, URL, Bluesky DID or Discord ID — or an explicit DNS query such as MX example.com. The classifier runs in your browser to preview the detected types and again on the server, which then runs every applicable capability (one documented provider operation) in parallel and streams the results back.

Each capability receives only the normalized value it needs, never your DuckINT identity. All provider requests are made by the DuckINT server, so providers see the server — not your browser or your IP address. Provider API keys stay on the server and never reach the browser.

Capabilities and the providers they contact

Only capabilities that apply to the detected query types run: an email address, for example, goes only to the breach and leak-index sources, to GitHub (to find accounts linked to it) and, for its domain part, to DNS. Discord IDs are decoded on the DuckINT server itself, from the creation time embedded in the ID; no provider is contacted for them. Discord avatars and banners shown in results are fetched by the DuckINT server from Discord's image CDN and passed on to you, so your browser never contacts Discord. Providers process requests under their own terms and privacy policies. The sources status in the top bar shows what is enabled on this deployment right now.

URLs

When you search a URL, its query string (everything after ?) and fragment are removed before any lookup: they are never sent to the website or to any provider, and never stored. The only exception is a Hacker News profile link, whose id is read as the username before the rest is discarded. Usernames or passwords embedded in a URL are ignored. Only https on the default port is fetched, and private or reserved addresses are never fetched.

Short public-data cache

To spare providers, an identical lookup of public data — DNS, RDAP, profiles, repositories, certificate logs, InternetDB, IP geolocation — may be answered from an in-memory server cache for 2 to 30 minutes, depending on the capability. Such results are marked cached. The cache is partitioned per searcher (your account), so a cached answer can only come from your own earlier lookup and never reveals what anyone else searched. It lives only in server memory, is cleared when the server restarts, and is never used for breach checks or website fetches.

What we store

• Accounts. Your username, your e-mail address (used only for password resets), the time you accepted the terms, and a one-way Argon2id hash of your password. The password itself is never stored, logged or shown to anyone — administrators included.
• Sessions. A hashed session token, timestamps and your browser's user agent, so you can stay signed in and sign out.
• Daily usage and security records. A per-day counter of your successful searches (to enforce the daily allowance), account notifications, single-use password reset tokens (stored only as hashes), and an audit log of sign-ins, account changes and administrative actions, including a coarse network key (IPv4 address or IPv6 /64) for security events. The network key an account was created from is also kept with the account, so that only one account can be registered per network. For abuse and support review, administrators and the owner can see an account's registration network key, the network keys of its recent sign-ins, the browser user agent of its active sessions, and other accounts created from the same network; every such view is recorded in the audit log.
• Search records. Every search is recorded with its normalized query (URL query strings already removed), the detected query types, the outcome, timing, and each provider's status and result count — not the results and not raw provider responses. These records enforce quotas, drive provider health and abuse controls and, for registered users, form your search history, which you can delete entry by entry or clear entirely. Administrators and the owner can view an account's search history for abuse and support review; every such view is recorded in the audit log.
• Saved results (registered users). When you save a result, DuckINT stores that normalized result (title, fields and sources), the query it came from and any note you add, until you delete it.
• Provider health. Success and failure counts per capability over the last 24 hours, aggregated from the search records above.

What we do not do

We do not require a phone number or real identity, we use your e-mail address only for password resets, and we do not use invasive browser fingerprinting. We do not log API keys, credentials, session tokens or raw provider payloads. The web app never puts your queries or results into page URLs, browser storage or console logs: the recent-queries list and the raw provider responses shown in the inspector live only in the open tab's memory and disappear when you close or reload it.

Daily allowance

Searching requires an account. Each account's daily allowance is counted on the server per account, so it does not depend on cookies, browsers or devices.

Retention

Search records are purged after the retention window set by the operator (30 days by default). Saved results are kept until you delete them. Expired sessions, stale rate-limit records and expired reset tokens are purged by periodic maintenance, and cache entries expire within minutes.