Last updated:

PDF Version of this document

PACKETSNITCH PRIVACY POLICY

Effective Date: November 4, 2026

PacketSnitch (“PacketSnitch”, “the Software”) is developed and distributed by Marshall Whittaker, doing business as oxasploits (“oxasploits”, “we”, “our”, or “us”). This Privacy Policy describes how we collect, use, disclose, and protect information relating to the use of PacketSnitch and of our websites.

By installing, accessing, or using PacketSnitch, or by using our websites, you acknowledge that you have read and understood this Privacy Policy.

1. OUR PRIVACY PHILOSOPHY

PacketSnitch is designed with privacy in mind.

Packet analysis happens on your own computer. Captures, sessions, extracted artifacts, notes, and analysis results are stored locally, and we do not receive them. We collect only what is needed to license the Software, to keep it working, to improve it, and to run our business — and the largest part of that collection is a single opt-in switch that is off until you turn it on.

Three distinct collection surfaces exist, and it is worth separating them at the outset, because they are governed by different switches:

Surface When it operates What you control
Catalog and licensing server Whenever the application checks its license tier or fetches the theme catalog Nothing — this is how licensing works
Anonymous usage metrics and application analytics Only after you enable “Send anonymous usage metrics” One checkbox in Settings → Privacy
Website analytics Whenever you load a page on our sites Your browser’s tracking protections
Third-party integrations Only when you invoke an integration that calls out Per-feature; you choose whether to use it

Section 2 covers the licensing surface, Section 3 the opt-in metrics, Section 4 the websites, and Section 5 the third-party integrations.

2. INFORMATION RECEIVED BY THE CATALOG AND LICENSING SERVER

2.1. What Is Sent

PacketSnitch contacts our catalog server at catalog.packetsnitch.com to determine the installation’s license tier (Demo, Free, Professional, Enterprise, Developer, or revoked), to deliver licensed theme and artifact definitions, and to announce new releases. Each request necessarily conveys, and may be recorded as:

  • The installUUID assigned to the installation;
  • The PacketSnitch version and build identifier;
  • The platform (operating-system family and CPU architecture);
  • The transport-level source address of the connection, which is your public IP address as seen by our server;
  • The connection timestamp; and
  • The HTTP User-Agent, which is configured to identify PacketSnitch and its version.

2.2. What Is Retained

Our catalog server maintains, per installation:

  • An install record carrying the reported tier, the evaluation-window start and expiry, the last-seen timestamp, and a snapshot of the most recent client version, platform, and build;
  • A rolled-up sighting history — one row per distinct combination of version, platform, and build, with first-seen and last-seen timestamps and a visit counter. This answers operational questions such as when an installation moved to a new version, and it is deliberately rolled up rather than appended per request;
  • License entitlement rows for purchased or granted items, including grant and revocation timestamps; and
  • An administrative audit trail recording operator actions taken against the installation, such as a tier change.

If you purchase a license, the server additionally holds the purchase identifiers returned by Paddle, the customer email captured at checkout, and — where you use the self-service portal — a display name and an email-verification timestamp.

2.3. What Is Not Received

The catalog server does not receive packet captures, packet payloads, imported files, extracted artifacts, notes, chat or LLM prompts, LLM responses, your local file paths, or the hostnames and addresses observed inside a capture. The sighting record describes the client build and host platform, never the content you analyse.

2.4. Why We Need It

Tier resolution is how Demo mode, Free mode, and paid tiers work at all. Without an identifier the server cannot tell one installation from another, cannot apply a purchased entitlement, cannot expire an evaluation window, and cannot revoke an entitlement that a payment processor reports as reversed.

3. ANONYMOUS USAGE METRICS (OPT-IN)

PacketSnitch contains an anonymous usage metrics pipeline controlled by exactly one consent switch: “Send anonymous usage metrics”, presented both as a first-run prompt and in Settings → Privacy.

It is disabled by default. No metrics are transmitted until you enable it, and enabling it is a single decision that governs every destination described in this section.

3.2. What Is Collected

While the switch is on, the application transmits the following categories:

Navigation and activity

  • Which tab and sub-tab you opened;
  • How long each tab remained active;
  • Two separate aggregate byte counters per tab: capture data ingested while the tab was open, and bytes processed by that tab’s own tools. These are counts, not content.

Feature use and gating

  • Which named capability was exercised;
  • Whether the license gate granted or refused it, with a short machine token for the refusal reason (no_license, trial_expired, revoked);
  • Success and failure counts, result counts, and counts of dropped queue entries.

Performance and errors

  • How long a named operation took to complete, as a millisecond count;
  • Uncaught errors and exceptions, reduced to the first line of the message and passed through a scrubbing pass that replaces file paths, IP addresses, and capture filenames with placeholders;
  • The number of packets and capture sources analysed, and whether this was the first analysis the installation performed.

Coarse context

  • Application version;
  • Operating-system family and CPU architecture;
  • Language tag;
  • The license tier and a coarse integer count of evaluation days remaining.

Identity

  • A randomly generated per-install identifier, created the first time you opt in. It counts distinct installations. It is not derived from hardware, is not a name or address, and is not shared with third parties other than as described in Section 3.4.

3.3. What Is Not Collected

No metrics field is designed to carry — and no described event populates a field for — the following:

  • Packet capture files, packet payloads, or packet contents of any kind;
  • Imported files, documents, archives, or extracted artifacts;
  • Local file paths or capture filenames;
  • IP addresses, hostnames, or other identifiers observed inside a capture;
  • Chat or LLM prompts, or LLM responses;
  • Credentials, API keys, or keys discovered in traffic.

This is enforced structurally, not by convention. Every outgoing field passes through a compiled-in allow-list that admits only enumerated values — a tab name, a feature name, a protocol name, a model name, a duration, a byte count, an outcome flag. A value that is not on the list is not forwarded.

There is one qualified exception, and it is stated plainly rather than buried: the first line of an error message is free text. Before transmission it is passed through a scrubbing pass that replaces file paths, IP addresses, and capture filenames with placeholders and truncates the remainder. Because scrubbing is pattern-based, it reduces but does not eliminate the possibility that an unusual string survives. If that residual risk is unacceptable for the data you handle, leave metrics disabled — the application is fully functional without them.

3.4. Where It Goes

Anonymous event batches are delivered to our metrics receiver and are concurrently relayed to our Google Analytics 4 property. Section 4 describes the GA4 relationship in full.

The receiving endpoint is configurable. You may repoint it at your own receiver, including the dependency-free receiver shipped with the Software’s source, in which case the anonymous stream is delivered to your infrastructure instead of ours. Google Analytics reporting is not configurable and is governed solely by the consent switch.

3.5. Retention of Metrics

Anonymous event batches land as line-oriented records on our receiver and are retained for software debugging and quality improvement, together with aggregate operational reporting. Because the records carry only a random per-install identifier and enumerated fields, they are not associated with a name, an email address, or an account unless you separately purchased a license.

Clear “Send anonymous usage metrics” in Settings → Privacy. Both the local event batches and all application Google Analytics traffic stop immediately. Events already transmitted cannot be recalled, but no further events are produced.

4. GOOGLE ANALYTICS 4

We use Google Analytics 4 (“GA4”), operated by Google, on our websites and — subject to the consent switch — in the application. These are separate surfaces with separate controls, and we describe them separately.

4.1. Application Analytics

When the Privacy consent switch is enabled, the application loads the GA4 tag and also relays the same anonymous event stream to our GA4 property from the application’s main process.

The main-process relay exists because a packaged desktop build serves its interface from a file:// origin. Browser-side tags cannot deliver collection requests from that origin, so the relay through Google’s Measurement Protocol is what makes reporting function in a packaged build at all. The relay shares the renderer’s consent gate, allow-list, and per-install identity, so the two halves of the stream describe one installation rather than forking it.

GA4 receives the event names and allow-listed fields described in Section 3.2, together with the application version, operating-system family, CPU architecture, and language tag. A stable client identifier, derived from the per-install identifier and persisted, is used so a single installation reports as one user across launches rather than as a new user each time.

Google processes this information on its own infrastructure, potentially outside your country of residence, under Google’s terms of service and privacy policy.

4.2. Website Analytics

Our websites — packetsnitch.com, the storefront at catalog.packetsnitch.com, and their documentation, blog, and release pages — load the GA4 tag on every page. This operates independently of any setting inside the desktop application.

Website analytics covers ordinary web measurement: pages and documentation viewed, scroll depth, referring source, approximate geographic location derived from IP address, device and browser characteristics, and interactions with download, documentation, storefront, and purchase-intent controls.

Query strings on checkout and purchase-intent URLs may contain an install UUID or a buyer email address. Our website analytics deliberately excludes those query strings: such events are emitted with explicit properties, such as the product and a path stripped of its query, rather than the full URL.

The site sets a cookie_consent cookie recording that you dismissed the cookie notice, and the download bar caches the latest release metadata in your browser’s local storage. Neither is transmitted to us through the analytics tag.

4.3. Installer download counts

Separately from GA4, one first-party request records that an installer download link was clicked. The header download bar and the downloads page build their package links at runtime, so there is no static markup for a tag to observe; a small same-site script posts the package filename (for example packetsnitch_4.0.1_amd64.deb) to our catalog server at catalog.packetsnitch.com/downloads/hit. From that name we record only a running count per version and per package type (.deb, .rpm, .exe), together with the first and last time that combination was seen. We do not store a cookie, a visitor identifier, a referrer, or the query string for this request, and the raw request is not retained — only the aggregate is kept.

This counts a click, not a completed transfer: if you cancel a download or your connection fails, the click has already been counted. You can prevent it with the same tracking protections described below. Unlike the GA4 tag, it is served from our own domain, so a content blocker must be configured to block catalog.packetsnitch.com for it to be suppressed.

4.4. Your Choices

Application analytics: clear “Send anonymous usage metrics” in Settings → Privacy.

Website analytics: use your browser’s tracking protection, do-not-track signal, or a content blocker, or block googletagmanager.com and google-analytics.com. Blocking those hosts removes the GA4 tag; the installer download count described above is first-party and requires blocking catalog.packetsnitch.com separately.

We do not treat a blocked or absent tag as an error, and the sites remain fully functional without it.

5. THIRD-PARTY SERVICES AND INTEGRATIONS

PacketSnitch integrates with services operated by third parties. When you invoke an integration, data leaves your computer and is received by that service, which maintains its own privacy policy, terms of service, retention practices, and logging.

Those practices are not ours to control, and this Privacy Policy does not describe them. Your use of a third-party service is governed solely by that provider’s terms.

5.1. Services Currently Shipped

  • VirusTotal — file upload and hash, domain, and URL reputation lookups. Uploading a file transmits the file, or a sample of it, to VirusTotal.
  • Shodan InternetDB — IP-address exposure lookups.
  • hashes.com — hash reverse-lookup and hash-identifier queries, which transmit the hash values you submit.
  • WHOIS / RDAP registries — registration lookups against the regional internet registries, transmitting the IP address being looked up.
  • ASN lookup services — IP-to-autonomous-system lookups.
  • IPSum and the Tor Project Onionoo service — reputation and exit-node dataset retrieval.
  • Ollama — local language-model inference, and cloud model inference when a cloud-tagged model is selected (see Section 5.2).
  • OpenRouter — cloud language-model inference, when selected as the provider.
  • Cohere — cloud language-model inference, when selected as the provider.
  • Paddle — checkout, subscription, billing, and payment processing (see Section 6).
  • Google Analytics 4 — the analytics described in Section 4.
  • Any additional API, endpoint, host, or plugin you configure yourself, including plugin-originated network requests made under a plugin’s declared capability.

This list is not exhaustive and will change as integrations are added or retired. The application’s Settings interface indicates where a credential is required for a given service.

5.2. Language Models, and How to Keep Data Local

PacketSnitch can send capture-derived and session-derived content to a language model to produce summaries, analysis, and chat responses. That content is not subject to the anonymous metrics allow-list described in Section 3.3 — it is prompt text, sent to the provider you selected, because inference cannot happen otherwise.

What leaves your computer depends entirely on which provider you select:

Provider selection Where prompts go
A local Ollama model Nowhere. Inference runs on your own machine against your local Ollama installation.
A cloud-tagged Ollama model (any name ending :cloud, including the shipped default) ollama.com. Cloud-tagged models are served by Ollama’s infrastructure, not by your local daemon.
OpenRouter OpenRouter, and the upstream model provider OpenRouter routes the request to.
Cohere Cohere.

Prompt content is derived from your capture and session. It can therefore contain IP addresses, hostnames, credentials observed in traffic, file contents, personal data belonging to third parties, and other sensitive material.

If you do not want your data to reach a third-party language-model provider, configure a local Ollama model instead of a :cloud model, OpenRouter, or Cohere.

Language-model functionality is optional in every part of the application. PacketSnitch remains usable with it disabled entirely, and disabling it means no prompt content is generated or transmitted.

5.3. Other Outbound Connections

Beyond the integrations above, PacketSnitch contacts our own infrastructure and a small number of third-party hosts for routine reasons: version and release checks, theme and plugin delivery, license verification, and update discovery. These connections are necessary for the Software to function as licensed and are described in the EULA.

Optional active reconnaissance, such as service scanning, contacts the targets you specify and is enabled only when you choose to use it.

5.4. API Keys and Accounts

Certain PacketSnitch features require accounts or API keys obtained directly from third-party providers. Obtaining, maintaining, securing, and paying for these is solely your responsibility. Keys you enter are stored in your local settings file and are used to authenticate your requests to that provider; they are not transmitted to us.

6. PAYMENT PROCESSING AND PADDLE

Themes, plugins, licenses, subscriptions, and other digital products may be purchased through PacketSnitch using Paddle as the payment processor.

Paddle independently processes payment information under its own privacy policy and terms of service. Payment card and other financial information submitted through Paddle is collected and processed by Paddle and its payment partners; we do not receive or store it.

We may receive transaction-related information from Paddle, including information necessary to identify your purchase, maintain your subscription, administer your license, provide support, and meet accounting and tax obligations. For those purposes we may retain:

  • Customer name;
  • Email address;
  • Purchase and subscription identifiers;
  • License information; and
  • Transaction history.

Except where required by law, necessary to perform our contract with you, or permitted under Paddle’s agreements, this information is not sold or disclosed to unrelated third parties.

7. HOW WE USE INFORMATION

We use the information described above to:

  • Determine and enforce the installation’s license tier, including the evaluation window;
  • Deliver purchased and licensed content, and administer subscriptions;
  • Detect and prevent fraud, abuse, and circumvention of licensing controls;
  • Operate, secure, and defend our servers and infrastructure;
  • Diagnose defects and improve the Software’s usability, reliability, and performance;
  • Respond to support requests and communicate about the Software; and
  • Comply with legal, tax, and accounting obligations.

We do not use the anonymous metrics stream to identify an individual, and we do not attempt to re-identify it.

8. DISCLOSURE

We do not sell your personal information.

Information may be disclosed only:

  • Where required by applicable law, court order, or legal process;
  • Where necessary to investigate fraud or abuse, or to protect our legal rights;
  • Where necessary to process payments, subscriptions, or license entitlements, including to Paddle;
  • Where necessary to operate our business, to service providers acting on our behalf under confidentiality obligations; or
  • In connection with a sale, transfer, restructuring, merger, acquisition, or other transfer of all or part of the business or assets, subject to applicable law.

9. SECURITY

Reasonable administrative and technical safeguards are employed to protect information under our control. Where feasible, identifiers are random rather than derived, and metrics carry enumerated values rather than free text.

No method of electronic storage or internet transmission can be guaranteed to be completely secure. Accordingly, we cannot guarantee absolute security.

10. RETENTION

Information is retained only for as long as reasonably necessary for customer support, accounting, tax compliance, licensing, fraud prevention, legal obligations, and business operations.

Anonymous metrics are retained for software debugging and quality improvement.

Install records and sighting history are retained for the life of the licensing relationship, because entitlement and revocation history must remain answerable.

11. CHILDREN

PacketSnitch is not directed toward children under thirteen (13) years of age. We do not knowingly collect personal information from children.

12. YOUR RIGHTS

Depending upon applicable law, you may have rights regarding your personal information, including the ability to request access, correction, deletion, restriction, portability, or objection, and to lodge a complaint with a supervisory authority.

Requests may be submitted through the official PacketSnitch support channels. We will respond within the period required by applicable law.

Two limits are worth stating plainly:

  • Anonymous metrics cannot be tied to you. If the record carries only a random per-install identifier and enumerated fields, we have no way to determine which records are yours. We will act on a request that identifies an installUUID, but we cannot search by name or email for data that was never associated with either.
  • Data already sent to a third party is outside our control. We cannot recall, delete, or restrict information transmitted to VirusTotal, Shodan, hashes.com, an RDAP registry, Ollama, OpenRouter, Cohere, Paddle, or Google. Those requests must be directed to the provider.

13. INTERNATIONAL TRANSFERS

Our infrastructure and certain service providers, including Google and Paddle, process information in jurisdictions other than your own. Where required, transfers are made under appropriate safeguards recognized by applicable law.

14. CHANGES TO THIS POLICY

This Privacy Policy may be revised from time to time.

Revisions become effective upon publication with an updated Effective Date. Material changes will be reflected in the Effective Date and, where appropriate or legally required, announced through the Software, our website, or email.

Continued use of PacketSnitch or our websites after a revision is published constitutes acceptance of the revised policy to the extent permitted by applicable law.

15. NO WARRANTY AND LIMITATION OF LIABILITY

TO THE MAXIMUM EXTENT PERMITTED BY APPLICABLE LAW, PACKETSNITCH IS PROVIDED “AS IS” AND “AS AVAILABLE” WITHOUT WARRANTIES OF ANY KIND, WHETHER EXPRESS, IMPLIED, STATUTORY, OR OTHERWISE.

OXASPLOITS EXPRESSLY DISCLAIMS ALL WARRANTIES, INCLUDING BUT NOT LIMITED TO MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, TITLE, NON-INFRINGEMENT, ACCURACY, RELIABILITY, OR THAT THE SOFTWARE WILL OPERATE WITHOUT INTERRUPTION OR ERROR.

TO THE MAXIMUM EXTENT PERMITTED BY LAW, OXASPLOITS SHALL NOT BE LIABLE FOR ANY INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, CONSEQUENTIAL, OR PUNITIVE DAMAGES, INCLUDING BUT NOT LIMITED TO LOSS OF PROFITS, LOSS OF DATA, LOSS OF BUSINESS, LOSS OF GOODWILL, NETWORK DAMAGE, OR ANY DAMAGES ARISING FROM THE USE OF PACKETSNITCH OR ANY THIRD-PARTY SERVICE.

USE OF PACKETSNITCH IS ENTIRELY AT YOUR OWN RISK.

16. CONTACT

Questions regarding this Privacy Policy may be directed to:

PacketSnitch Support
Marshall Whittaker dba oxasploits
300 Long Shoals, Ste 14V
Arden, NC 28704
United States

Email: support@packetsnitch.com
Website: https://packetsnitch.com
Parent Website: https://oxasploits.com

This Privacy Policy should be read together with the End User License Agreement, available at https://packetsnitch.com/EULA/. Where the two conflict regarding the handling of personal information, this Privacy Policy controls.