Privacy Policy

Overview

This Privacy Policy explains what information is collected and why it is collected. Account changes, exports, and deletions are currently handled by emailing info@lifub.com — there is no self-serve account dashboard yet.

Depending on your use of the Lifub website and its products, two types of information are collected: personal data and non-personal data.

Controller (Art. 4 No. 7, Art. 13(1)(a) GDPR)

The controller operates as a natural person under the Kleinunternehmer scheme (§ 19 UStG). No Data Protection Officer is mandatory because § 38 BDSG only requires one where 20 or more persons are regularly engaged in personal-data processing. The primary contact for data-protection enquiries is info@lifub.com.

Legal bases for processing (Art. 6 GDPR)

Art. 6(1)(b) — Contract performance

Account creation, API key issuance, delivery of purchased services, requested Monitoring email verification and alerts, and pre-contractual communication initiated by you (e.g. emailing info@lifub.com to request a service).

Art. 6(1)(f) — Legitimate interest

IT security via server logs (Recital 49 GDPR), anti-abuse rate limiting on anonymous API traffic, basic aggregated usage statistics without user-level tracking, and bot / AI-agent recognition (Analytics) from server-side request fingerprints for fraud / abuse prevention (Recital 47 GDPR).

Art. 6(1)(c) — Legal obligation

Retention of invoicing / accounting records for 10 years per § 147 AO.

Art. 6(1)(a) — Consent

Only where explicitly collected (e.g. opt-in to non-essential communication). None is required or requested for using Lifub products today.

Retention periods

• Account / key-issuance emails: for the duration of the service relationship + 30 days.
• Server access logs (including IP addresses): 30 days, then auto-deleted. BayLDA recognises 30 days for IT-security legitimate interest.
• API request log (metering): retained for the duration of your service relationship. Within 30 days of the relationship ending (key revocation or written request), all rows tied to your API key are deleted. Aggregated, non-identifying counts may be retained for billing reconciliation. This matches the deletion timeline in the DPA § 4.
• Site Search crawled index & search logs: duration of the customer relationship + 30 days after termination.
• Analytics visit analytics (per-visit verdict + request fingerprints incl. the hashed IP, JA3 / JA4, TLS cipher, User-Agent): kept on a rolling 365-day default TTL (configurable per site), and in any case deleted within 30 days of the service relationship ending. The raw IP is never stored — only the pseudonymous ha5h:… hash. Aggregated, non-identifying counts may be retained for reporting.
• Monitoring notification email: a pending address and hashed verification UUID are kept in Monitoring state for at most 15 minutes. After successful verification, the address is retained while its anonymous Monitoring site remains active and expires no later than 90 days after activity stops; removing it in the Monitoring gadget deletes the pending and verified address from Monitoring state immediately. Previously delivered messages remain subject to the sender’s and recipient’s mail-retention settings.
• Site Audit reports and snapshots: every completed browser audit is stored server-side for 90 days so its unguessable bearer report link works. Saving it as a labelled snapshot in the browser does not create another server copy: the label and local snapshot history remain in that browser until cleared or displaced from its 50-entry history, while the underlying report keeps its original 90-day expiry. Server-side API or MCP snapshots use the same 90-day TTL. A direct API or MCP audit requested without sharing or snapshot storage is returned once and is not stored as a report. Stored reports retain the target and final URLs, status and classifications, selected response headers, captured-size and hash evidence, scores, findings, bounded page, TLS, and SEO facts, response timings, speed evidence, and public field-performance data. They do not retain response bodies, request headers, or cookies. Anyone holding the report UUID can read it until it expires.
• Operator administration audit history: capped at 1,000 entries; the Redis list expires 365 days after the last administrative write. Entries record the operator source address, timestamp, action, target or recipient information, and bounded fulfillment detail.
• Site Audit voucher fulfillment records: provider name, purchase-reference UUID, transaction and voucher fingerprints, remaining balance, and issuance or revocation time currently have no automatic expiry because they preserve the outstanding bearer entitlement and prevent duplicate fulfillment. They remain until operator deletion, subject to applicable accounting, dispute-resolution, and legal-retention duties.
• Outbound email awaiting retry: when a receiving mail server refuses a message temporarily (greylisting is the common case), we hold that message — recipient address, subject and full body — in a queue on our own EU infrastructure and retry it on a fixed schedule spanning a little over 5 hours. It is deleted as soon as it is delivered, or when the schedule is exhausted, whichever comes first. Because the body is held whole, a queued Monitoring verification message contains its verification UUID, a queued Site Search setup message contains its Site Secret, and a queued Site Audit voucher-delivery message contains its bearer voucher for that period. No third party holds the queue.
• Suppressed recipient addresses: when a receiving mail server rejects an address permanently as nonexistent or disabled, we record that address for 30 days and send it nothing further. Keeping it is what stops us mailing a dead mailbox repeatedly; it expires automatically, and no message content is retained with it.
• Mail received by the fallback mail exchanger: moved to our own mail server and deleted from the Yandex 360 mailbox within 7 days of arrival.
• Invoicing / accounting records: 10 years (§ 147 AO).
• Aggregated, anonymised usage statistics: retained indefinitely.

Recipients / processors

• OVH SAS (2 rue Kellermann, 59100 Roubaix, France) — infrastructure hosting for our primary server (EU). A GDPR-compliant data processing agreement (Art. 28) is in place.
• netcup GmbH (Daimlerstraße 25, 76185 Karlsruhe, Germany) — infrastructure hosting for our secondary server (EU). It holds a read-only replica of our data so the service survives the loss of the primary server; its storage is encrypted at rest on the same terms. A GDPR-compliant data processing agreement (Art. 28) is in place.
• Applicable Stripe entities identified in Checkout and Stripe's Privacy Center — primary hosted payment processing. The responsible Stripe entity depends on location, payment service, and processing role. For Site Audit, Stripe receives the purchaser's delivery email, business-buyer confirmation, purchase reference, and payment details needed to complete the one-time checkout. Card number and CVC are submitted directly to Stripe and are never stored by Lifub.
• Revolut — fallback payment processing only when separately arranged by the operator. Raw card or account credentials are submitted directly to the Revolut entity identified in the hosted checkout or receipt. Lifub also processes the voucher-delivery email address and the fulfillment and accounting metadata described below.
• DB-IP (by 2VIA S.A.) — DB-IP Lite geolocation database (CC BY 4.0). IP addresses are looked up locally against a database hosted by us; no end-user IP is sent to DB-IP. Published with required attribution.
• Yandex 360, provided by Air Smart Advertising Solutions FZ-LLC — fallback mail exchanger for lifub.com. Lifub’s mailboxes live on our own OVH-hosted server, which receives mail addressed to Lifub and sends our messages directly to the recipient domain’s mail exchanger — no third party sits in that primary path. Yandex receives a message addressed to lifub.com only when our own mail server is unreachable or temporarily refuses it, and holds it in a Yandex mailbox; we move such mail to our own server and delete it at Yandex within 7 days. Yandex is also authorised to send mail on behalf of lifub.com.
• Google LLC (Chrome UX Report API) — source of public, aggregated real-user performance data for Site Audit, used only when real-user field data is enabled. Google receives the audited page's URL without its query string or fragment, and if needed its origin. No visitor IP address, cookie, request header, or other identifier of the person requesting the audit is sent. Google acts as an independent source of public data for this lookup, not as our processor.

A processor may use infrastructure or subprocessors outside the EEA. Where an international transfer is unavoidable, we rely on Art. 46 GDPR safeguards (Standard Contractual Clauses).

Site Audit reports

Site Audit fetches and transiently analyzes the public page selected by the user. Every completed browser report is published under an unguessable bearer UUID and kept for 90 days. Saving a browser snapshot adds its label only to local browser history; it does not make another server copy or extend the underlying report's expiry. Server-side API or MCP snapshots use the same 90-day TTL. A direct API or MCP audit requested without sharing or snapshot storage is not retained as a report. Stored reports contain bounded technical evidence, not the fetched response body, request headers, or cookies. Recent-site and browser-created snapshot-label history stays in the user's browser and is not sent to Lifub. When real-user field data is enabled, the server sends the audited page's URL without its query string or fragment, and if needed its origin, to Google LLC's Chrome UX Report API to retrieve public, aggregated Core Web Vitals data. No visitor IP address, cookie, request header, or other identifier of the person requesting the audit is sent.

Monitoring email notifications

Monitoring works without an account or email address. If you explicitly enable email notifications, we store the address under your unguessable siteId and send a one-time UUID to prove that you control the mailbox. Only a SHA-256 hash of that UUID is stored in Monitoring state, it expires after 15 minutes, and successful verification consumes it. The raw UUID necessarily appears in the delivered verification message and may remain in sender or recipient mail systems under their retention settings. The verified address is used only for requested incident, recovery, and verification messages — never marketing. You can remove pending or verified Monitoring configuration at any time in the Monitoring gadget.

How our email is delivered

Every message Lifub sends — Monitoring incident, recovery and verification messages, the Site Search setup-information message, and Site Audit voucher delivery — is delivered by our own EU-hosted server straight to your mail provider. No third-party sending service or SMTP relay sits in between. Your provider necessarily receives the message and processes it as your mail host rather than ours.

A Site Audit voucher-delivery message carries a bearer credential. Anyone who reads that voucher can spend its remaining paid audits. Keep it private; retrying fulfillment for the same settled provider transaction returns the same voucher rather than another balance.

The Site Search setup-information message carries a credential on purpose. It is sent to the address you enter in the Getting Started gadget, which is labelled accordingly, and it contains your Site ID and your Site Secret — the value that authorizes crawls, page writes and profile changes for that index. Treat it like a password: we cannot recover it for you, and anyone who reads that message controls the index.

Two mechanisms exist so that a delivery problem neither loses your message nor turns us into a source of junk mail, and both retain data for a bounded period — see Retention periods above. A message a receiver refuses temporarily is held whole and retried for a little over 5 hours. An address a receiver refuses permanently, as nonexistent, is recorded for 30 days and sent nothing further; if that was a mistake, tell us and we will clear the entry immediately.

Your rights (Art. 15–22 GDPR)

• Access (Art. 15) — a copy of the personal data we hold about you.
• Rectification (Art. 16) — correction of inaccurate data.
• Erasure / "right to be forgotten" (Art. 17).
• Restriction of processing (Art. 18).
• Data portability (Art. 20) — structured, machine-readable export.
• Objection (Art. 21) — in particular to processing based on legitimate interest.
• Revoke consent (Art. 7(3)) — where consent was the legal basis.
• No automated individual decision-making (Art. 22) — we do not subject you to automated decisions with legal effect.

To exercise any of these rights, email info@lifub.com. We respond within one month (Art. 12(3) GDPR). We may verify your identity by requiring the request to come from the email address registered with the service.

Supervisory authority

You have the right to lodge a complaint with a supervisory authority (Art. 77 GDPR). The authority competent for this service is:

Types of Data

When Data is Collected

1. When you integrate Page Finder into your website
2. When you log in to access your Page Finder dashboard
3. When you optionally enter an address for Monitoring email notifications
4. When you simply browse this website

Page Finder Integration — What Data is Collected from Your Users?

When we process your visitors' data on your behalf as a data processor under the Data Processing Agreement, we permanently ensure that our operations are executed in accordance with GDPR requirements. To make sure your privacy is protected:

• Technical and organizational measures taken by our infrastructure provider (ISO/IEC 27001 certified)
• Quality compliance certificate issued by the German certification body TÜV Rheinland
• Technical and organizational measures taken by us as a contractor

HTTPS and API traffic uses TLS 1.2 or later; direct email uses STARTTLS when the receiving server offers it.
What we store about your end users: their search query (Site Search) or their IP address (IP Intelligence API) for the duration of the service relationship + 30 days, then deleted. We do not store names, emails, or other contact data of your end users.

Analytics — What Data is Collected from Your Visitors?

Analytics is a web-analytics tag whose purpose is bot and AI-agent recognition. When you embed it we act as your data processor under the Data Processing Agreement. By default Analytics sets no cookies and assigns no cross-site identifier — it never follows a visitor across different websites. A site owner may optionally enable a single first-party, same-site cookie to tell new visitors from returning ones (see Returning-visitor cookie below); it is off unless the owner turns it on. To tell real humans from bots, Analytics processes and stores server-side request fingerprints for each visit:

• IP address — used at the moment of the visit to derive the network owner (ASN), country and city and the datacenter / proxy-bot signal, then discarded and kept only as a pseudonymous, irreversible hash (an IPv6-shaped ha5h:… token, peppered server-side). The raw IP address is not retained.
• TLS fingerprints (JA3 / JA4) and the negotiated TLS cipher — these identify the client's TLS stack, a strong automation tell.
• HTTP protocol version and the User-Agent header.
• Page path and the external referrer host (where the visitor came from).
• For visitors that run JavaScript, a small set of browser runtime signals (e.g. whether automation is detected, language count, hardware concurrency, plugin count).

The IP address is personal data under the GDPR, and the pseudonymous hash that replaces it is treated as personal data too — a hash is pseudonymisation, not anonymisation. We process these fingerprints on the basis of Art. 6(1)(f) legitimate interest — fraud and abuse prevention (Recital 47), which is the core function you embed Analytics for. The data is scoped to your individual site, used only to compute each visit's human / bot verdict and your aggregated analytics, and is never used for cross-site profiling, advertising, or sold to anyone. Retention follows the "Retention periods" section above. We store no names, emails, or other contact details of your visitors.

Returning-visitor cookie (optional, off by default)

A site owner may switch on a single first-party cookie (loxal_vid) so Analytics can distinguish new from returning visitors. It holds only a random per-browser id, is same-site only (never read on any other website), is no advertising or cross-site identifier, and expires after ~180 days. Because it is not strictly necessary, it is written only with the visitor's consent — obtained either through Analytics' own built-in consent banner (with an equally-prominent Accept / Reject) or through the site owner's own consent platform. With the cookie off (the default) Analytics is fully cookieless.

What we collect when you request access

Access that requires approval is granted manually by email. When you email info@lifub.com to request a Free or Pro API key (or a managed Site Search install), we collect only what you supply:

• Email address
• Name (optional)
• Domain (Page Finder only)
• Tier (Free / Pro)

How we use this information

1. To issue an API key and reply to you.
2. To understand how the service is being used so we can prioritise.
3. To send service messages (e.g. key revocation notice). We do NOT send marketing emails — there's no list to be on.

To update or delete your record, email info@lifub.com. There is no self-serve dashboard / "Profile settings" UI yet — the current operating scale does not justify building one. We respond within one month per Art. 12(3) GDPR.

Vynx full browser extension build

Vynx combines Claude and GitHub Copilot chat, proofreading, a Browser Agent, an optional MCP Bridge and local page tools. The directly downloadable full build is described at Vynx. It includes no analytics or advertising system that reports your browsing history. Local diagnostics and the optional bridge have the separate boundaries described below.

What the extension reads

• Chosen page content and browser state - chat, the Browser Agent and the MCP Bridge can read the pages and tabs you select, and act on them. Local dark-mode, cookie-banner rejection, element hiding and other page tools inspect supported pages according to their settings.
• Signed-in provider sessions - provider requests use your existing browser session rather than requiring a new Lifub account or an API key. Provider access can include cookies, a short-lived Copilot bearer token, account model availability and usage information.
• Request and page diagnostics - local tools observe bounded request metadata; HAR and request-body capture require explicit capture. These tools are not exposed through the remote MCP action catalogue.

What leaves your device, and to whom

Chat, bundled skills and Browser Agent requests send your prompts and selected page context to Anthropic or GitHub, according to your selected sending provider. Perplexity supports proofreading and receives the selected proofreading text. OpenAI integration reads usage/reset information; it does not send chat prompts. Your provider's privacy policy and account terms govern those requests. Files, screenshots or page content you direct a local tool to upload go to the destination you select.

Enabling the MCP Bridge connects to its configured server, normally api.lifub.com. Commands, results and ordinary selected-page content pass through that server to the connected client. URLs and ordinary form values can be included. Structured DOM results withhold recognized credential field values and the bridge's own secret. Screenshots and PDF output capture the rendered page and can transmit visible sensitive information through the bridge server to the connected client; those captures do not mask every sensitive field. This is not a general guarantee that a page is free of sensitive content. Raw cookies, storage, traffic, provider-session requests and arbitrary JavaScript remain local-only. Keep the bridge Session ID private: it grants access to that browser profile.

The German-English dictionary is downloaded from www.lifub.com on first use and cached locally. Normal HTTPS connection metadata reaches the recipient of each request, including Lifub for bridge and dictionary requests; the general server logging policy above applies.

What stays on your device

• Settings, provider and model choices, and request-header rules.
• Saved chat history, proofreading originals and replies, retained archives, and the newest 10 Browser Agent sessions. Settings provides a saved-chat export; it excludes provider credentials and bridge enrollment secrets.
• Saved popup and Browser Agent drafts, including exact prompt text, provider, model, skill, effort and captured page or browser context. Composer, queued and interrupted-request records stay in the same profile for explicit recovery; recovery does not send them automatically. Discard removes the selected draft, not all retained drafts.
• Bridge enrollment/configuration, bounded bridge journals and diagnostics, cookie-dismissal aggregate diagnostics, and the dictionary cache. Local capture buffers are bounded and memory-only.

Saved drafts have no timed expiry or automatic eviction. An empty composer with no selected skill, or an empty Perplexity composer, is removed when its view closes. Successful sends retire their own recovery records only after completion is durably recorded; restoring a copy leaves the original saved record in place. There is no draft-only clear-all control. To remove recovered drafts, use Discard this saved draft for each record in the popup and Browser Agent. Drafts held by another open view are unavailable for recovery until that view closes. Finish or stop active work and clear current composers before closing views, then discard the remaining recovered records. Discarding a draft does not delete saved history or undo a request.

Draft storage is not encrypted by Vynx and is not a credentials vault. Prompts and captured context can contain sensitive information you enter or select. Saving a draft does not upload it; sending it uses the provider and bridge boundaries above. Local data belongs to the browser profile. Exporting a journal or diagnostic bundle creates a file under your control; review it before sharing. Logical deletion is not secure erasure: browser databases, filesystem snapshots and backups can retain prior bytes.

Vynx no longer contains a password vault. That surface became the separate Keyring extension on 28 August 2026, and Vynx now ships no vault code and no clipboard access on any platform.

Permissions that look alarming, and why they exist

• Broad host access, scripting and cookies - required for chosen-page tools and signed-in provider access. Local page interventions follow their own settings rather than a chat run.
• Tabs, tab groups, side panel, storage and alarms - support extension views, history, browser actions, scheduling and the optional bridge.
• Web request and declarative network rules - support local diagnostics, ad/tracker blocking and configured request-header rules.
• Debugger and downloads - support browser actions such as page screenshots, native dialogs, PDF output and requested downloads. Local JavaScript execution is included in the full build; it is not a remote MCP capability.

The bridge is off on a fresh install. Each profile generates its own enrollment; the download contains no installed profile, account credentials or personal saved history. Questions: info@lifub.com.

Keyring browser extension

Keyring is our standalone password and passkey manager. It is a single-purpose extension: it contains no AI, browser agent, analytics or advertising. It is currently a beta, distributed unlisted, and its behaviour may still change.

The property that matters most: encryption and decryption happen in your browser, and we cannot read your entries. Your local Vault password and recovery phrase never leave your device. What synchronises to the Lifub API is ciphertext, and we hold no key that opens it. There is no sign-up and no account - a vault is proven by a cryptographic challenge, not by an identity we hold.

Direct download

Keyring is also available as a direct download from its product page on this site, installed with the browser's Developer mode. It is the same package as the Chrome Web Store install, with the same data practices: everything in this section applies to it unchanged. A direct-download install makes no update checks; you update it yourself from the product page. In the downloaded package, as in the store package, the control channel described under "Limited companion controls" admits no other extension. The Chrome Web Store Limited Use statement at the end of this section is made for the store install.

What leaves your device, and to whom

Vault synchronisation goes to api.lifub.com under /keyring/v1: enrollment, challenge/response proofs, encrypted vault records and recovery state, plus the metadata needed to route and order them. Synced item names, usernames, passwords, notes, TOTP secrets and passkeys are inside the ciphertext. Starting a new keyring's sync can require your browser to solve a short proof-of-work puzzle, which carries nothing about you. To limit abuse, the service then counts the new keyrings started from your IPv4 address, or from the IPv6 /64 network your address is in, for 24 hours, and deletes the count when that day is over.

Connection metadata reaches our servers, as with any HTTPS request: your source IP address is needed to deliver a response. It is retained in security and access logs for up to 30 days and then deleted. Keyring requests no location permission.

Keyring's service requests send no page content, current-tab URLs, browsing history, cookies or credentials in the clear. Keyring contains no third-party service.

What stays on your device

Your Vault password and recovery phrase are used locally. The Rust cryptographic core handles encryption keys; decrypted entries and credentials also pass through local extension memory and the management page or page helpers when needed. They are not sent to Lifub in readable form.

Your settings, encrypted local bootstrap and encrypted vault records stay in extension storage and browser IndexedDB. The unlocked session uses your inactivity auto-lock setting, which defaults to 15 minutes and can be set to Never.

On Chrome and Brave, "Stay unlocked when the browser restarts" is on by default. Keyring keeps a wrapped root key and the random key that opens it together in this browser profile, so a restart can resume the session while respecting your configured inactivity limit. Restarting does not reset the inactivity clock. Lock, auto-lock and turning the option off delete the restart record from the active profile. If the browser is closed when the deadline passes, the record may remain on disk until Keyring runs again.

A copy of the profile containing both keys can open the vault without your local password. The deadline is an application check; later Lock or deletion cannot revoke a copy already taken. Deletion is logical, not a secure erase, and backups may retain the bytes. With restart unlock off, any restart record uses browser session storage instead, which the browser clears when it exits. Firefox does not resume across browser restarts.

Site icons are on by default in Chrome and Brave, and you can turn them off. Keyring reads the browser's own local favicon cache using the saved site's origin, without its path, query or fragment. It makes no request to the website, to an icon service, or to Lifub for them. With icons off, entries show a letter monogram.

Page helpers and permissions

Access to all sites lets a password manager work wherever you sign in. Page helpers load in the top frame of https pages and stay inert while Keyring is locked. With focus autofill on (the default), an empty login field that is focused, including one already focused when the page helper starts, and a sign-in form that appears within five seconds of your click on the page can receive the login you chose last time for that origin, or its only login for that origin, without another click. A site's www address and its bare domain count as the same origin here, and a login saved for another address on the same site fills there only after you have picked it once. Other entries need a click or Enter. With one-time codes on, the code field of a form Keyring has just filled also receives the linked authenticator's current code. This puts the credential into that site's form, where the site can read it. Keyring never submits a form for you. Save and update prompts require explicit confirmation, and navigation discards an unsaved candidate. Passkeys have their own switch, on by default.

Clipboard read is used only to check that a secret Keyring copied is still there before clearing it, so it does not erase something you copied in the meantime. A copied recovery phrase is cleared after 60 seconds, or when you return to the Keyring page if it could not clear while the page was in the background. The comparison happens in memory and is not transmitted.

Tabs are used to match the current site against your entries and to open the management page. Keyring does not record where you browse. Scripting registers the page helpers, alarms enforce inactivity locking, storage keeps the local data described above, and the favicon permission enables local site icons.

The privacy permission controls only the browser's offer to save passwords. "Turn off the browser's own password saving" is on by default; turning it off hands the setting back. Browser policy and another controlling extension can prevent Keyring changing it. Passwords the browser saved earlier stay untouched.

Limited companion controls

Keyring has a narrow local control channel for a companion extension. Published packages - the Chrome Web Store install and the direct download - admit no extension to it; only a development copy of Keyring, loaded from its own source folder, names one allow-listed companion that its owner installs. Where it is admitted, it can see status, counts, login titles, website hosts and settings; change allowed settings; lock Keyring; unlock it, or set up a new Keyring, with a password the companion reads from a local file and hands over without showing it to anyone; fill a saved login into a sign-in form on that login's own site, which puts the credential into that site's form; open its management page; import a file into an unlocked vault; and reset this browser's Keyring after an exact confirmation. It cannot read or export usernames, passwords, TOTP secrets or codes, passkeys or recovery phrases. Where the browser supports them, the same limited controls are available to a browser agent on Keyring's own management page, except the three that take a file: import, set-up and unlock. The channel is on by default, and you can switch it off in Keyring's options.

Chrome Web Store Limited Use

Keyring's use of information received through Chrome extension APIs follows the Chrome Web Store User Data Policy, including its Limited Use requirements. We use that information only for the password-management features disclosed here and their security. We do not sell it, use it for advertising, or use it to determine creditworthiness or lending eligibility.

Questions: info@lifub.com.

Vynx Store distribution build

The direct download at Vynx is the full local build, not a Store package. A separate Chrome Store staging build shares the worker, UI, saved history, provider integrations, proofreading and bridge. Its one build-time difference is that arbitrary local JavaScript execution is absent. This section does not announce a Store listing, Store approval or a Safari/iOS release.

Local page processing

• Dark mode — a local script loads at the start of HTTP and HTTPS pages so it can apply dark mode on domains where you explicitly enabled it.
• Cookie-banner rejection - enabled by default. Local scripts scan supported pages and may click reject or dismiss controls selected by built-in rules. Aggregate diagnostic counts stay local as described above.
• Picture-in-Picture - a local script identifies supported HTML5 videos and selected embedded players. While this feature is enabled, Vynx transiently processes pointer position, page-scroll events and keydown events locally to reveal the video control and detect the Alt/Option+P shortcut. These events are neither retained nor transmitted. With automatic entry enabled, which is the default, a second local script registers the browser's Picture-in-Picture media action at the start of each page, so a playing video with sound can open in Picture-in-Picture when you switch tabs. It reads no page content and transmits nothing; the browser's own site permission still applies, and the option can be switched off in Settings.

These page interventions run locally. The sending providers, saved data, diagnostics and optional bridge retain the same boundaries described in the full-extension section.

Network requests

• Provider models and usage - current availability comes from the selected signed-in provider, not a substituted Lifub model catalogue.
• Dictionary — the first lookup downloads one fixed compressed Ding dictionary file of about 14.4 MB from www.lifub.com. The query itself is not sent. After a successful local cache write, lookups work offline; clearing browser storage or a failed cache write can require another download.
• AI requests and bridge - requests go to the selected supported provider; enabling the optional bridge sends its commands/results through the configured bridge server. Saved chat and recovery history remain in browser storage, not only popup memory.
• Connection logs — as with an ordinary HTTPS request, Lifub receives connection metadata including the source IP address. Security and access logs are retained for up to 30 days and then deleted.

What stays on your device

Extension storage keeps preferences, saved history, recovery data, bridge configuration and local diagnostics as described above. The dictionary keyboard command writes a one-shot local focus timestamp that the popup deletes immediately after reading, whether it is fresh or stale. IndexedDB holds the downloaded dictionary. Vynx has no advertising or third-party analytics, does not sell local extension data, and does not use it for credit, lending, or advertising decisions. Requests you initiate still send the data described above to their selected provider or destination.

Chrome Web Store Limited Use

Vynx's use of information received from Chrome extension APIs adheres to the Chrome Web Store User Data Policy, including the Limited Use requirements. Vynx handles user data only to provide or improve the disclosed user-facing features and their security; it does not use or transfer that data for advertising, data brokerage, creditworthiness or lending, and does not permit humans to read chat content except with the user's specific consent or where access is necessary for security or legal compliance.

Payment Information

Site Audit normally uses a fixed-price, one-time Stripe Checkout. Revolut is available only when separately arranged as an operator fallback. Neither payment route creates a subscription or automatically issues the voucher. Lifub manually verifies the settled payment and delivers the bearer voucher by email. Lifub processes the checkout delivery email to verify and deliver the purchase; delivered messages remain subject to the sender's and recipient's mail-retention settings. Lifub stores the provider name, purchase-reference UUID, transaction and voucher hashes, balance, and issuance time needed for replay-safe fulfillment and accounting. Raw card number, expiry date, and CVC are submitted directly to the selected provider and are never stored on Lifub's servers.

Website Browsing Data

When browsing our site, you automatically send us non-personal data such as your device's IP address, referring website, pages visited, and browser information. We use this aggregated data to:

• Collect website usage statistics to improve performance and content
• Remember your language preference for future visits

Cookies — essential only, no banner

This website uses only strictly-necessary cookies that are essential for the operation of the requested service (e.g. session cookies, CSRF tokens). Per § 25 Abs. 2 Nr. 2 TDDDG, such cookies are exempt from the consent requirement and we therefore do not show a cookie banner. We do not use third-party, advertising, or cross-site tracking cookies. The Analytics product can optionally set one first-party, same-site cookie to recognise returning visitors — off by default, and written only with the visitor's consent (see the Analytics section above); where we run it on our own pages, such as the Analytics demo, it is gated behind an explicit opt-in banner.

If we ever add non-essential cookies, we will request explicit opt-in consent via a banner with an equally-prominent "reject all" option (consistent with DSK Orientierungshilfe Telemedien v1.2, Nov 2024, and VG Hannover, 19 March 2025).

If your browser blocks essential cookies entirely, parts of the service (e.g. session continuity, form submission) will not work. You can still call the public API endpoints with curl without any cookies.

Protecting Your Information

Human administrative access to production is restricted to the operator. HTTPS and API traffic uses TLS 1.2 or later. Production service, root, container, and data contents are encrypted at rest in LUKS2 volumes on both our primary and secondary servers. Each root passphrase is supplied interactively at boot and is stored on neither. The boot, EFI, BIOS, and provider-configuration partitions remain unencrypted but contain no root unlock key. Encrypted off-site archives use a separate key derived from the operator-held recovery passphrase.

Sharing Your Information

We do not sell, rent or trade personal data. We disclose it only to the recipients and processors listed above, for the purposes this policy describes. We do not run analytics, advertising-network integrations, or third-party tracking pixels — see the cookie section below.

Legal Compliance

Data Breach Notification

Should a personal data breach occur and if it is likely to put our users' privacy at risk:

• We will notify users by email and via in-site notification within seven business days
• We will notify designated supervisory authorities within 72 hours