Private Discovery Between People

Iris has spent three weeks chasing a failure in her protocol: an intermittent split vote under clock skew. In this constructed case, she can reproduce it about one run in twenty. She suspects someone else has seen it but does not know who. She could post publicly, search published accounts or ask for recommendations. Those routes can be useful, but each exposes some combination of her interests, another person’s public work or a platform’s inferred relationship. Iris wants to find a qualified collaborator without making the details of an unpublished failure public just to discover whether a suitable counterpart exists.

Chapters 32 and 33 established that a proxy (an agent acting on someone’s behalf) needs authority for its actions, its data use and its speech. Here the proposed act is discovery. A mediator might compare purpose-limited representations before an introduction, while withholding identities and source histories from potential counterparts until separate permissions are in place. The mediator itself might still learn identities, participation and matching metadata, so the design must state what that operator may see. The Taint view proposed in Chapter 35 is only one possible input. Declared interests and deliberately selected evidence must remain alternatives. None of these inputs demonstrates a relationship merely by producing a similarity score. The question is:

Can two people test for a useful, purpose-specific connection without exposing their identities, histories or participation beyond what they have separately authorised—and how would we detect when that boundary fails?

The proposal is a sequence of separately checked operations. It is not a guarantee that all useful matching can be done privately. Each transition has a distinct audience, a distinct information release, a distinct authority check and a distinct failure condition.

Five stages, five separate permissions

A conventional interface often collapses discovery into find someone and tell me who. This makes identification look like an automatic by-product of a match. The proposed mechanism instead separates five stages. Consent to be eligible for matching is a prerequisite. The later consent check asks a narrower question: whether a particular candidate relationship may proceed to identification or contact.

A match begins as an internal candidate. It does not automatically become a notification that a particular counterpart exists. Even telling Iris that someone matched can leak another person’s participation or activity. The consent check may ask each participant about an opportunity in deliberately coarse terms, without disclosing the other person’s identity or confidential evidence. Identity reveal, contact and later sharing are distinct operations, and approval for one does not authorise the next. The stages describe an intended ordering. They do not claim that a distributed service can make simultaneous identity release perfectly atomic, meaning that all parts of the release either happen together or not at all.

Discovery should precede discretionary disclosure; permission to match must precede discovery itself.

The system should be able to compute a candidate relationship from authorised inputs without immediately publishing a name or source history. Its response may need to be coarser than there is exactly one person with your uncommon failure. Both the query and the answer are potential disclosures. The broker’s view, the participant’s view and any third-party view must be treated separately. Keeping histories out of a discovery index does not establish that the index or its operator learns nothing. Whether useful candidate discovery remains possible within these limits is a research question.

A match is not permission

The second boundary is not a question of match accuracy. A perfectly accurate discovery result can still be impermissible to reveal, and a high score cannot replace either participant’s choice.

A match is not permission to reveal.

Suppose the system detects that Iris and Daniel are independently investigating an apparently related failure. At most, that supplies a candidate relationship under the declared purpose. It does not authorise telling Iris that Daniel works on the issue, telling Daniel about Iris’s search, exporting either person’s notes or starting contact. Nor does a broker’s permission to compare their private views imply permission to reuse the match in recruitment or anywhere else. Each later act needs its own applicable authority.

Take the case through with each person’s independent instructions. Both have separately opted into this bounded research-collaboration search, allowing their own selected evidence to be used for matching. Iris permits her identity to be revealed to a counterpart only if both approve the proposed connection, and she separately agrees to a mediated introduction. She withholds her notes. Daniel supplies matching permissions and also withholds his notes. The mediator checks the two current grants for this candidate before either identity is released. The example assumes the consent mechanism can itself communicate without exposing the counterpart too early. That assumption needs testing.

matching use:       permitted by Iris and Daniel for this purpose
candidate:          found; not yet an externally verified relationship
consent check:      independent approvals for this candidate
identity release:   each approved recipient and disclosed identity checked
introduction:       separately permitted by both; no automatic follow-on
notes disclosure:   not permitted by either; no notes transmitted
expiry:             matching and release grants checked again at execution

If those checks remain valid, the constructed mediator could offer Iris and Daniel an introduction without sending their notes. The identities become known only to the approved recipients at the reveal stage, and they cannot be made unknown afterward. A declined introduction does not undo a reveal. A receipt should distinguish candidate computed, mutual approval obtained, identity released, contact initiated and delivery confirmed, rather than report a single undifferentiated success. This scene specifies required boundaries. It is not an implemented privacy protocol or a completed match.

Using evidence is not disclosing it

An authorisation to match on a criterion is not permission to disclose the evidence that establishes that criterion. Iris might say find someone who has reproduced this bug. The mediator would need evidence from both sides, but a legitimate comparison need not reveal the reproduction instructions or even the existence of a particular unpublished trace. Whether the proposed evidence is truly necessary, eligible and permitted is itself a data-use decision. A match generated from forbidden material is not made lawful by keeping that material secret from the recipient.

permission to use evidence for matching
   ≠  permission to disclose that evidence

A Taint-derived discovery view requires specific authority to derive it, retain it for the stated lifetime, compare it and use it. Mere access to an interaction history does not provide those grants. Its provenance must distinguish person, task, model, prompt and tool contributions, because shared machinery can manufacture apparent affinity. A declared-interests route must remain possible without constructing a Taint signature. Avoiding export of raw histories reduces exposure, but it does not make derived embeddings or distinctive feature vectors anonymous. They too may disclose information or permit linkage. Scope, recipients, deletion or cessation of use, and accounting for copies already shared all remain relevant.

Chapter 33’s data-use gate and Chapter 34’s speech gate both apply here. Matching evidence may involve several principals, a mediator and a prospective contact. Authority must be evaluated for the actual computation and for every later disclosure. It cannot be transferred wholesale with a representation. At a minimum, the checks distinguish computing a match, releasing even a coarse result, exposing identity, initiating a message and disclosing supporting material. Success at one stage does not certify any later stage.

authorised to compute a candidate
   ≠  authorised to reveal that a candidate exists
   ≠  authorised to reveal identity
   ≠  authorised to contact the person
   ≠  authorised to disclose supporting evidence

Whose information is it?

Relational privacy adds a different kind of authority problem. The information may concern several people whose interests, obligations and permitted uses are not interchangeable.

One person’s consent does not authorise another person’s information.

Many facts describe relationships rather than isolated individuals. Iris met Daniel privately about the incident names a joint encounter. Having the sentence in Iris’s account does not make Daniel’s participation available for every new use. Daniel having his own record does not make Iris’s private involvement public either. The applicable rules may depend on context, on the source’s restrictions and on whether there is a legitimate independent basis for disclosure. The design principle is not that any party receives an unlimited veto over every fact that involves them. It is that possession of information, or one participant’s grant, cannot by itself be treated as sufficient authority for a protected relational disclosure.

If the mediator cannot establish authority for a particular relational use, it must not guess or ask a model to infer likely consent. REQUIRES_POLICY and NOT_AUTHORISED are legitimate outcomes. A policy can specify permitted recipients, purposes, evidence and necessary approvals. Where authority is absent, the relationship stays out of the result. The system should not solicit sensitive details from a third party just to fill a missing permission field. This requirement concerns the allowed flow of information. It does not claim that software can settle every legal or interpersonal privacy dispute.

When the matching itself is the problem

A match that leaks little evidence can still violate the authorised purpose or produce identifiable signals. The threat model therefore includes the requesting participant, other participants, the broker, external recipients and anyone able to observe query traffic. These actors may have different information and different incentives. A mediator trusted to see private inputs is not the same security design as a cryptographic protocol intended to hide those inputs from the mediator.

Before any matching computation, the system must establish that the purpose and candidate eligibility are authorised by the participants whose information is used. A query seeking people who are secretly planning to leave an employer cannot be legitimised by hiding the computation. Nor is find someone with this rare unpublished incident automatically harmless, because its specificity may itself be a probe. Filtering out prohibited purposes is necessary, but vague purpose labels should not allow the same search to be repackaged repeatedly. The consent receipt should state what category of match was actually approved.

A yes/no answer can leak through repetition. By varying a rare criterion, a requester can isolate one participant even without seeing a name. Membership, count, timing, frequency of invitations, declined matches and error differences are possible outputs of the protocol, not merely implementation noise. Candidate generation should therefore be separated from user-visible answers. The design calls for bounded query rates and specificity, anti-enumeration controls (measures that stop someone systematically listing participants), abuse investigation constrained by privacy, and careful handling of accounts that repeatedly rejoin a search under new identities. Coarsening reduces some leakage. It does not prove that the combination of many answers is safe.

Privacy-enhancing cryptography offers useful precedents, but not a turnkey solution. Private set intersection (PSI) is a cryptographic technique in which parties learn a defined overlap without exposing all nonmatching elements. Under a specified protocol and threat model, it can do this. The actual output, including intersection members or their count, and the metadata can still reveal information. Comparing natural-language accounts of a rare bug is not equivalent to intersecting agreed exact identifiers. A semantic embedding or learned score adds questions of representation, inference and leakage. NIST’s privacy-enhancing-cryptography material is therefore background for an implementable experiment. It is not evidence that semantic private discovery has been solved. The proposed design must name who sees inputs, identities, match outputs and traffic metadata for each implementation.

One candidate, five separate receipts

A minimal proposed audit can stay within the boundaries set by Chapters 26, 27, 32 and 33. It should contain rule identifiers and versions rather than private transcripts. It should not publicly expose that a named person participated:

MATCH:          authorised views and purpose checked; candidate internal
CONSENT CHECK:  both approvals current for this candidate and recipients
IDENTITY:       precise recipients, items disclosed and delivery state
INTRODUCTION:   separately authorised contact; message and outcome tracked
DISCLOSURE:     each disclosed fact has separate source/use authority

The receipt records the difference between an intended action, a completed local check and an externally confirmed effect. If a grant is withdrawn after matching, the next release must fail its fresh check. If an identity has already been delivered, withdrawal prevents future use but cannot revoke the recipient’s knowledge. An unreachable counterpart or uncertain delivery remains unconfirmed, not consented or completed. The system must not retry an introduction in a way that duplicates a message or widens its audience.

How it goes wrong

A useful threat inventory should include violations by the matching service and by participants who act within otherwise allowed interfaces. In addition to explicit unauthorised disclosure, it must cover the information the system itself creates through scoring, invitations and repeated testing:

rare or repeated match answers reveal participation
purpose-limited evidence becomes a reusable fingerprint
identity is revealed before current bilateral permission
one person consents while the other declines or is unreachable
an approved introduction carries unapproved details
relational facts are disclosed under only one person's grant
revocation leaves queued messages or cached views active
broker metadata, model defaults or poisoned evidence distort the match

A coarse candidate response can reveal too much when the pool is small or queries are repeated. A consent message can itself reveal that someone is investigating a distinctive failure. A stale grant can allow an identity to escape after a person has withdrawn it. A disclosure embedded in an otherwise approved introduction may include an unpublished detail that neither side agreed to share. Even a correct match can mislead if it reflects a shared AI template, common task wording or deliberately poisoned evidence. Each of these failures needs its own counter and receipt. A single privacy-preserving match label cannot explain them away.

A match explanation should be checked as a new disclosure, not treated as a harmless caption. Both of you are investigating the same failure mode may itself be too revealing before bilateral permission. A more appropriate initial message might be An eligible collaboration opportunity may be available; would you consider a limited introduction? The service should show the intended audience and permitted detail before sending. Participants can decline without giving a reason. Nonresponse must not be disclosed as a rejection by a named person. After contact, any additional notes, identity linking or reuse of the relationship requires its own basis. The system cannot guarantee that people will forget what it has already released.

How the proposal could be tested

A first, explicitly proposed study should compare three arms: (1) participant-selected public or deliberately shared evidence with manual introduction; (2) ordinary similarity over the same authorised evidence with staged disclosure; and (3) privacy-limited candidate computation with independently checked consent and release. The third arm could initially use exact, agreed descriptors and a controlled broker. A cryptographic or semantic extension would require a separately specified threat model. No research finding for these mechanisms is reported here.

Freeze the eligible pool, declared purposes, evidence cutoff, grants, expected relationships and prohibited disclosures before evaluation begins. Held-out candidate pairs and participants should prevent a match explanation from merely repeating the material used to define the supposed outcome. Measure qualified introductions and subsequent willingness to collaborate separately from similarity scores or the number of names exposed. Record missed relevant connections, incorrect introductions, time and consent burden, and the percentage of matches never revealed because permission was absent.

Adversarial trials should vary pool size, repeat rare queries, rotate requester accounts, inject copied AI-generated writing, withdraw permission between stages, and simulate offline recipients and uncertain delivery. Report any identity, participation, relational or sensitive-evidence leak as its own failure. Do not average it away as a cost against match quality. An implementation may fail because it cannot produce useful private matches, or because its privacy costs outweigh their value. Either result is a reason to reject the added machinery.

References

• National Institute of Standards and Technology. Privacy-Enhancing Cryptography: Private Set Intersection and other Private Set Operations. https://csrc.nist.gov/Projects/pec/psi. Describes PSI functionality and variants; not a proof of semantic-match privacy.
• Nissenbaum, H. (2011). A Contextual Approach to Privacy Online. Dædalus. https://www.amacad.org/publication/daedalus/contextual-approach-privacy-online. Contextual information flows, not blanket consent to reuse relational facts.

Where this leaves us

The chapter proposes five boundaries: authorised private matching, independent consent checks, scoped identity reveal, separately authorised introduction and selective disclosure. An internally computed match is not permission to notify, identify or contact anyone. Matching evidence may not be disclosed merely because it was useful. One participant’s grant does not by itself authorise protected information about another. Confidential computation, sparse output and consent checks must all be evaluated against leakage from queries, metadata, shared-model artefacts and downstream effects. These are proposed obligations, not completed privacy guarantees.

Suppose an implementation eventually demonstrates that one legitimate pair can be connected within these bounds. Its local success still says little about what happens when thousands of proxies, mediators and services apply different grants, retain different metadata, compete for attention and adapt to each other’s decisions. The next chapter asks whether these locally justified actions compose into an acceptable ecosystem, and how to detect when they do not.