Getting a basic URL Filter to work

I haven’t been able to get this to work at any level! I’m running into multiple issues, any light shed on any of these would be nice:

  1. I can’t implement a bloom filter that produces the same output as can be found in the SimpleURLFilter sample project, after following the textual description of it that’s available in the documentation. No clue what my implementation is doing wrong, and because of the nature of hashing, there is no way to know. Specifically:
    1. The web is full of implementations of FNV-1a and MurmurHash3, and they all produce different hashes for the same input. Can we get the proper hashes for some sample strings, so we know which is the “correct” one?
    2. Similarly, different implementations use different encodings for the strings to hash. Which should we use here?
    3. The formulas for numberOfBits and numberOfHashes give Doubles and assign them to Ints. It seems we should do this conversing by rounding them, is this correct?
    4. Can we get a sample correct value for the combined hash, so we can verify our implementations against it?
    5. Or ignoring all of the above, can we have the actual code instead of a textual description of it? 😓
  2. I managed to get Settings to register my first attempt at this extension in beta 1. Now, in beta 2, any other project (including the sample code) will redirect to Settings, show the Allow/Deny message box, I tap Allow, and then nothing happens. This must be a bug, right?
  3. Whenever I try to enable the only extension that Settings accepted (by setting its isEnabled to true), its status goes to .stopped and the error is, of course, .unknown. How do I debug this?
  4. While the extension is .stopped, ALL URL LOADS are blocked on the device. Is this to be expected? (shouldFailClosed is set to false)
  5. Is there any way to manually reload the bloom filter? My app ships blocklist updates with background push, so it would be wasteful to fetch the filter at a fixed interval. If so, can we opt out of the periodic fetch altogether?
  6. I initially believed the API to be near useless because I didn’t know of its “fuzzy matching” capabilities, which I’ve discovered by accident in a forum post. It’d be nice if those were documented somewhere!

Thanks!!

Answered by beacham in 877878022

@DTS Engineer I am still getting this when pushing to Testflight:

Invalid Info.plist value. The value of the NSExtensionPointIdentifier key, com.apple.url-filter-provider, in the Info.plist of “PledgeLock.app/PlugIns/URLFilterExtension.appex” is invalid. Please refer to the App Extension Programming Guide at https://developer.apple.com/library/content/documentation/General/Conceptual/ExtensibilityPG/Action.html#/apple_ref/doc/uid/TP40014214-CH13-SW1. (ID: cf6bb55a-0673-41b4-8aaa-d64c2f36ce9c) error: exportArchive Validation failed. Invalid Info.plist value. The value of the NSExtensionPointIdentifier key, com.apple.url-filter-provider, in the Info.plist of “PledgeLock.app/PlugIns/URLFilterExtension.appex” is invalid. Please refer to the App Extension Programming Guide at https://developer.apple.com/library/content/documentation/General/Conceptual/ExtensibilityPG/Action.html#/apple_ref/doc/uid/TP40014214-CH13-SW1. (ID: cf6bb55a-0673-41b4-8aaa-d64c2f36ce9c).

That’s what was happening last night 😅

Currently (on the latest beta), I always get that error when trying to activate the TestFlight build. However, some testers have reported being able to activate 🤷‍♀️

But (still on the latest beta) versions installed from Xcode eventually activate. They flip many times between “busy” and “error” before tho, but that’s not new. It takes like a minute for the NEURLFilterManager.Status to eventually go to running. Once it does, everything works.

I don’t see any new errors on the server side, always the same two that were already common two days ago when everything was working, so I don’t think these are related, but here goes anyway:

Gateway:

2026-03-03T13:01:21.886520Z ERROR ThreadId(02) http_request{request_id=508c3c86-e2e2-440b-901e-0041f5928152 method=POST uri=/gateway user_agent=unknown}: ohttp_gateway::handlers::ohttp: Failed to decapsulate OHTTP request: a problem occurred with HPKE: Failed to open ciphertext

PIR:

2026-03-03T12:50:16+0000 error id=8836ee4457e3aa7dce6037645e7783cc [PIRService] HTTPError: Bad Request, Evaluation key not found

All I see on the server side when trying to activate is a few GETs to /.well-known/private-token-issuer-directory which appear to succeed.

I’ve restarted everything on the server but no change.

Any guidance in how to debug this would be extremely appreciated!

Still banging my head on this 😬

Thanks to the author of the gateway software I’m using we figured out those errors, and everything seems good on that front.

Still getting a lot of Bad Request, Evaluation key not found errors during queries. The sample project documentation says these should happen when the server is restarted bc old keys are cached, but they happen all the time. Still, this is only on the /queries endpoint, which is not involved in setup (afaik).

The client is still at times throwing this on TestFlight builds:

<NEPIRChecker: 0xbc2c4ae00>: -[NEPIRChecker start:responseQueue:completionHandler:] - failed to register with PIR for Group site.kaylees.Wipr2 usecase site.kaylees.Wipr2.url.filtering

The thing is, all other endpoints always work with no issues: /.well-known/private-token-issuer-directory, /token-key-for-user-token, /issue, /config, and /key are always successful. As far as I can tell, this should be enough for registration.

What exactly does the failed to register with PIR error mean?

What exactly does the failed to register with PIR error mean?

It’s hard to say without more information.

That log entry is recorded by NE when it fails to register with some underlying infrastructure. That registration mechanism follows standard Objective-C error conventions, that is, it has a method result and if that indicates an error, by returning NO, there’s an ‘out’ error parameter. NE checks the method result and sees the failure but it doesn’t record the error.

It’s possible that the error is being logged by the underlying code. Do you see any correlated log entries with a subsystem of com.apple.cipherml.

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Yes actually! This one

7214 error 19:24:29.268275+0100 framework configureUseCaseGroup(withName:useCaseGroup:) threw an error: CipherML.CipherMLError.unsupportedNetworkURL(url: https://pir.kaylees.site/)

or later

configureGroupWithName:useCaseGroup:error: Request complete error:Error Domain=com.apple.CipherML Code=1400 "Unable to configure use-case group: unsupported network URL: https://pir.kaylees.site/" UserInfo={NSLocalizedDescription=Unable to configure use-case group: unsupported network URL: https://pir.kaylees.site/, NSUnderlyingError=0x736c3de60 {Error Domain=CipherML.CipherMLError Code=12 "unsupported network URL: https://pir.kaylees.site/" UserInfo={NSLocalizedDescription=unsupported network URL: https://pir.kaylees.site/}}}

“unsupported”?

As far as I can tell, the device makes no attempt to contact the server.

This only happen with TestFlight builds on the latest beta. Every other combination seems to work fine.

I would try to debug this but I think it’s private API, and it’s pretty hard if I have to release a new TestFlight build every time 😅

Omg it was the / at the end. I’m gonna send this to the testers and see if that’s it.

Omg it was the / at the end.

Well, blat!

I’m gonna send this to the testers and see if that’s it.

Cool.

If that does turn out to be the problem, I’d appreciate you filing a bug about it. The system should either tolerate this or vend a more helpful error.

Please post your bug number, just for the record.

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Hmm I still don’t think I can ship :/ The “server setup incomplete” issue seems to be mostly solved, but NEURLFilterManager still breaks** in a lot of circumstances:

  • When the device is restarted
  • When the OS is updated (for example, from 26.4 seed 4 to 26.4 RC)
  • When the app is updated using TestFlight
  • When switching from App Store version to TestFlight version

And of course these will be blamed on me 😅 For all I know these might be TestFlight quirks that don’t affect the App Store version, but I can’t risk it.

** either by reporting configurationInternalError, or internalError, or by remaining in the starting state forever.

I just submitted this as FB22281393, but I’m afraid this won’t be enough info for them to do anything. Any guidance? I don’t think making a sample project would help, since this stuff only happens in TestFlight builds. I guess they can install my TestFlight?

I guess they can install my TestFlight?

Yes [1].

For all I know these might be TestFlight quirks … but I can’t risk it.

I agree with you there. My experience is that TestFlight is a very accurate representation of what you see on the App Store, so if things are failing in TestFlight then you have good reason to be concerned.

I just submitted this as FB22281393

Thanks.

You attached a sysdiagnose log to that bug, but there was no context for that. Some questions:

  • Did you have the VPN (Network Extension) for iOS/iPadOS debug profile installed when you took that log? See our Bug Reporting > Profiles and Logs for more about that.
  • What failure is the log showing? You list four cases where you had problems, but it wasn’t clear which of them was being demonstrates in that sysdiagnose log.
  • What was the timeline for that failure? Having a timeline really helps us orient ourselves in the log.

My general recommendation for grabbing a sysdiagnose is:

  1. Install any relevant debug profiles.
  2. Reproduce the problem, making a rough timeline as you go.
  3. Trigger the sysdiagnose log as soon as you see the issue.
  4. Attach that log to your bug, along with your steps to reproduce and your rough timeline.

I have a lot more advice on bug reporting in Bug Reporting: How and Why? and the various things it links to.

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

[1] Well, not exactly using TestFlight, but there are other internal paths for this sort of thing.

Hmm most of these issues are happening to the testers, but I guess I can try reproducing at least the TestFlight update one on one of my devices.

I’ll try and report back.

(I had only attached the sysdiagnose because the app made me 😅)

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!

Getting a basic URL Filter to work
 
 
Q