Design domain-free, privacy-preserving behavioral sharing v2

[MahdiHedhli]

Decision

Design a new domain-free, privacy-preserving behavioral aggregation contract. This issue is a design, utility, and adversarial-review gate; it does not authorize production sharing.

For beta, behavior_summary and query-derived candidate-domain export remain disabled. Production telemetry continues to export only Core-confirmed matches to public known-bad indicators under the existing privacy-reduced contract.

The intended value of behavior_summary_v2 is fleet-level detector prevalence and SNR calibration—not discovery of new domains, per-device behavior, or remote enforcement.

Prerequisites

• Complete reporter deletion and enforced retention in [privacy ops] Define reporter deletion and retention for opt-out installations #42. A new protocol must not inherit indefinite reporter, counter, or aggregate storage.
• Fix [telemetry privacy] Gate export on persisted suppression disposition #98 so Core's persisted suppression disposition is honored by the current telemetry export gate.
• Use Research: privacy-exposure and behavioral signals after findings fusion #67 to identify locally useful behavioral signals and measure their false-positive contribution before freezing the shared vocabulary.
• Preserve the accepted advisory-only Sybil posture: cohort size and valid credentials are not proof of independent people, households, or operators.

Contract requirements

Define a versioned behavior_summary_v2 as a fixed-shape report containing only:

• a common signed task/schema manifest and version;
• fixed public behavior/detector enums;
• clipped, bounded counters or documented count buckets;
• fixed, coarse, non-overlapping collection epochs;
• fixed evidence/outcome categories only where the utility study shows they are necessary.

The report and every intermediate representation must have no field capable of carrying:

• a domain, query, URL, IP, MAC, hostname, device/sensor/install ID, event/finding/rule ID, or source hash;
• a keyed or unkeyed hash of a private or enumerable observable;
• exact event timestamps or per-device/per-household activity history;
• arbitrary tags, labels, metadata, URLs, headers, or free-form text;
• client-selected task parameters that could partition the anonymity set.

Unknown fields and unknown enum values fail closed. Consumers recompute verdicts locally. A community aggregate is advisory context only and cannot independently create, suppress, resolve, or change the priority of a finding.

Threat model and architecture

Document protected information, trust boundaries, observable metadata, and collusion cases for:

• Core/client, eligibility issuer, OHTTP relay, leader/helper aggregators, feed consumer, dashboard, and operator;
• malicious/compromised clients, Sybil operators, curious infrastructure, colluding parties, network observers, and malicious feed consumers;
• timing/volume linkage, replay/double spend, differencing, low-cohort inference, targeted task partitioning, poisoning, and auxiliary-data re-identification.

The design must state what Cloudflare, each protocol role, and the Vedetta operator can observe. It must specify contribution bounds, cohort/release rules, retention, deletion, opt-out, privacy accounting, collection limits, schema rollback, and collection/publication kill switches.

Architecture constraints:

• Privacy Pass-style credentials may provide unlinkable authorization and contribution bounds; they do not prove one credential equals one independent household or solve Sybil attacks.
• OHTTP can separate client addressing from request content only under the stated non-collusion assumptions. The gateway still decrypts the application message; payload minimization, common padding, fresh contexts, timing controls, and identifier stripping remain required.
• Consider Prio/VDAF/DAP only with a genuinely independent, non-colluding second operator and a pinned, independently reviewed protocol version. DAP is still an Internet-Draft.
• Cohort thresholds alone are not differential privacy. Do not claim DP without a specified mechanism, privacy-budget ledger, and review of repeated releases.
• TPM attestation does not solve household linkage, privacy, or the fundamental Sybil limitation.

Staged delivery

1. Utility and local shadow mode: define the fixed vector, keep every report local, and prove that the aggregate would materially improve SNR using synthetic or explicitly consented data.
2. Synthetic transport pilot: test unlinkable authorization, independent OHTTP relay behavior, fixed-size envelopes, replay controls, batching, delayed delivery, and kill switches using synthetic canaries only.
3. Private aggregate beta: permit real reports only after the independent-helper, retention/deletion, contribution-bound, privacy-accounting, and red-team gates pass. No raw or below-cohort reports are exposed in the dashboard/API.
4. Advisory release: publish only delayed, cohort-safe aggregates or bands with signed provenance, schema version, expiry, and rollback. Validate useful local interpretation before any scoring experiment.

Acceptance gates

• Approved data dictionary, canonical examples, compatibility policy, data-flow diagram, collusion matrix, and retention/deletion schedule.
• Structural tests, property tests, and fuzzing reject every forbidden/unknown field in the producer, relay/gateway boundary, aggregator, storage, and dashboard.
• No server surface can reconstruct reporter-to-contribution or household/device history under the documented non-collusion assumptions.
• Enforced one-report/task/epoch bounds, replay/double-spend rejection, fixed manifests/padding, delayed batching, collection limits, and exercised kill switches.
• No arbitrary dashboard slicing, overlapping releases, exact small cells, or below-cohort visibility that enables differencing.
• Re-identification, timing, differencing, replay, task-partitioning, Sybil, malformed-report, and semantic-poisoning red team.
• Measured SNR/utility gate with a documented holdout and no increase in missed high/critical detections.
• Public disclosure accurately describes consent, residual metadata, protocol assumptions, retention, opt-out, and the advisory-only trust limit.
• Independent cryptographic/privacy review clears the exact deployed design before real-data implementation.

Out of scope

• Query-derived candidate domains or arbitrary private-heavy-hitter discovery.
• Uploading local suppression/whitelist rows or free-form operator feedback.
• Community false-positive/domain nominations and a curated benign-context corpus; tracked separately in Design privacy-safe community false-positive nominations and curated benign context #99.
• Community device-fingerprint submissions under Community device-fingerprint database (network/IoT) with temporal versioning #52.
• Per-device, per-household, regional, or real-time community analytics.
• Automatic enforcement, blocking, whitelisting, suppression, or finding disposition changes.

The work in #99 may reuse a successful transport architecture, but it requires its own schema, explicit consent, poisoning analysis, curation model, and privacy review because it can be domain-bearing.

Standards references

• Privacy Pass architecture (RFC 9576)
• Oblivious HTTP (RFC 9458)
• Distributed Aggregation Protocol, current Internet-Draft
• NIST guidance on evaluating differential privacy guarantees

[MahdiHedhli]

Piggybacking off this, we should leverage community efforts for aggregating suppression signals so that when multiple users are suppressing similar patterns we add the indicators to a list for evaluation and potentially adding to our known good/whitelist for improved SNR and reduced reported false positives.

[MahdiHedhli]

Reviewed and accepted as a product direction, with a necessary boundary: repeated suppressions are nomination evidence, not proof that an indicator is benign, and they must never auto-promote into a whitelist or weaken strong IOC/IPS evidence.

I split the domain-bearing workflow into #99. That issue defines explicit per-item nomination, fixed reason codes, privacy-safe aggregation, curator review, scoped/expiring benign context, provenance, rollback, and Threat Network dashboard requirements. Local suppression/whitelist rows are never uploaded directly.

#57 is now finalized around the domain-free behavior_summary_v2 contract and its utility/privacy/adversarial-review gates. I also filed #98 for a current prerequisite discovered during the trace: Core persists suppression as a disposition, but telemetry currently checks only for a tag Core does not add. This does not expose raw query names under today's beta gate, but it must be corrected before either future sharing path proceeds.

[MahdiHedhli]

Ratified

The design proposal in this issue — the domain-free behavior_summary_v2 contract, its no-carriable-field requirements, the threat model and architecture constraints, the staged delivery, and the acceptance gates — is accepted as the required path for any future privacy-preserving behavioral aggregation.

To be explicit about scope, consistent with the issue text:

• This ratifies the design and gate framework. It does not authorize production sharing. behavior_summary and query-derived candidate-domain export remain disabled; production telemetry continues to export only Core-confirmed public known-bad matches under the existing privacy-reduced contract.
• The prerequisites ([privacy ops] Define reporter deletion and retention for opt-out installations #42 reporter deletion/retention, [telemetry privacy] Gate export on persisted suppression disposition #98 suppression-disposition gate, Research: privacy-exposure and behavioral signals after findings fusion #67 local signal utility) and every acceptance gate — including the independent cryptographic/privacy review of the exact deployed design — remain to be satisfied before any real-data implementation.
• Scope is unchanged: community device-fingerprint submissions (Community device-fingerprint database (network/IoT) with temporal versioning #52) and false-positive / benign-context nominations (Design privacy-safe community false-positive nominations and curated benign context #99) stay separate tracks, each requiring its own schema, explicit consent, poisoning analysis, and privacy review.

Staying open to track the prerequisites and acceptance gates.