But they generally just block domains, or use extensions, neither of which care about http/s.
A quick search shows that https://www.netnanny.com/products/netnanny/ says it works against SSL.
(I'm concerned if a kid browses with iPad, some telephone, etc., and the concern is more on whoever provides the service that might be liable in some way).
The only time it makes a difference is if you want to block part of a domain and not other parts. I can think of some use cases (block Google unsafe search, but not safesearch), but generally they just block the whole domain and have a separate domain for the "good" part. (See http://www.safesearchkids.com/, for example.)
And it's not like this isn't the same situation now. Whatever would be possible then would also be possible now, just by using https. This is just making http harder to use.
Besides, what you described is still domain specific. If you want to block only certain Youtube videos, that's where you'll have a problem.
http://stackoverflow.com/questions/18447874/google-chrome-us...
I'm not familiar with how those typically work, but intuitively from an architecture standpoint, that sounds like something that should sit as a filter between the browser and the outside world. Browser as monolith of functionality seems undesirable.
With a browser extension (which you would also need to get installed on the device in some manner) you can inspect the pages as they are displayed.
In-path filters outside the trust boundary are, I'm afraid, the very first casualty in our efforts to mitigate the threats of nation state adversaries, as they resemble the attacks used there too much to survive. I, for one, will not mourn them.