I was told (https://developer.apple.com/forums/thread/791352?answerId=865728022#865728022) to post here. I have now additionally submitted this issue as FB21013893.

Hi! I’m not asking about either feedback per se; I’m reporting/asking about what I think is a bug in Feedback Assistant(‘s backend). In one case the engineers confirmed they received my debug data, yet the app is still yelling at me like I need to do something.

So the fact that those feedbacks are in the “Requests” mailbox with an “unread” dot is just a glitch that I can safely ignore?

It’s been over a month since then with no activity, however FB19582905 still has the “unread” badge so I’m afraid as far as you're concerned you’re still waiting for my answer? (FB14888965 is another bug with an unresolved unread badge after providing requested info)

Thanks, I just provided the requested info!

Hmmm I got an email reply but I can’t see it here? Anyways I did just try to resubmit again and the errors are the same: Validation failed Invalid Code Signing Entitlements. Your application bundle's signature contains code signing entitlements that are not supported on iOS. Specifically, value 'url-filter-provider' for key 'com.apple.developer.networking.networkextension' in 'Payload/Wipr.app/Wipr' is not supported. (ID: 65f19038-24b1-4701-9bae-237253675d6f) Validation failed Invalid Code Signing Entitlements. Your application bundle's signature contains code signing entitlements that are not supported on iOS. Specifically, value 'url-filter-provider' for key 'com.apple.developer.networking.networkextension' in 'Payload/Wipr.app/Extensions/WiprBlockerNetwork.appex/WiprBlockerNetwork' is not supported. (ID: cdc0f1ec-d541-4d55-8202-bb9c8e3553d7) Validation failed Invalid Info.plist value. The value of the EXExtensionPointIdentifier key, com.apple.networkextension.url-filter-control, in the Info.plist of “Wipr.app/Extensions/WiprBlockerNetwork.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: 27b322bc-9010-40c6-880c-7ad627a7c149)

Hi! Few more weeks went by, 26.1 beta is out, but I’m still nowhere closer to test this (let alone release it). Same two blockers: No response to the server certification form App Store Connect auto-rejects apps with URL Filter extension I have 150 testers that signed up to test this specifically... What do I tell them? 😬 I figured it was safe to announce this feature late in the 26 beta cycle 🥲

Bug number is FB19582905

I’m now down to two blockers: I’ve submitted the form to validate my server component over a week ago and no answer 🤷‍♀️ I don’t know how long that is supposed to take, but until it happens a potential TestFlight or App Store version either won’t work at all, or would “fail closed” as I specified (I don’t know which). App Store Connect currently auto-rejects any app with a URL Filter extension in it, which makes TestFlight testing (and later, shipping) impossible. I’ve reported this as a bug which was answered but with no actionable information 😬 At this point I don’t think this feature is gonna ship with the 26 updates, or at least not in a way that an App Store app can take advantage of. But I’d love to be proven wrong 🤷‍♀️

Ok I’ve figured it out from trial and error: The framework's FNV-1a implementation multiplies before xoring, while most implementations online do the opposite. I just implemented it myself. For MurmurHash the implementation in this package will do https://github.com/daisuke-t-jp/MurmurHash-Swift The bits are stored “backwards” in the resulting data. In other words, write them in array order and then bit reverse every byte.

The problems I’ve originally reported as questions 2 through 4 appear to be fixed in the current beta. Any guidance about generating a correct bloom filter would be very much appreciated. The system is loading my filter properly now, but every URL gets “allowed”, presumably because my “bits” are incorrect.

The workaround of killing Settings before installing a new URL Filtering extension seems to work. However the system gets confused when you have multiple installed – if you switch one on from Settings they will all get enabled at once, which fails. I still haven’t managed to install "debug logging for Network Extension” but I will and submit some feedbacks. About the bloom filter tool, should we expect it in a reasonably short timeframe so we can start using it before these features ship? Cause if not I gotta go back to poking my code until I make it work right through sheer luck 😬

Still About 3): While my configuration is enabled, this line keeps being spammed in the logs: mapError unexpected error domain NEVPNConnectionErrorDomainPlugin code 7 Which appears to mean /** @const NEVPNConnectionErrorServerDead The VPN server is no longer functioning. */ case serverDead = 7 I don’t know if this is referring to the remote PIR server or just some locally running code. After I disable the configuration the following is spammed like 10 times before ceasing: mapError unexpected error domain NEVPNConnectionErrorDomainPlugin code 38 This one seems to be undocumented.

About 3): Digging further with Console, I saw this error message: NESMURLFilterSession[Wipr:...]: Failed to start with error: Error Domain=NSCocoaErrorDomain Code=4099 "The connection to service created from an endpoint was invalidated from this process." UserInfo={NSDebugDescription=The connection to service created from an endpoint was invalidated from this process.} Obviously no clue what this means 🥲 But it seems that the extensions with the NEURLFilterControlProvider cannot even be launched for some reason?