Hi @DTS Engineer Quinn made real progress based on your BAD_DECRYPT lead, with a new, more specific finding. I bypassed swift-crypto's HPKE.Recipient/HPKE.Sender entirely and implemented RFC 9180 base-mode HPKE manually using the lower-level primitives (Curve25519 key agreement, HKDF, AES-GCM) instead. Confirmed this resolves the platform-specific bug: a standalone HPKE test request I construct now decrypts successfully both locally on macOS and on the actual Fly.io/Linux deployment - identical result on both platforms now, where before it only worked on macOS. However, real requests from the iOS device still fail - now with a cleaner, more specific error: a genuine AEAD authentication failure (HPKE open failed), not the generic library crash from before. So my implementation correctly handles a standard RFC 9180 request, but something about the actual request the device sends doesn't match what I'm computing. Is there anything non-standard about how NEURLFilterManager/the PIR client constructs or routes these OHTTP requests that might not be obvious from the RFC - e.g., does it go through an Apple-operated OHTTP relay that re-encapsulates in transit, or is there a PIR-specific wrinkle in how info/aad are built that differs from generic OHTTP? Trying to figure out what to compare my reimplementation against, since I don't have visibility into the real device's raw request bytes. Thanks again - your BAD_DECRYPT read got us this far.

@Pushpak-Ambadkar123 hello, yes, I've dug a lot further on this. The full client-side sequence (on-device, Console.app filtered by NEPIRChecker) looks like this before that error: <NEPIRChecker>: -[NEPIRChecker start:responseQueue:completionHandler:] - Register with PIR Server (...) completed registration with PIR for Group ... <NEPIRChecker>: -[NEPIRChecker start:responseQueue:completionHandler:]_block_invoke - PIR status returned error <Error Domain=com.apple.CipherML Code=1100 ...>But the real root cause, if you also run your own PIR server and have access to its logs: on my server side, this traces back to an HPKE decapsulation failure in the OHTTP gateway Crypto.CryptoKitError.underlyingCoreCryptoError(error: 503316581)thrown from HPKE.Recipient(...)/.open(ct, authenticating:) when decrypting the incoming OHTTP request. I confirmed it's reproducible independently of the real client using a standalone HPKE test script, and that the failure rate seems to fluctuate with server uptime (worse after the process has been running a while) - pointing toward a possible concurrency issue around shared key material. Are you running your own PIR server, or hitting this purely from the client side? If you have server logs too, it'd be great to compare notes; might help build an even stronger case for @DTS Engineer Quinn.

Hi @DTS Engineer Following up with a much more precise finding after digging into server-side logs. The failure is happening in our PIR server's OHTTP gateway, specifically in HPKE request decapsulation: [OHTTP] decapsulateRequest failed: Crypto.CryptoKitError.underlyingCoreCryptoError(error: 503316581)This is thrown from HPKE.Recipient(privateKey:ciphersuite:info:encapsulatedKey:) / .open(ct, authenticating:) (DHKEM(X25519, HKDF-SHA256) / HKDF-SHA256 / AES-128-GCM, per RFC 9458). What I've confirmed: Not an entitlement/config issueThe NEURL Filter configuration is correctly onboarded, and the client reaches this point successfully (handshake, registration all succeed first). Reproducible independently of the iOS client I wrote a standalone Python script using a real HPKE library (pyhpke), fetched our server's published /.well-known/ohttp-gateway key, and built a byte-for-byte RFC 9458-compliant OHTTP request against it. It fails with the exact same CryptoKitError.underlyingCoreCryptoError(error: 503316581). So this isn't specific to anything the iOS client does. Failure rate seems to fluctuate over server uptime Right after restarting the server process, a handful of real device requests briefly succeeded decryption (progressing to a later, unrelated parsing error), then it reverted to failing on essentially every attempt a few minutes later. This pattern makes me suspect a concurrency/thread-safety issue around the shared Curve25519.KeyAgreement.PrivateKey being used to construct a new HPKE.Recipient on every incoming request, rather than a static configuration problem. Any idea what corecrypto error 503316581 typically indicates, or whether there's a known gotcha with concurrent HPKE.Recipient construction from a shared private key in swift-crypto? Happy to share the Python repro script and/or file a bug with logs attached if that would help narrow it down. Thanks again for sticking with this one.

@DTS Engineer Of course; makes sense, I'll keep things separated going forward. New thread posted here: https://developer.apple.com/forums/thread/853331

Hi @DTS Engineer — quick update now that the account transfer is confirmed onboarded on the good ID (thank you!). Running into a new, separate issue now when actually enabling the filter on device. The extension launches fine, XPC handshake succeeds, and PIR registration completes successfully. But the subsequent NEPIRChecker status check fails every time (retried repeatedly over several minutes, same result each time): PIR status returned error <Error Domain=com.apple.CipherML Code=1100 "Unable to query status due to errors: Error details were logged and redacted." UserInfo={NSLocalizedDescription=Unable to query status due to errors: Error details were logged and redacted., NSUnderlyingError=0x677037cf0 {Error Domain=com.apple.CipherML Code=1800 "Error details were logged and redacted." UserInfo={NSLocalizedDescription=Error details were logged and redacted.}}}>Config being registered (confirmed from the logs): pirServerURL = https://pir.dropbet.app/ pirPrivacyPassIssuerURL = https://pir.dropbet.app/issueBoth endpoints are live and were already validated as part of the original NEURL Filter configuration approval. I've captured a sysdiagnose from the device right when this was happening, so I have that ready to attach to a bug report if useful — just let me know and I'll file one. Any idea what CipherML error 1100/1800 typically indicates? Thanks again for all the help on this.

Hello Quinn, ok no problem and thanks again for your help 😉

Hello Quinn, Today I recive the mail about my onboarding : Your configuration [NE URL Filter] 9f3cbff8-63de-4c69-bf68-c19cd1c5d842 has been successfully onboarded and is now active. what´s the next step ? did i have to do something els for the transfer (FB24607828); or i have just to wait ? best regards & thanks again, Romain DropBet

ok thanks for informations Quinn, best regards

Got it, thanks for clarifying — that makes sense. Is there anything needed from my side for the onboarding step, or is it now entirely on Apple's end? And do you have any rough sense of timeframe (days, weeks, months) I should plan around, even approximate? Just trying to figure out whether to keep waiting or look at alternatives in the meantime.

Thanks for looking into it, @DTS Engineer Quinn! Just to clarify though — this isn't a new PIR onboarding in progress. The configuration (ID 9f3cbff8-63de-4c69-bf68-c19cd1c5d842) was already fully approved back on Aug 5, so there's no review pending on the PIR server itself. The actual issue is that it's attached to the wrong Apple Developer Team (ex personnel acc Romain Scotto : S5VDH23BBZ instead of the organisation acc SCOTTO : KRKJ76BC7W), and the portal blocks any attempt to fix that with "A configuration with the same PIR Server Domain already exists." So there's nothing to wait out — it's purely a matter of reassigning the existing approved config to the correct team. Does that change things on your end?

Hi @DTS Engineer Quinn — just following up. It's been about two weeks now since you opened this, and past the ~1 week check-in you'd mentioned. I haven't seen any status change on FB24607828 in Feedback Assistant yet. Any update on where things stand? Thanks again for your help.

Filed as FB24607828. Thanks again for the help, Quinn!

Thanks so much for taking the time to look into this, Quinn — really appreciate it. One thing that might be useful context for whatever direction you're investigating: the configuration itself (bundle ID, PIR server, all endpoints) is already fully validated and correct — the only thing wrong is which Team ID it's attached to. So if there's any way to simply re-attach/reassign it rather than routing it through a brand new full review (which took about 7-8 weeks last time), that would save a lot of time for what's really just a one-field correction. Totally understand if that's not how things work on your end though — just flagging it in case it's helpful. Thanks again for the help!

Quick bump — it's been a couple of days with no response yet, and this is quite time-sensitive on my end. Is there anyone from Apple DTS who could help with this, or who might have the right internal contact to get an approved configuration reassigned between Team IDs? Also — genuine question, since I'm not familiar with the process: if I open a paid Technical Support Incident (TSI) for this, is that actually something DTS engineers can act on for an account/entitlement-transfer issue like this one? Or would it likely get bounced as "out of scope" since it's more of an account administration matter than a code-level technical question? I'd rather not spend one of my two free incidents on this if it's not the right tool for the job. Any pointer — even just "this isn't something the forum/DTS can fix, go through X instead" — would genuinely help at this point. Thanks again for any help.

Hi everyone, I've been following this thread closely — it's been extremely helpful for getting NEURLFilterManager working. I'm now facing the pirSkipRegistration = NO blocker. My setup: Filter extension activates and deactivates correctly (cycle works end-to-end on iOS 26.5) configurationInvalid is resolved (trailing slash fix + correct usecase name) PIR server deployed at https://dropbet-pir.fly.dev/ (Swift PIR Service, 4 shards, ~208K domains) Usecase: com.dropbet.DropBet.url.filtering Entitlement url-filter-provider confirmed on both app and extension targets Privacy Pass disabled server-side for dev testing The filter is active but never sends /queries to my server — because pirSkipRegistration = NO, iOS requires Privacy Pass via Apple's OHTTP relay before forwarding any PIR queries. My question: what is the exact process to register a PIR server with Apple's OHTTP relay? Is there a form, a DTS request, or a specific Apple program to apply to? I haven't found any documentation on this step. Any help appreciated.