What Veilance processes locally, changes in your browser, and sends.

1. Scope and privacy controller

This policy applies to the Veilance browser extension, veilance.org, and the public Veilance API and leaderboard. Veilance is operated by Revix Technologies Incorporated (“Revix,” “Veilance,” “we,” “us,” or “our”), which is responsible for personal information received by the Veilance website or API.

For information that remains solely in your browser, Veilance provides software that processes the information on your device. Revix does not receive that local information unless you enable or initiate an upload, open a link that includes an identifier, contact us, or otherwise send it to us.

No Veilance account is required. The extension automatically creates a local pseudonymous identifier and Solana wallet even when telemetry uploads remain disabled.

2. Default behavior in extension v0.7

The reviewed extension uses the following defaults:

• Routine observation and built-in indicators: enabled.
• Fingerprint Shield (Beta): enabled.
• Tracker, behavioral detection, and Shield databases: enabled.
• Automatic database update checks: enabled, normally every eight hours.
• Automatic telemetry snapshot capture: disabled.
• Permission to upload telemetry snapshots: disabled.
• Automatic snapshot upload: disabled.
• Payout dashboard: unavailable in the reviewed build.
• Pseudonymous client ID and local Solana wallet: created automatically during extension initialization.

3. Routine local observation

When Veilance is allowed to run, its packaged scripts start at the beginning of a top-level HTTP or HTTPS page. Routine observation can occur on public websites and on local or private-network HTTP(S) pages, including localhost, if the browser permits the extension to run there. Browser-internal pages, extension pages, local files, and other non-HTTP(S) pages are not supported.

Site and visit information stored locally

• the page origin, hostname, protocol, and port;
• a random visit ID and internal tab, document, and navigation identifiers;
• start, update, page-load-complete, and end timestamps; active status; and visit duration; and
• locally generated findings, severity labels, evidence summaries, and interest scores.

The retained page identity does not include the page path, query string, or fragment.

Network activity processed and stored locally

Chrome’s webRequest API supplies the requested URL so Veilance can parse and classify the request. Veilance retains aggregate counts, destination hostnames, resource types, first- or third-party classification, and tracker matches. It does not request or retain request bodies. For the top-level page response, it stores the response status code and whether selected security headers are present; it does not retain the header values.

The selected header names are Content-Security-Policy, Strict-Transport-Security, Permissions-Policy, Referrer-Policy, X-Frame-Options, Cross-Origin-Opener-Policy, and Cross-Origin-Resource-Policy.

Page characteristics stored locally

• counts of scripts, third-party scripts, iframes, and third-party iframes;
• the number of cookies visible through document.cookie, not cookie names or values;
• localStorage.length and sessionStorage.length, not storage keys or stored values;
• the number of IndexedDB databases and Cache Storage containers when the browser makes those counts available;
• whether the page is a secure context; and
• whether a service worker controls the page.

Browser and page API activity stored locally

Veilance records supported API names, actions, counts, and limited non-content metadata involving network requests, trackers, security headers, storage, cookies, Canvas, fonts, WebGL, WebGPU, Web Audio, Navigator and Client Hints, Screen, locale and time zone, CSS media queries, performance timing, network information, media capabilities, encrypted media, WebRTC, media devices, geolocation requests, permissions, connected devices, sensors, credentials and WebAuthn, file-system access, speech, Clipboard, notifications, battery, Beacon, Privacy Sandbox APIs, and single-page-app navigation.

Local signal details are limited to a small number of primitive fields. The sanitizer rejects fields named or associated with page text, bodies, payloads, cookies, authorization data, tokens, passwords, URL paths or queries, clipboard content, form or input content, database or storage keys, and location coordinates.

Routine instrumentation runs in the page’s main JavaScript world so it can observe supported calls. It attempts to preserve native behavior, but instrumentation can add processing overhead and may affect compatibility on some websites. Veilance reports observed behavior and does not treat an API call or tracker match as proof that a website is malicious.

4. Veilance Shield

Fingerprint Shield (Beta) is enabled by default in v0.7. It is separate from detection: detection records supported activity, while Shield can change a supported value before the website receives it. Changes apply to newly loaded pages; open pages may need to be reloaded after the setting changes.

The bundled Shield database reviewed with v0.7 contains 30 default-enabled, data-only rules. The active count and parameters can change through validated database updates. Downloaded rules may select only hooks and transformation strategies already packaged in the extension; they cannot supply executable JavaScript.

The reviewed bundled rules include:

• Web Audio: six rules that make small, session-consistent changes to selected analyser or audio-buffer entries, with no more than eight edited entries per operation under the shipped parameters.
• Canvas and font metrics: bounded changes to selected Canvas pixel values or exports and a small session-consistent change to supported measureText metrics.
• Navigator: replacement or bucketing of device memory, hardware concurrency, and maximum touch points.
• Screen: normalization or bucketing of color depth, screen width and height, available dimensions, and device-pixel ratio.
• WebGL: downward caps on ten capability values, bounded changes to selected readPixels bytes, and replacement of unmasked renderer and vendor strings.

Shield uses a random page-session seed so supported changes are consistent within that page session but are not intended to remain a stable cross-session fingerprint.

For visibility, Veilance stores a local Shield activity record containing the rule ID, fingerprint surface, action, technique, explanation, count, first and last protection times, and a bounded preview of the value returned to the page. Depending on the type, that preview can contain a modified scalar, a short sample of an array, selected object fields, a shortened data-URL prefix, or Blob type and length. These Shield returned-value previews are local visit-history data and are not included in the v0.7 telemetry snapshot or upload schema.

Tracker Shield is not active in the reviewed build. Veilance does not currently claim to block tracker requests.

5. Local telemetry snapshots and redaction

A telemetry snapshot is separate from the routine visit record. Manual snapshot creation requires an eligible visit. Automatic snapshot capture is disabled by default and must be enabled separately. Snapshot creation never grants upload permission.

Version 0.7 permits a snapshot only when all of the following are true:

• the page is a public HTTP or HTTPS hostname;
• the visit reaches the current interest threshold of 25 out of 100;
• the snapshot passes the final safety validator; and
• the tab is not Incognito.

Localhost, local and internal suffixes, private or reserved IP ranges, and unsupported pages cannot be snapshotted or uploaded. If a user separately allows Veilance to run in Incognito, routine observation may depend on the browser’s Incognito extension model, but v0.7 explicitly refuses both manual and automatic snapshots in Incognito.

What is temporarily processed to create a snapshot

When a snapshot is requested, the content script traverses the live document in the page. To decide what to retain or redact, it temporarily reads DOM text nodes, attribute names and values, resource URLs, and up to 1 MiB of each inline script’s source text for coarse capability matching and size classification. This processing occurs in the page while the redacted representation is built. The unredacted text, attributes, URLs, and inline script source are not intentionally sent to the background service worker or written into the snapshot database.

What the redacted snapshot can retain

• an inert HTML-like tag structure;
• redaction markers in place of text, inline scripts, style blocks, form controls, titles, templates, and other opaque content;
• selected low-risk structural attributes, such as safe type, relationship, loading, form method, referrer policy, iframe sandbox, dimensions, and script loading flags;
• public resource origins, including scheme, hostname, and port, while removing paths, queries, and fragments;
• public resource-host counts and tag counts;
• coarse advertising, consent, anti-blocking, and tracking markers derived from element identifiers, class names, and attribute names, without retaining the original identifier or class text;
• coarse inline-script capability hints and size buckets, without retaining inline source; and
• redaction counters and truncation metadata.

Snapshot limits and validation

The redacted HTML is limited to approximately 384 KiB, 12,000 visited nodes, a depth of 64, and 160 retained public resource hosts. The validator rejects unsafe text, executable attributes, full resource URLs, private hosts, forbidden identity or secret fields, unexpected tags or attributes, and payloads outside the defined schema.

No automated sanitizer can guarantee that every future webpage or browser behavior will be handled perfectly. Do not create or upload a snapshot from a hostname that you do not want associated with your pseudonymous identifier, public wallet address, and IP address.

6. Optional telemetry uploads

Telemetry upload permission is disabled by default. You may enable “Allow pseudonymous snapshot uploads” in Settings, queue individual or all eligible snapshots, choose “Upload now,” or separately enable automatic uploads. Automatic snapshot capture and automatic upload are independent controls. Enabling upload permission is an affirmative choice to send the identifiers, exact hostname, server-observed IP address, and redacted snapshot contents described below to Revix for automated processing and limited authorized human review as described in Section 11. Local observation and Shield remain usable without enabling uploads.

Queued and automatic uploads normally use a randomized delay of five to fifteen minutes. “Upload now” queues all eligible local, failed, or already queued snapshots and immediately starts an upload attempt. Failed records use progressively longer randomized retry delays based on approximately one minute, five minutes, fifteen minutes, one hour, and four hours.

Each request contains no more than 20 snapshots and is constrained to approximately 2 MiB of uncompressed snapshot data.

IP lookup performed before upload

Immediately before an upload operation, the extension sends a credential-free GET request to https://api.veilance.org/api/v1/telemetry/ip. The endpoint returns the IPv4 or IPv6 address observed by the Veilance API. If the lookup fails or returns an invalid address, the upload fails closed and remains available for retry. Veilance does not use WebRTC, STUN, or a third-party IP lookup service for this step.

Multipart fields sent with every upload

• client_id: the stable 64-character pseudonymous client ID;
• wallet_address: the automatically generated public Solana wallet address;
• domain_name: the exact normalized public hostname, including subdomains, but excluding scheme, port, path, query, and fragment;
• ip_address: the server-observed IPv4 or IPv6 address returned by the Veilance IP endpoint; and
• telemetry: a raw gzip file named telemetry.bin.

Uploads are sent by HTTPS POST to https://api.veilance.org/api/v1/telemetry/upload with browser credentials omitted, no-store caching, redirect refusal, and a no-referrer policy.

Contents of the gzip telemetry file

The gzip envelope contains a batch schema version, random batch ID, the same contributor/client ID, and the snapshot observations. Each v0.7 observation can contain:

• snapshot schema version, random event ID, and extension version;
• the exact public hostname and whether the page used HTTPS;
• rounded visit duration and total, first-party, and third-party request counts;
• up to 120 public third-party destination hostnames with request and resource-type counts;
• up to 200 tracker or managed-rule identifiers with category and request counts;
• up to 100 explicitly allowlisted browser API signals, limited to indicator ID, API name, action, and count;
• script, iframe, JavaScript-visible cookie, local/session storage, IndexedDB, Cache Storage, and service-worker counts or status;
• booleans showing the presence of selected response security headers;
• the interest score, level, threshold, eligibility status, and up to 16 reason identifiers with severity and points; and
• the safety-validated redacted document and its structural evidence and redaction counters.

Information excluded from the v0.7 snapshot payload

The schema and validator exclude full page URLs, URL paths, queries and fragments; page text; form and input values; cookie names and values; storage keys and values; authorization headers and tokens; clipboard contents; location coordinates; credentials and passkey data; file names and file contents; media content; request bodies; private or local-network resource hosts; exact visit timestamps; internal visit, tab, document, and navigation IDs; response status codes; local signal detail objects; Shield protection events and returned-value previews; the local environment hash; and the wallet private key.

The API and its infrastructure also necessarily receive ordinary request metadata, such as request time, source network address, TLS and connection information, and browser user-agent information. Uploaded records are used for validation, deduplication, privacy intelligence, security and abuse prevention, contributor administration, and possible rewards. A submission is not guaranteed to be accepted or rewarded.

7. Pseudonymous client identity, wallet, and rewards

Client ID

At startup, the extension creates or restores a random 32-byte client ID represented as 64 hexadecimal characters. The ID is stable for the browser extension profile and is created even when uploads are disabled.

To decide whether to keep or rotate that ID, the extension calculates and stores a local SHA-256 hash of coarse environment information: browser family, operating system, CPU architecture, and Native Client architecture. If that coarse environment hash changes, the client ID is rotated. Neither the source environment fields nor the hash are included in telemetry uploads.

Automatically generated Solana wallet

At startup, the extension creates an extractable Ed25519/Solana keypair if a stored wallet is not already present. The public address and creation time are displayed in Settings. The 64-byte secret key is stored as Base64 text in chrome.storage.local.

The private key is exposed only through the explicit Settings export flow and is not intentionally included in telemetry or synced to Veilance. Clearing extension data, uninstalling the extension, deleting the browser profile, or losing the device may permanently remove the local copy if you have not backed it up.

The public address is required for every v0.7 telemetry upload, even if no reward is issued. If a reward is later sent on Solana, the wallet address, token amount, transaction time, and other blockchain transaction data can be permanently public and outside Veilance’s ability to delete. The reviewed v0.7 interface marks the payout dashboard as unavailable.

Telemetry contributions are pseudonymous, not anonymous. The client ID, wallet address, exact hostname, and IP address can link multiple submissions or make a contributor identifiable when combined with other information.

8. Tracker, detection, and Shield database updates

Veilance uses tracker definitions, behavioral detection definitions, and Shield rules. All three databases are enabled by default, and automatic checks are enabled by default. The normal schedule is every eight hours, with an initial check shortly after setup and an install-time check.

The extension downloads repository archives from GitHub or codeload.github.com for:

• Veilance Tracker DB ↗
• Veilance Detection DB ↗
• Veilance Shield DB ↗

GitHub and its infrastructure receive ordinary network metadata for those requests, such as IP address, request time, user agent, and requested repository path, under GitHub’s own privacy practices. Veilance does not intentionally include visit history or telemetry snapshots in database-update requests.

Downloaded records are treated as data, validated, limited in size and count, and stored locally. Shield records can select only packaged strategies and cannot execute remote code. Update logs store status, timestamps, counts, revision information, and errors; each database log is limited to the 50 most recent entries.

Settings provides separate controls to disable a database, disable its automatic update checks, or manually check for updates. Users can also import local custom indicator JSON files. Imported rule data remains local unless it contributes identifiers or findings to a snapshot that the user later uploads.

9. Veilance website and public leaderboard

The Veilance website does not require an account and is not designed to use advertising pixels or personalized advertising. The website host, content-delivery network, DNS provider, security provider, and API infrastructure may process standard web-request information needed to serve and protect the service, including IP address, user agent, date and time, requested path and query, referrer when supplied, and security or error logs.

The leaderboard requests public ranking data from https://api.veilance.org/api/v1/leaderboard. As of this policy’s effective date, the public API returns rank, a masked client ID, accepted telemetry count, and assigned payout amount. It does not publish IP addresses, wallet addresses, or per-site browsing history in that response.

The website links to services operated by others, including Google’s Chrome Web Store, Microsoft Edge Add-ons, GitHub, X, Telegram, Pump.fun, Solscan, and Solana-related services. Those parties receive information when you visit or interact with them and apply their own privacy terms.

10. Why information is processed and applicable legal bases

Depending on the feature and jurisdiction, Veilance processes information for these purposes:

• Provide local observability and Shield: to detect, explain, and, where enabled, modify supported browser privacy surfaces. The applicable basis is providing the user-requested product and our legitimate interest in operating its core privacy and security functions.
• Maintain rule databases: to provide current tracker, detection, and protection definitions. The applicable basis is providing the product and our legitimate interest in keeping it accurate and secure.
• Receive optional telemetry: to validate, deduplicate, analyze, and incorporate user-contributed snapshots into privacy intelligence. Where consent is required, the basis is the user’s separate, affirmative upload permission.
• Administer contributions and rewards: to associate accepted submissions with a public wallet, prevent duplicate or manipulated submissions, calculate or assign rewards, and maintain accounting or transaction records. The basis may be consent, performance of the contributor arrangement, legitimate interests in administering the program, or legal obligations.
• Operate and secure the website and API: to deliver requests, diagnose failures, rate-limit, prevent abuse, investigate security incidents, and protect users and infrastructure. The basis is our legitimate interest in operating and securing the service.
• Comply with law: to meet legal, regulatory, tax, accounting, sanctions, law-enforcement, or court requirements. The basis is compliance with legal obligations or the establishment, exercise, or defense of legal claims.

Providing telemetry is optional and is not a statutory or contractual requirement. If you choose the upload feature, the client ID, public wallet address, exact hostname, server-observed IP address, and validated snapshot payload are required for that feature; an upload cannot proceed without them. You may withdraw snapshot-upload permission at any time in Settings. Withdrawal stops future authorized transfers and can abort an active upload, but does not make prior processing unlawful and does not automatically delete records already received by Veilance.

Veilance may use automated interest scoring, eligibility checks, validation, deduplication, and abuse controls. It does not make solely automated decisions about a person that produce legal or similarly significant effects.

11. Service providers, authorized review, disclosures, and prohibited uses

Veilance may disclose information only as reasonably necessary to:

• infrastructure, hosting, content-delivery, security, storage, communications, and professional-service providers acting for Revix;
• GitHub for database-update and repository requests;
• Google, Microsoft, and other browser-distribution providers when users visit or install through their stores;
• authorized Revix personnel or contractors who validate submitted snapshots, investigate duplication, manipulation, abuse, or security issues, administer contributor rewards, provide user support, or comply with law;
• courts, regulators, law enforcement, or other parties when required by law or reasonably necessary to protect rights, safety, security, and service integrity; or
• a successor in a merger, financing, reorganization, acquisition, bankruptcy, or sale of assets, subject to applicable notice and consent requirements.

Authorized reviewers may inspect the submitted, redacted snapshot and associated identifiers for validation, contributor administration, user-requested support, security and abuse investigation, or legal compliance. Human access may occur only for the disclosed Veilance purposes, with the user’s applicable consent or another legally permitted basis. Veilance is not intended to give reviewers access to the excluded raw page text, form values, credentials, cookie values, storage contents, or private wallet key.

Veilance does not sell personal information; does not transfer it to data brokers; does not use or transfer it for personalized advertising, cross-context behavioral advertising, creditworthiness, or lending; and does not use browsing activity for a purpose unrelated to Veilance’s disclosed privacy-observability, protection, security, and optional contribution functions.

The use of information received from Google APIs will adhere to the Chrome Web Store User Data Policy, including the Limited Use requirements.

12. Retention

Local visit history

Veilance stores visit history in a SQLite WASM database serialized into extension-local browser storage. The database automatically keeps the 20 most recent visits and removes older visit rows.

Local telemetry snapshots

The normal snapshot limit is 20. Older snapshots that are not pending can be pruned automatically. Snapshots in queued, uploading, or failed status are exempt from that pruning, so the local total can temporarily exceed 20 until uploads are resolved or records are deleted. Uploaded, blocked, or local-only snapshots may remain among the newest 20 until pruned or cleared.

Other local data

Settings, indicator preferences, imported indicators, downloaded tracker/detection/Shield records, the client identity and environment hash, the Solana wallet and private key, and update state remain in extension storage until replaced, reset by an available control, cleared through browser extension data, or removed when the extension or browser profile is deleted. Update logs are limited to the 50 most recent entries per managed database.

Submitted telemetry and server records

Accepted telemetry may be retained for historical privacy intelligence, validation, deduplication, security, contributor accounting, and research for as long as those purposes continue. Veilance does not currently publish a fixed maximum retention period for accepted telemetry, associated client IDs, public wallet addresses, hostnames, or server-observed IP addresses. Accepted telemetry may therefore remain in the historical intelligence dataset indefinitely while Revix continues to consider it necessary for those stated purposes, subject to applicable deletion rights and legal retention limits.

Rejected, invalid, duplicate, failed, abuse-related, security, support, and operational records may be retained for as long as reasonably necessary to prevent fraud, protect the service, resolve disputes, comply with law, and preserve system integrity. Backup copies may remain until ordinary backup rotation completes. Aggregated or de-identified information that can no longer reasonably identify a person may be retained for research and statistical purposes.

Solana transactions, if any, are maintained by the public blockchain and are not controlled or erasable by Veilance.

13. Extension controls and privacy rights

Controls available in the extension

Depending on the installed version, users can:

• enable or disable individual observation indicators;
• disable Fingerprint Shield;
• disable the tracker, detection, or Shield databases and their automatic updates;
• leave automatic snapshot capture disabled or turn it off;
• leave upload permission and automatic upload disabled or withdraw upload permission;
• review and delete individual snapshots or clear all snapshots;
• review and clear local visit history; and
• view, copy, and explicitly export the local wallet key material.

Turning off automatic upload does not necessarily cancel snapshots that are already queued. Turning off upload permission stops and can abort transfers, but does not delete the local snapshots or clear their prior queue and retry metadata. Delete or clear snapshots before re-enabling permission if you do not want them considered for a later upload.

Uninstalling the extension or clearing its storage can remove local visit history, snapshots, settings, client identity, and wallet material. Back up any wallet you intend to keep before doing so.

Rights concerning information held by Revix

Where applicable, you may request access to, correction of, deletion of, or a portable copy of personal information held by Revix; object to or request restriction of certain processing; withdraw consent; opt out of legally defined sale, sharing, targeted advertising, or profiling; appeal a denied request; and complain to an appropriate privacy regulator.

Because Veilance does not require an account, we may need the full client ID, public wallet address, event ID, or other information sufficient to locate and verify the records. Never send us the wallet private key. If you lose or delete the identifier needed to locate pseudonymous submissions, we may be unable to associate a request with those records.

Revix will not discriminate against a person for exercising applicable privacy rights. We may deny or limit a request where permitted by law, including when identity cannot be verified, the request would adversely affect another person, a legal exception applies, or retention is required for security, fraud prevention, accounting, legal claims, or compliance.

Requests may be sent using the contact information in Section 20. Authorized agents may submit requests where allowed by law, subject to verification of their authority and the user’s identity.

14. Browser permissions and code execution context

Veilance v0.7 requests broad access because its user-facing purpose is to observe privacy-relevant activity across the websites a user visits and to apply Shield at the beginning of page execution.

• storage: stores settings, managed rules, client identity, wallet material, update state, and the serialized local SQLite database.
• unlimitedStorage: reduces the risk that local history, rules, and snapshots are rejected by ordinary extension-storage quotas.
• alarms: schedules tracker, detection, and Shield database checks and queued upload retries.
• webRequest: observes HTTP(S) request URLs for host-level aggregation and reads top-level response header names and status.
• webNavigation: correlates top-level navigation start, commit, completion, redirects, and visit lifecycle.
• scripting: dynamically registers or unregisters the packaged Fingerprint Shield script.

The host permissions cover http://*/*, https://*/*, and https://api.veilance.org/*. Packaged observation scripts run at document_start in the top frame. One script runs in the page’s main JavaScript world to observe supported APIs; the content bridge and redaction code run in the extension’s isolated world. When enabled, the packaged Shield script also runs at document_start in the page’s main world.

15. Security and data minimization

Veilance uses host-level and count-based evidence where practical; limits signal, host, tracker, node, document, snapshot, and batch sizes; removes disallowed fields; restricts uploaded API signals to an explicit allowlist; validates snapshots before storage and again before upload; excludes private hosts from snapshots; and transmits uploads over HTTPS.

Remote Shield definitions are declarative and cannot provide executable code. Upload requests omit browser credentials, reject redirects, avoid referrers, and use no-store caching. The extension source and managed databases are publicly reviewable.

These controls reduce risk but cannot guarantee that software, browser storage, redaction, network transmission, server systems, or public blockchains will be error-free or completely secure. The wallet private key is particularly sensitive because the reviewed build does not add a Veilance passphrase or separate encryption layer.

Security and privacy issues may be reported through the contact information below or the official repository. Do not include private keys, credentials, raw sensitive page content, or exploit details in a public issue.

16. U.S. state privacy disclosures

For laws that require category-based disclosures, Veilance may process the following categories during the preceding 12 months, depending on the features used:

• Identifiers: IP address, pseudonymous client ID, public wallet address, event and batch IDs, and ordinary server identifiers such as user agent.
• Internet or electronic network activity: exact hostnames, protocol, visit duration, request and resource-type counts, third-party hosts, tracker matches, supported browser API activity, security-header presence, redacted page structure, and website/API logs.
• Financial or transaction-related information: public Solana wallet address, assigned reward amounts, and public blockchain transaction information if a reward occurs. Veilance does not receive the wallet private key through the upload schema.
• Approximate location information: an IP address can be used by infrastructure or service providers to infer an approximate area. Veilance does not upload GPS coordinates from observed geolocation API calls.
• Potentially sensitive information: an exact hostname can reveal or suggest sensitive interests or services. Veilance does not intentionally use submitted hostnames to infer protected traits about a contributor.
• Inferences about website behavior: findings, tracker classifications, interest scores, and severity labels describe observed website behavior, not a user’s character, eligibility, creditworthiness, health, or other personal attributes.

Sources include the extension and browser APIs, the user’s settings and upload actions, the user’s network connection, the Veilance API, and public blockchain data if a reward is issued. Business purposes and disclosure recipients are described in Sections 10 and 11.

Veilance has not sold personal information or shared it for cross-context behavioral advertising and does not use it for targeted advertising, credit decisions, or lending. Because Veilance does not engage in those activities, it does not offer a separate “Do Not Sell or Share” link at this time. Users may still send an opt-out or rights request using Section 20.

If Veilance activates a contributor reward program that is subject to financial-incentive or loyalty-program notice requirements, the material program terms will be presented before participation. The reviewed v0.7 interface marks the payout dashboard as unavailable.

17. International processing

Revix is based in the United States. Optional telemetry, website and API requests, support communications, and related records may be processed in the United States and in other locations where service providers operate. Those locations may have privacy laws different from the user’s home jurisdiction.

Where required, Revix will use legally recognized safeguards for restricted international transfers. Users in the European Economic Area, United Kingdom, or Switzerland may contact Revix to ask about applicable safeguards and may lodge a complaint with their local supervisory authority.

18. Children

Veilance is a general-audience browser privacy tool and is not directed to children under 13 or to anyone below the minimum age required to independently consent to the relevant processing in their jurisdiction. We do not knowingly seek optional telemetry from a child who cannot lawfully provide the required consent. A parent or guardian who believes a child submitted personal information may contact us to request review and deletion, subject to verification and legal exceptions.

19. Changes to this policy

We may update this policy to reflect changes in the extension, website, API, databases, contributor program, law, or service providers. The effective date and reviewed extension version will be changed when the policy is revised.

If an extension update materially expands collection, transmission, use, sharing, identifiers, retention, human access, or a default setting, Veilance will provide any additional in-product or browser-store disclosure and obtain any consent required by applicable law or platform policy before the new practice applies.

20. Contact Revix Technologies Incorporated

Privacy questions, rights requests, deletion requests, security reports, and implementation concerns may be directed to:

Email: veilance13@gmail.com
Phone: +1 405-458-9177

Review the Veilance source or open an issue ↗