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:
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.
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:
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?
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?
