Transparent Proxy filter by app or pid?

Is there another way of "getting out of the way"?

No, but that would make a fine enhancement request IMO. Please post your bug number, just for the record.

Is there a better API I should be looking at for this?

What are you doing with the flows? Looking at, and potentially blocking, them? Or actually changing the contents?

Share and Enjoy
—
Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

All three actually.

• Looking at incoming data to look for malicious content
• Potentially blocking outgoing connections to known bad actors
• Replacing page contents with a
  • product block page when user browses to malicious site
  • product warning page when user browses to unproductive site
  • product block page when user browses to unproductive site

Some of these use cases can be handled by the Content Filter, but I don't think it can cover all of them. We have to support all browsers, right down to the little unsigned homebrew wget.

Some of these use cases can be handled by the Content Filter, but I don't think it can cover all of them.

Looking through that list I think that a content filter can handle them all. What do you think is missing?

Share and Enjoy
—
Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

According to this documentation, the NEFilterDataProvider can only put up block pages if the flow originates from a WebKit browser. I also saw in documentation (but I can't find it at this moment) that Content Filters were only able to see the data but not modify it. If we can't use the built in block page aparatus, and we can't modify the flow to show a block page when needed, then we can't use the content filters. I realize that some of the documentation on these APIs are for macOS and iOS, so there might be some inconsistencies that are not well documented.

Thanks for your insight!

According to this documentation, the

NEFilterDataProvider

can only put up block pages if the flow originates from a WebKit browser.

Ah, yeah, I’d forgotten about that caveat. And non-WebKit browsers are much more prevalent on macOS.

Share and Enjoy
—
Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

I was curious about this, so I asked the NE team to clarify. Some factoids:

• The

  filterBrowsers

  feature is not supported on macOS (something that I hadn’t noticed but is clearly called out in the deprecation warning on that property).

• Given that, a web browser’s network connections are going to come through as socket flows (

  NEFilterSocketFlow

  ).

• It’s possible, in the type system, to resolve a socket flow with a block page — for example, by having

  -handleNewFlow:

  return

  +[NEFilterNewFlowVerdict remediateVerdictWithRemediationURLMapKey:remediationButtonTextMapKey:]

  — but this doesn’t work. In the context of a socket flow, that verdict is treated as a drop verdict (

  +dropVerdict

  ).

Share and Enjoy
—
Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

I created a Suggestion feedback ticket with number FB7573775 that suggests the AppProxyProvider be able to not proxy a flow but allow the flow to continue.