Client-Side Execution Architecture: Privacy-Preserving Variance Computation on Device

Mechanism

The client-side execution path begins at the moment content is captured, generated, or imported on a device. A deterministic variance extractor consumes the raw content in its native representation and produces a fixed-dimension vector summarizing the structural features of the content. The extractor is specified precisely enough that any conforming implementation, given the same input bytes, will produce a bit-identical output vector; this determinism is the foundation on which all subsequent verification rests, because a verifier who recomputes the vector locally must arrive at exactly the same value as the producer.

Once the variance vector has been computed, the device assembles an anchor record consisting of the vector, a content-type tag, a timestamp drawn from a monotonic local clock, a reference to the prior anchor in the device's lineage if one exists, and a signature produced by a key held in the device's hardware-backed key store. The anchor record is then published; the raw content is not. The publication channel may be a peer-to-peer broadcast, a write to a content-addressable store, or an entry in an append-only log, depending on deployment, but the channel never receives the underlying content.

Verification is symmetric to production. A verifier in possession of a candidate piece of content and a published anchor recomputes the variance vector locally using the same deterministic extractor, checks the recomputed vector against the vector embedded in the anchor, and validates the signature against the producer's public key. A match establishes that the content the verifier holds corresponds to the content the producer anchored; a mismatch establishes that the content has been altered, substituted, or never originated from the claimed producer. No party other than the verifier needs access to the content during verification, and no party other than the producer needs access to the content during anchoring.

Because the variance extractor operates on the device, the architecture inherits whatever access controls the device imposes on the content. A photo that never leaves a camera roll can be anchored without exposing its contents to the network; a document held under disk encryption can be anchored without decrypting it for transmission; a stream produced on an air-gapped device can be anchored locally and have its anchor exfiltrated through any narrow side channel sufficient to carry the small anchor record. The privacy property is therefore not a policy layered on top of the architecture but a structural consequence of where the computation happens.

The bandwidth property follows from the same structural fact. The anchor record is bounded in size by the dimension of the variance vector plus a small constant for metadata and signature; for typical configurations this total is measured in hundreds of bytes regardless of whether the underlying content is a kilobyte text file or a multi-gigabyte video. The cost of provenance is therefore decoupled from the size of the content, which makes anchoring practical for content classes where transmitting the raw bytes would be prohibitively expensive.

Operating Parameters

The variance extractor is parameterized by a vector dimension, a feature basis, and a quantization rule. The dimension is fixed across a deployment so that anchors are interoperable; typical deployments use dimensions in the hundreds to low thousands, balancing discriminative power against anchor size. The feature basis determines which structural properties of the content contribute to the vector and is chosen to be invariant to representational nuisances such as container format, compression artifacts within a declared tolerance, and lossless transcoding, while remaining sensitive to substantive content changes.

Quantization reduces continuous extractor output to a discrete vector whose entries are stable under bit-level perturbations of the input that fall below a declared sensitivity floor. The sensitivity floor is a deployment parameter: a strict deployment will treat any pixel-level change as a different anchor, while a lenient deployment will tolerate transcoding within a defined envelope. The choice is exposed to operators rather than fixed by the architecture, because the appropriate floor depends on the threat model and the content class.

The signing key is held in a hardware-backed key store wherever the device platform provides one. Key rotation is supported through a lineage-based mechanism in which a new key is introduced by an anchor signed under the prior key, allowing verifiers to follow the key history without requiring an external directory. Devices without hardware key stores fall back to software-protected keys with the consequence that the privacy property is preserved but the non-repudiation property weakens to the strength of the software protection.

Local clock skew is bounded by requiring monotonicity within the device's anchor lineage; absolute time is not required for verification, only for ordering within the lineage. Deployments that require absolute time anchoring incorporate periodic attestations from a trusted time source, with the attestation itself being anchored so that the time claim becomes part of the lineage rather than a separate trust assumption.

Anchor publication is rate-limited at the device to prevent flooding and is back-pressured by the publication channel. A device temporarily unable to publish accumulates anchors in a local queue and emits them in order when the channel becomes available; the lineage chain ensures that no anchor produced during a partition is lost or reordered relative to its peers.

Alternative Embodiments

In one embodiment, the variance extractor runs in a WebAssembly module executed inside a browser at the moment a user captures or uploads content, with the resulting anchor published through the page's normal network channels and the raw content never leaving the page context. In another, the extractor runs inside a mobile operating system framework that exposes anchoring as a system service to applications, so that any application capturing content can request an anchor without itself handling key material. In a third, the extractor runs inside a dedicated coprocessor on a capture device such as a camera, with the anchor produced before the content reaches the device's main processor.

Verification embodiments include in-browser verifiers that recompute the vector against a candidate file the user has selected locally, command-line verifiers used in archival pipelines, and embedded verifiers in distribution platforms that check incoming content against published anchors before accepting it for redistribution. The verifier may operate fully offline, since all material required for the check is local to the verifying party once the anchor has been obtained.

The publication channel may be a public append-only log, a private permissioned ledger, a peer-to-peer gossip network, or a direct point-to-point exchange. The architecture is indifferent to the channel because the anchor's integrity is established by the signature and the lineage chain rather than by any property of the channel.

Composition with Other Architectural Primitives

Client-side execution composes with quadrant decomposition by allowing region-specific anchors to be produced on the same device pass, so that the privacy and bandwidth properties extend uniformly to sub-region fingerprints. It composes with the lineage substrate by providing the per-device anchor stream as the input to higher-level lineage aggregators, which can sequence anchors across devices without ever needing access to the content. It composes with policy enforcement by allowing acceptance criteria at distribution points to be expressed in terms of anchor provenance rather than content inspection, which preserves the privacy property end-to-end.

The architecture also composes with selective disclosure mechanisms: a producer who later wishes to disclose content to a specific verifier can do so out-of-band, with the verifier confirming the disclosed content against the previously published anchor. The anchor remains the public commitment; the content remains under the producer's control until and unless the producer chooses otherwise.

Prior-Art Distinction

Conventional content provenance approaches rely on metadata tags such as EXIF or XMP fields, on visible or invisible watermarks embedded in the content, or on centralized registries that hold copies or summaries of the content for later comparison. Metadata is trivially strippable and therefore offers no structural guarantee; watermarks alter the content and degrade in the presence of transcoding, cropping, or adversarial removal; centralized registries require the content to leave the producing device, which contradicts the privacy property, and require the registry to be available at verification time, which contradicts the offline-verification property. Hash-based content addressing, while offering integrity, requires bit-exact preservation and breaks under any of the representational changes that the variance extractor is designed to tolerate.

Perceptual hashing schemes share the goal of stability under nuisance transformations but typically run server-side against uploaded content, which forfeits the privacy property, and are not bound to a producer-signed lineage that carries through key rotation and partition. The architecture described here differs by performing the extraction on-device, signing the output under hardware-backed keys, chaining anchors into a lineage that survives key rotation, and exposing verification as a fully local computation against material already in the verifier's possession.

Disclosure Scope

The mechanism is disclosed in support of US 63/808,372, "Content Anchoring Through Structural Variance Analysis." The disclosure encompasses the on-device variance extraction discipline, the anchor record format and signing protocol, the lineage chaining mechanism that supports key rotation and partition recovery, the symmetry between production and verification computation, and the deployment parameters that govern dimension, sensitivity, and publication. Embodiments that vary the host platform, the extractor implementation, or the publication channel remain within scope so long as anchoring is performed on the originating device, the raw content is not required for verification, and the anchor is bound to the producer through a hardware-backed or equivalently protected signature.

Licensing inquiries and implementation guidance are available through the publication channels referenced above. The disclosure is intended to support both defensive publication and active prosecution, and is offered without warranty as to fitness for any particular deployment.

The disclosure further contemplates the operational practices that make the on-device discipline durable across heterogeneous deployment environments. A reference implementation specification fixes the byte-level serialization of the variance vector, the canonical ordering of metadata fields prior to signing, the exact rounding behavior of the quantizer, and the procedure for handling boundary cases such as zero-length content, content shorter than the extractor's minimum input, and content whose declared canonical extent disagrees with its observed bytes. Each of these specifications is necessary because the symmetry between production and verification depends on bit-identical recomputation, and any unspecified corner of the extractor pipeline becomes a divergence opportunity that could undermine verification. The reference specification is therefore part of the disclosed scope, alongside the higher-level structural commitments, because the structural guarantee is only as strong as the lowest-level determinism that supports it. Conformance test vectors covering the corner cases above are likewise contemplated as part of the deployment package so that independent implementations can be audited for compatibility before they are admitted to a production federation.