I forgot to put this into the previous post about content blocking.
I was at a teacher networking meeting a couple of months ago and we had some Apple folks down to talk about education. They were looking at some of the stuff coming up in iOS 9, and mentioned content blocking. Through reading and listening to followup from WWDC this year, most people had put this squarely into an ad-blocking context, but the way they were talking about it sounded a lot more like it would be usful in an instututional setting where acceptable use policies would dictate that some content be inaccessible (e.g. the myriad of stuff which educational organisations block because they are “thinking of the children!”).
I’d seen an example app that worked with older versions of iOS which used VPNs to achieve content blocking without the use of proxy filtering (which was good because it worked regardless of the app using network resources), but the way that content blocking works in iOS 9 seems like a nicer and more configurable way of doing things, providing that users are locked out of disabling it through settings through device management policy or something similar.
There are a couple of downsides to this idea though:
- Content blocking only applies to the new Safari view controllers and Safari itself. Most established apps will use web views, which aren’t filtered, so any app which gets out to the web by itself is potentially excluded from filtering.
- Safari provides a mechanism for reloading pages without filtering by holding the reload button down. Obviously this is a problem for mandatory filtering as opposed to optional filtering.
I do wonder (not being in an environment where I have to manage iOS devices anymore) whether the reload behaviour can be disabled through policy, since per-device filtering seems like a nice lightweight way of doing content filtering. It shifts processing and networking burdens from the edge servers to individual devices, and still allows for updating of rules on those devices.