Hi! If I guessed right the issue is: URL Filters break like that on macOS if the user ID is not 501. Reported this back in March in FB22281393. My app detects this scenario and warns the user! But it’s a nightmare for them to actually change their user ID, so I’d love for this to get fixed eventually.

If you haven't already, install the VPN (NetworkExtension) debug profile on your test device. This will un-redact the ⁠com.apple.CipherML Code 1800⁠ errors in the macOS Console and should explicitly confirm the proxy provisioning failure. I’m pretty sure I had this already, that’s how I was able to get the logs above. Maybe it’s a different profile that will un-redact them? Update your Feedback/Radar ticket to highlight that ⁠NEMembershipChecker⁠ Code 3 is failing specifically for production-signed profiles, causing CipherML to fail closed on the privacy proxy. It was already in there, but why not, done 😅 Also, if the ⁠NEURLFilterManager⁠ or PIR configuration APIs allow it, see if there is a temporary parameter to set the proxy behavior to "fail open" (direct connection fallback) for the duration of the beta cycle. There is a “fail open/close” parameter but I think it means a different thing in this context. Fail open means that the URL Filter won’t block a load that gets caught by the local prefilter if the server can’t be consulted, fail closed means it will block it.

iOS 27 beta 1 brings a brand new error which ends up resulting in a state of .serverSetupIncomplete: <NEPIRChecker: 0x7de6c79b60>: -[NEPIRChecker start:responseQueue:completionHandler:]_block_invoke - 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=0x7de712f4e0 {Error Domain=com.apple.CipherML Code=1800 "Error details were logged and redacted." UserInfo={NSLocalizedDescription=Error details were logged and redacted.}}}> <NEAgentURLFilterExtension: 0x7de6d24e60>: -[NEAgentURLFilterExtension startURLFilter]_block_invoke - Failed to startFilter <Error Domain=NEMembershipCheckerErrorDomain Code=3 "(null)"> What’s a NEMembershipChecker? Member of what? Digging deeper I found these: Failed to prefetch tokens for group 'site.kaylees.Wipr2': Error Domain=NSURLErrorDomain Code=-1009 "The Internet connection appears to be offline." UserInfo={_NSURLErrorNWPathKey=satisfied (Path is satisfied), interface: en0[802.11], ipv4, dns, uses wifi, LQM: good, NSErrorFailingURLKey=https://pirissuer.kaylees.site/token-key-for-user-token, NSUnderlyingError=0x7517125a40 {Error Domain=NSPOSIXErrorDomain Code=50 "Network is down" UserInfo={NSDescription=Network is down}}, _NSURLErrorPrivacyProxyFailureKey=true, NSLocalizedDescription=The Internet connection appears to be offline.} queryStatus(for:options:) threw an error: Error Domain=NSURLErrorDomain Code=-1009 "The Internet connection appears to be offline." UserInfo={_NSURLErrorNWPathKey=satisfied (Path is satisfied), interface: en0[802.11], ipv4, dns, uses wifi, LQM: good, NSErrorFailingURLKey=https://pirissuer.kaylees.site/token-key-for-user-token, NSUnderlyingError=0x7517125b00 {Error Domain=NSPOSIXErrorDomain Code=50 "Network is down" UserInfo={NSDescription=Network is down}}, _NSURLErrorPrivacyProxyFailureKey=true, NSLocalizedDescription=The Internet connection appears to be offline.} The connection and the URL mentioned are fine of course, but "Network is down” now? This new problem only affects the App Store version of my app – not present if I install from Xcode.

Interesting... but why tho?? 😅 None of the users I’ve told this to were expecting this. Anyways thank you, this solved the issue for my users who purchased the IAP after I’ve set it to shareable. The ones who purchased before then still have the issue, so for anyone reading this: enabling Family Sharing for a (non-consumable, at least) IAP is not retroactive.

It would be extremely useful if this API tried all subdomains... as in, they keys c.com and b.c.com should both block the load of http://a.b.c.com/whatever. When I read the docs, who said that loading https://www.example.com/a/b/c?id=123#fragment would be matched against both example.com and www.example.com, I assumed that meant that subdomains didn’t matter. But in testing I discovered it literally only applies to www 😅 I think I can infer why this API was introduced based on its design; however wouldn’t that use case require pretty strong anti-evasion features?

Really not sure why you’re asking me, but if I had to guess... Well the DNS record issue should be pretty obvious, the rest I imagine is because azure puts your server behind some sort of proxy? Literally spitballing over here tho

I didn’t, I got lucky!

I started from that code yeah. Of course there was a lot of configuration involved to stand up the server 😅 I don’t know how to help, I guess I just got lucky and did it right the first time. I was never formally accepted or rejected, but apparently I was accepted in effect.

Guess I’m the authority on URL Filters now 🤷‍♀️ I didn’t; in my use case (and most, I’d wager), Safari is literally the only place where URL Filters make no difference, so no one would see that screen. Content Blockers are much more powerful!

I’m not sure whether a restart of the target app is needed for foundation to reload the bloom filter, I always re-launch everything while testing. Seems like a comparatively minor issue anyway.

Not really, on 26.4 an app update causes the filter to break permanently. On 26.5 it takes like 5/10m for it to reactivate. Nothing to do with the browser, of course.

Well no it triggers when you first activate the extension, but never again. All the non-cosmetic bugs I’ve found are reported in this thread!

I didn’t!

Prefetch used to work but it’s been broken for a bit, yeah. I haven’t even reported this yet, there's way worse bugs to fix.

I managed to reproduce one of the issues first try: Update the TestFlight to a newer version -> NEURLFilterManager goes to “starting” forever. I sent the sysdiagnose as instructed (added to the same bug). Hopefully this and the other issues have a common root cause!