Content Filter Providers in unsupervised and unmanaged iOS devices

I'm looking at implementing an iOS app that has includes a Content Filter Provider to block access to certain domains when accessed on the device.

This uses NEFilterManager, NEFilterDataProvider and NEFilterControlProvider to handle configuration and manage the network flows and block as necessary.

My question is can you deploy this in an iOS 18+ app on the App Store to devices which are unmanaged, unsupervised and don't use Screen Time APIs?

Although not 100% clear, this technote seems to say it is not possible: https://developer.apple.com/documentation/Technotes/tn3134-network-extension-provider-deployment

Testing this on a Developer device and build works successfully without any MDM profiles installed.

A similar approach using the same APIs also works on macOS once user permissions have been given.

If it can't work on unsupervised, unmanaged iOS devices, is possible for the user to first manually install a MDM profile which includes the required 'Content Filter' details and then have it work?

If not, how would you filter iOS network traffic on an unmanaged, unsupervised device?

Is it necessary to use a VPN or DNS approach instead (which may be a lot less privacy compliant)?

Answered by DTS Engineer in 826324022
Written by bentocorp in 775112021
this technote seems to say it is not possible

Right. TN3134 lists the supported deployment scenarios. Things that aren’t listed there aren’t supported.

Written by bentocorp in 775112021
If not, how would you filter iOS network traffic on an unmanaged, unsupervised device?

I wouldn’t.

To be clear, the limitations on content filter are not an accidental omission but an expression of a privacy policy.

Written by bentocorp in 775112021
Is it necessary to use a VPN or DNS approach instead … ?

I’m not sure what you mean by “VPN or DNS approach” but, if you’re planning to use a packet tunnel provider for this, please note the advice in TN3120 Expected use cases for Network Extension packet tunnel providers.

Share and Enjoy

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

Written by bentocorp in 775112021
this technote seems to say it is not possible

Right. TN3134 lists the supported deployment scenarios. Things that aren’t listed there aren’t supported.

Written by bentocorp in 775112021
If not, how would you filter iOS network traffic on an unmanaged, unsupervised device?

I wouldn’t.

To be clear, the limitations on content filter are not an accidental omission but an expression of a privacy policy.

Written by bentocorp in 775112021
Is it necessary to use a VPN or DNS approach instead … ?

I’m not sure what you mean by “VPN or DNS approach” but, if you’re planning to use a packet tunnel provider for this, please note the advice in TN3120 Expected use cases for Network Extension packet tunnel providers.

Share and Enjoy

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

Thank you for the response. Regarding your note:

I’m not sure what you mean by “VPN or DNS approach”

Currently on iOS, there are two main ways that apps on the App Store provide network content blocking or network filtering capabilities on unsupervised and unmanaged devices:

  1. DNS - Create a DNS server which blocks name requests for certain domains. An accompanying iOS client app prompts users to download a custom Configuration Profile on the device and then manually accept in Settings, which modifies the DNS name servers for that device allowing certain traffic to be filtered and blocked by the domain name server.
  2. VPN - Create a VPN Server that tunnels all network traffic and blocks traffic requests for certain domains. An accompanying iOS client app sets up the VPN connection via the NEVPNManager API.

Both of these approaches are currently in use on the App Store and are inherently privacy hostile. The providers of either the DNS or VPN service can track domains accessed and/or traffic routed via their servers.

I am wanting to filter traffic which is guaranteed to be more privacy compliant on-device on unsupervised and unmanaged iOS devices, by using the Content Filter Provider approach (NEFilterManager, NEFilterDataProvider and NEFilterControlProvider).

These APIs are designed from the ground up to ensure that traffic and domains cannot be tracked and yet the more privacy compliant approach is not supported by Apple?

Why?

You may say:

I wouldn’t. To be clear, the limitations on content filter are not an accidental omission but an expression of a privacy policy.

I understand why the APIs are architected in a privacy compliant manner, which I fully support, but Apple's policy in allowing their use forces app developers to use less privacy compliant means to provide this functionality and simply externalises the privacy breaches for users.

This argument that these APIs may be problematic to be used broadly for on-device network filtering also falls apart because:

  1. Apple supports their use on children's devices! The tech note explains that it's ok to use them in ScreenTime scenarios on a child's device which is managed by a parent. So these are problematic to use, but it's ok to use them on children's devices? So Apple thinks a parent can make a fully informed evaluation on the suitability of this functionality for their children but are incapable of making a fully informed evaluation of the suitability of this functionality for themselves and their own devices?
  2. Apple supports the exact same APIs on unmanaged Macs. Sure Macs are generally given more flexibility, but the API's work well and are not causing major privacy issues on that platform.

In lieu of the above changing in an iOS update – which I can send feedback via Feedback assistant about – is there any answer or guidance on the other question:

If it can't work on unsupervised, unmanaged iOS devices, is possible for the user to first manually install a MDM profile which includes the required 'Content Filter' details and then have it work?

Written by bentocorp in 826434022
Why?

This is a classic why question, which I can’t answer. See tip 3 in Quinn’s Top Ten DevForums Tips.

Share and Enjoy

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

This is a classic why question, which I can’t answer.

Ok, got it – I'll submit a formal feedback to address the usage of these APIs on unsupervised, unmanaged iOS devices.

Update: Feedback submitted - FB16614357

Third time lucky, though is there any technical answer that someone may be able to answer, if the following would function on iOS non-developer devices:

Question: Is it technically possible for the user to first manually install a MDM configuration profile which includes the required 'Content Filter' details and then have a Content Filter provider (using NEFilterManager, NEFilterDataProvider and NEFilterControlProvider) work on the device?

Written by bentocorp in 826594022
Is it technically possible for the user to first manually install a MDM configuration profile

There are two cases here:

  • Globally

  • Per-app

In the per-app case it’s definitely not possible. The mechanism used to associate the filter configuration with the app (ContentFilterUUID) requires that the app be installed by MDM.

In the global case I think it’s possible [1], but it requires that the device be supervised, which is a significant constraint.

Share and Enjoy

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

[1] Historically I’ve done it while testing, although I’m not sure if I actually tested it with a distribution-signed app.

Content Filter Providers in unsupervised and unmanaged iOS devices
 
 
Q