# Private Discovery Between People
# Book: Language
# Chapter URL: https://programmer.ie/books/language/35-chapter/
# Prose fingerprint (sha256, normalized): 127306575ec46a2b8e241c4b4d0c6ce9bc3d2eca2d17765f2e2ef4390619793f
# Snapshot generated at build time by Hugo. This is the complete rendered prose
# of the chapter; it is not a transcript of the source file.

Iris has been chasing a failure in her protocol for three weeks: an intermittent split vote under clock skew that, in this constructed case, she can reproduce 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 rely on 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 merely to discover whether a suitable counterpart exists.
Chapters 32 and 33 established that a proxy needs authority for its actions, data use and speech. Here the proposed act is discovery. A mediator might compare purpose-limited representations before an introduction, while withholding identities and source histories from the potential counterparts until separate permissions are established. The mediator itself might still learn identities, participation and matching metadata; the design must say what that operator may see. Chapter 35’s proposed Taint view is only one possible input. Declared interests and deliberately selected evidence must remain alternatives, and 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, not a guarantee that all useful matching can be done privately. Each transition has a distinct audience, information release, authority check and failure condition.
Five stages, five separate permissions A conventional interface often collapses discovery into find someone and tell me who. That 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, and the later consent check is about whether a particular candidate relationship may proceed to identification or contact.
Proposed permission boundaries, not a demonstrated privacy guarantee. Even notifying someone that a match exists needs its own disclosure check. Open full-size diagram. A match is initially an internal candidate, not automatically a notification that a particular counterpart exists. Even telling Iris 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’s identity or confidential evidence. Identity reveal, contact and later sharing are distinct operations; a prior approval for one need not authorise the next. The stages describe an intended ordering, not a claim that a distributed service can make simultaneous identity release perfectly atomic.
Discovery should precede discretionary disclosure; permission to match must precede discovery itself.
The system should be able to compute a candidate relationship using 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 those 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 initiating contact. Nor does a broker’s permission to compare their private views imply permission to reuse the match in recruitment or elsewhere. Each later act needs independently 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 itself can communicate without exposing the counterpart prematurely; 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, but 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. The scene specifies required boundaries, 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 establishing 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 the 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, retain for the stated lifetime, compare and use that view. Mere access to an interaction history does not provide those grants. Its provenance must distinguish person, task, model, prompt and tool contributions; 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 does not make derived embeddings or distinctive feature vectors anonymous: they too may disclose or permit linkage. Scope, recipients, deletion or use cessation, and accounting for already-shared copies all remain relevant.
Chapter 33’s data-use gate and Chapter 34’s speech gate meet 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, not 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 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 one isolated person. 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, the source’s restrictions and a legitimate independent basis to disclose. The design principle is not that any party receives an unlimited veto over every fact involving them. It is that possession or one participant’s grant alone cannot 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 or 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, not a claim that the software can adjudicate 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 incentives. A mediator trusted to see private inputs is not the same security design as a cryptographic protocol intended to hide them from that 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: its specificity may itself be a probe. Filtering out prohibited purposes is necessary, but vague purpose labels should not permit the same search to be repackaged repeatedly. The consent receipt should say 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, with bounded query rates and specificity, anti-enumeration controls, abuse investigation constrained by privacy, and careful handling of accounts that repeatedly join a search under new identities. Coarsening reduces some leakage; it does not prove that composition of many answers is safe.
Privacy-enhancing cryptography offers useful precedents but not a turnkey solution. Private set intersection (PSI) can, under a specified protocol and threat model, let parties learn a defined overlap without exposing all nonmatching elements. The actual output—including intersection members or cardinality—and 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 representation, inference and leakage questions. NIST’s privacy-enhancing-cryptography material is therefore background for an implementable experiment, 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 of Chapters 26, 27, 32 and 33. It should contain rule identifiers and versions rather than private transcripts, and 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 was already 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 doubles 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 inside 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. A disclosure embedded in an otherwise approved introduction may include an unpublished detail that neither side consented to share. Even a correct match can be misleading if it reflects a shared AI template, common task wording or deliberately poisoned evidence. These failures need distinct counters and receipts; 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 explanation, and nonresponse must not be disclosed as 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 (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 evaluating. Held-out candidate pairs and participants should prevent a match explanation from merely repeating 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, not as a cost to average away against match quality. An implementation may fail because it cannot produce useful private matches or because the 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 those 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 those locally justified actions compose into an acceptable ecosystem—and how to detect when they do not.