Thank you for confirming this, and for checking the request UUID. That answers the question we had been unable to resolve on our own: we are in Approved, not Successfully Onboarded. Our request was approved three weeks ago and has not moved since. Meanwhile the app is live and the extension ships in it, so the situation on our side is: | Measured today | Devices | | Active paying subscribers | 357 | | Devices that ever reached our PIR service | 83 | | Devices able to query today | 18 | Those 18 are not evidence that anything works. In the related GitHub thread, karulont explained that a device on a full-tunnel VPN currently skips OHTTP and connects directly, that this is a bug, and that it will be fixed in a future OS release. We reproduced that exactly, as an A/B on one device minutes apart: VPN on, the query reaches us and the caller name appears; VPN off, nothing reaches us at all. So every working user we have is working by accident, and when that fix ships the number becomes zero. The useful part of that test is that it proves our deployment is correct end to end. When a device does reach us, Privacy Pass issuance, configuration, evaluation keys and the PIR query all work and return the right answer. There is nothing left for us to fix or to test. Two requests, if you are able to help with either: Is there any way to expedite the move from Approved to Successfully Onboarded, or to find out what it is waiting on? We have no visibility into it and no contact who can tell us. Whatever you learn about how a provider is meant to discover this state, we would be glad to see documented. We spent months assuming the fault was ours. We are not asking for the OHTTP bug to be left in place. We are asking for the correct path to be available before the fix removes the accidental one, because at that point subscribers who have paid for this feature since launch will have no way to use it at all.

Update: A/B experiment on the same device, three minutes apart To rule out anything on our side, we injected a known record into our live PIR corpus, reprocessed the affected shard, restarted the service, and then placed a real incoming call from that number to the same test iPhone twice: once with the Xcode-signed build installed, once with the App Store build of the same version (14, build 36). Xcode-signed, 15:45:29 App Store, 15:48:07 Result POST /queries served, name shown on the incoming call screen requestData(byKeywords:shardIds:clientConfig:) → -1009 Proxies not present, but required to fail closed 0 94 Connections stamped proxy fail closed 0 47 nw_endpoint_proxy_add_config_if_applicable for our extension n/a (direct) 0 Interface Wi-Fi (en0) cellular (pdp_ip0, 5G) Server side over those same three minutes: 15:45:29 POST /queries <- Xcode build, answered, name returned 15:46:41 GET /.well-known/... <- App Store build, directory only 15:46:45 GET /.well-known/... 15:46:50 GET /.well-known/... (nothing else, ever) Everything is held constant except the code signature: same device, same iOS build, same Apple ID, same corpus record, same backend, same calling number, minutes apart. The failure is not limited to token acquisition. Three different endpoints across two hosts fail with the same proxy error: NSErrorFailingURLKey=https://<our-pir-host>/queries NSErrorFailingURLKey=https://<our-pir-host>/config NSErrorFailingURLKey=https://<our-issuer-host>/token-key-for-user-token Full error, the lookup call itself, on cellular: requestData(byKeywords:shardIds:clientConfig:) threw an error: Error Domain=NSURLErrorDomain Code=-1009 "The Internet connection appears to be offline." UserInfo={_NSURLErrorNWPathKey=satisfied (Path is satisfied), interface: pdp_ip0[endc_sub6], ipv4, dns, expensive, uses cell, estimated upload: 524288Bps, estimated download: 8388608Bps, LQM: minimal, NSErrorFailingURLKey=https://<our-pir-host>/queries, NSUnderlyingError={Error Domain=NSPOSIXErrorDomain Code=50 "Network is down"}, _NSURLErrorPrivacyProxyFailureKey=true, NSLocalizedDescription=The Internet connection appears to be offline.} And the same on Wi-Fi with a healthy link: interface: en0[802.11], ipv4, dns, uses wifi, LQM: good NSErrorFailingURLKey=https://<our-issuer-host>/token-key-for-user-token NSUnderlyingError={NSPOSIXErrorDomain Code=50 "Network is down"} _NSURLErrorPrivacyProxyFailureKey=true Note that _NSURLErrorNWPathKey reports the path as satisfied in every case, so the "offline" description is a downstream effect of the fail-closed proxy requirement, not a real connectivity problem. A sysdiagnose and the raw device log captures are available on request, and are attached to FB24501570.