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!

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 😅)

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?

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

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 😅

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?