The Vendor Disclosure Gap On psychological contracts, timeline opacity, and the limits of researcher good faith Stuart Thomas Independent Security Research — Whitby, North Yorkshire, United Kingdom 13 May 2026 · ORCID: 0009-0008-4518-0064 · CC BY 4.0 This essay accompanies the public disclosure of two vulnerabilities in macOS ( PING-01 and SMB-01A ), both filed with Apple Security Bounty in April 2026 and both confirmed by Apple with a "Fall 2026" fix timeline. It examines the implicit contract between security researchers and vendors, describes what happens structurally when that contract is honoured in letter but not in spirit, and sets out the reasoning behind disclosing ahead of the vendor's scheduled window. It is not a grievance. It is an account. 1. The Implicit Contract Responsible disclosure rests on an unwritten agreement. A researcher who finds a vulnerability in a vendor's product could, in principle, sell it, publish it immediately, or sit on it indefinitely. Instead, they notify the vendor privately, hold back technical detail, and wait. In exchange, the vendor acknowledges receipt, engages with the technical substance, fixes the issue within a reasonable window, and — eventually — either credits the researcher or at minimum does not treat their restraint as an invitation to delay without limit. The political philosopher would call this a psychological contract : a set of mutual expectations that are implicitly understood by both parties even though they are nowhere formally recorded. 1 The researcher's obligations under this contract are clear and voluntarily accepted: confidentiality, good faith, time. The vendor's obligations are less formally articulated, which is precisely where the contract breaks down. “The researcher's obligations under this contract are voluntarily accepted. The vendor's obligations are less formally articulated — which is precisely where the contract breaks down.” Most disclosure frameworks describe the vendor's side in terms of process : acknowledge within N days, provide status updates, ship a fix. What they rarely describe is substance : engage with the technical argument; give the researcher a credible reason, not just a placeholder; treat the submission as an input to engineering rather than as a legal liability to be managed. When vendors honour the process while ignoring the substance, the psychological contract is technically intact and operationally broken. 2. What "Fall 2026" Means Apple's current response to confirmed security findings is to assign them to a seasonal release cycle. "Fall 2026" means September or October 2026 at the earliest. Filed in April 2026, that is a six-month window from initial report to public patch — not for a critical zero-click remote-code-execution vulnerability, but for a local BSS write primitive in /sbin/ping and a network-reachable resource exhaustion in smbd . Six months is not unreasonable for a complex systemic vulnerability in a shipping OS. It is not obviously reasonable for a missing bounds check that requires a one-line fix and whose exploit primitive is limited to local, unprivileged, deterministic, non-escalating state corruption. The researcher is expected to sit on technical detail for six months while the vendor decides, at their own pace, whether to move the fix to an earlier release. The follow-up exchange on 13 May 2026, for the PING-01 case, produced this response from Apple: “We have reproduced this report and are continuing to investigate. No additional information is needed from you at this time.” This sentence is carefully constructed. It confirms that the vendor has everything they need. It does not engage with the technical argument. It does not offer a narrower timeline. It does not explain whether the Fall 2026 date is a floor or a ceiling. It closes the conversation politely and completely, from the vendor's side, while leaving the researcher in an indefinite holding state. This is not a complaint about the individuals at Apple Product Security, who are professional and prompt in acknowledgement. It is an observation about the system in which they operate: seasonal release cycles create a structural incentive to defer confirmed bugs to the next available window rather than to ship point fixes, regardless of severity. 3. The 90-Day Norm Google Project Zero established the 90-day disclosure deadline in 2014 after observing that indefinite vendor-controlled windows were being abused to delay fixes for years. 2 The 90-day limit is not an arbitrary number: it is long enough for a competent engineering team to produce a fix for most vulnerability classes, and short enough to prevent the normalization of permanent researcher silence as the default outcome. Project Zero's data, published annually, shows that the 90-day standard works : the median fix time for vulnerabilities disclosed under a deadline is substantially lower than the median fix time under indefinite "responsible disclosure" norms. 3 The dead...