Pyvorin GDPR Considerations

Assessing pyvorin-native 1.0.9 under the GDPR comes down to three questions: what personal data does the software touch, where does it go, and who controls it. This page answers the first two from the installed artefact itself — not from marketing copy — and flags the parts your own legal team has to decide. The short version: your source code never leaves the machine under the native package, the telemetry stream contains event metadata rather than payloads, and the one genuinely personal artefact is the device fingerprint sent during licence checks.

One correction before anything else. An earlier draft of this page claimed Pyvorin "does not collect source code (unless explicitly enabled)". That parenthetical was wrong, and the corrected sentence matters for your records: under pyvorin-native there is no opt-in that uploads source code, because there is no source-upload code path at all. The sibling package pyvorin-thin is different, and the distinction is scoped precisely below.

What leaves the machine

The complete outbound network surface of pyvorin-native 1.0.9 was captured by intercepting the HTTP layer at runtime. Two endpoints exist in the shipped binary, plus two that belong only to the optional product CLI:

There is no update-check call, no crash reporter, and no diagnostic upload. A full string sweep of every installed binary finds exactly three hosts in the code: api.pyvorin.com, app.pyvorin.com and localhost.

Compilation itself is local and in-process. The compiler path — the module that turns your Python into native code — contains no HTTP client at all; a grep for urllib, urlopen and requests across the compiler sources finds nothing, and nothing in the installed binaries contradicts that. Your source is processed on your CPU and stored in your caches, full stop.

The pyvorin-thin exception, stated plainly

pyvorin-thin is a separate package that submits source to a remote compile endpoint (POST /v1/thin/compile on api.pyvorin.com). Any sentence of the form "Pyvorin never uploads your code" is true of pyvorin-native and false of pyvorin-thin. If your GDPR position depends on source staying on-premises, the package name in your requirements file is the control. This page is about pyvorin-native throughout.

Telemetry: small, sampled, and narrower than most

The telemetry stream is fire-and-forget: a ring buffer capped at 1,000 events, flushed in batches of 50 or at five-minute intervals, with a five-second timeout and silent failure. The event vocabulary is fixed and small:

A captured batch looks like this: {"v":"1.0","session":"9ad3dbb7-…","privacy":"standard","abuse_score":0,"events":[{"t":…,"e":"compile","p":{"time_ms":1.0},"s":…}]}. The parameters field carries timing and event properties; nothing in the envelope carries source text, file paths beyond event context, variable values, or output data. The session identifier is the first sixteen characters of a UUID, regenerated per process, so it correlates events within one run and nothing more.

Three privacy levels exist: standard (the default above), minimal (security events only) and disabled. Here is the honest wrinkle: the opt-out is an in-process API call — pyvorin._telemetry.set_privacy("disabled") — or developer mode. There is no environment variable and no config-file switch. An earlier draft suggested pyvorin telemetry off; no such command exists in either CLI, and quoting it in a compliance document would survive contact with an auditor for about thirty seconds. If you need telemetry off fleet-wide, wrap it: set the privacy level at interpreter start-up, or block the destination at your egress proxy. Both are one-liners in your own infrastructure, which is where this control legitimately lives.

The device fingerprint is personal data

Every licence check sends a device fingerprint computed as sha256(hostname:username:/etc/machine-id), truncated to 32 characters. It is a hash, and it is still personal data: hash inputs containing a hostname like jsmith-laptop and a username like jsmith do not resist re-identification by anyone who knows the machine naming scheme. Our own engineering judgement, and the position we recommend you adopt in your records: treat the fingerprint as pseudonymous personal data, because treating it as anonymous is the kind of technicality regulators have heard before.

What that means in practice is modest. The fingerprint exists so a licence lease cannot be replayed onto a second machine; it is not joined to usage content because there is no usage content. But it does flow to our servers in the licence-check payload, it is stored in your local licence file, and your records of processing should say so.

Local state: the data map on disk

Everything Pyvorin writes locally is enumerable, which makes the local side of a GDPR assessment pleasantly boring:

Two things worth knowing before you promise anything to a data subject. First, the compile cache is keyed by a SHA256 of the source plus function plus options — it is a derived copy of your code, sitting inside the install tree rather than in anyone's home directory. Second, the disk cache validates each entry's checksum before use, so corrupted cache entries are detected rather than executed.

Checking the claims yourself

None of the statements above requires our cooperation to verify. The licence state on any machine is inspectable with the installed CLI:

# Local licence summary — reads the file, makes no network call
pyvorin status

# The hard gate — prints the pass/fail line and the exit code
pyvorin check

On a machine with no licence, the first prints {"status": "unlicensed", "reason": "No license file found"} and the second prints License gate failed: No license found… and exits 1. To observe exactly what activation would send, point the licensing endpoint at a sink you control with the PYVORIN_LICENSE_URL override and read the request body yourself; the payload class is one JSON object with two fields. That exercise — capturing the wire format rather than trusting a table like this one — is the same one your assessor will want to run, and it takes minutes.

Erasure and access requests

The local half of erasure is deletion of the files above; there is no hidden registry and no background service holding copies. The server half is a request to us: what we hold against a key is the licence record, the device fingerprint, and the sampled event stream — no source, no payloads, nothing else. If you are subjecting our processing to a data subject request, contact us through the licensing dashboard at app.pyvorin.com and identify the licence key; that is the join key on our side. Whether your organisation needs a data processing agreement with us, and on what terms, is a question we will not answer on this page — that is what your legal team and ours are for. What we will not do is claim a DPA exists when we cannot show you one.

What this page deliberately does not claim

For teams running a DPIA, the shape of the processing is conventional: a development tool on developer machines, with a small outbound stream to a single vendor endpoint and no automated decision-making, no profiling, and no special-category data in the payloads themselves. The residual risks live where they always live in this class of tool: source files can contain personal data as string literals (they stay local, but they are still your responsibility), and the licence file plus fingerprint make a machine identifiable to us. Pyvorin is not "GDPR compliant", and no toolchain can make you compliant; it provides the data flows described above, which you can assess. We hold no certification covering data protection for this product as of 1.0.9. And telemetry is not an audit log — it is a 1%-sampled, fire-and-forget event stream whose design goal is that losing it changes nothing, so do not build accountability records on it.

The assessment that survives contact with the artefact is narrower and more useful than a badge: under pyvorin-native, the personal data leaving your machines is a licence key, a pseudonymous device fingerprint, and sampled event metadata; your source stays with you; and every sentence in this paragraph is checkable against the binary on your own disk.

Where to go next

• Security and source privacy — the full network-surface and payload inventory this page draws on.
• Activation and entitlement — the licence check, the lease, and the device fingerprint in detail.
• Network requirements — endpoints, ports, and the environment overrides for redirecting traffic.
• Protected component delivery — how the package verifies itself before it runs.

Last reviewed 3 February 2026 against pyvorin-native 1.0.9 installed at /root/pvfinal: endpoints and payloads captured by intercepting the HTTP layer at runtime; telemetry envelope quoted from a captured batch; local paths confirmed on a clean HOME. Server-side retention practices are outside what we can verify from the artefact and are not claimed here.