Saturday, May 11, 2013

Parental Controls after OS X 10.8.2: EXC_CRASH and changes to https handling

The kids don't often use my Mountain Lion machines, so I only learned recently that Apple made some significant changes to Parental Controls with the 10.8.2 update. I don't rememberer seeing any documentation at the time and there's nothing in the release notes.

I found out about the changes when I opened the Parental Control Preference Pane on my main Mac. It crashed. I rebooted, it still crashed, and crashed ...

The crash message looked like this one one from last year (I'm on 10.8.3):

Mountain Lion Parental Control time...: Apple Support Communities

Process: System Preferences [2658]
Path: /Applications/System Preferences.app/Contents/MacOS/System Preferences
Identifier: com.apple.systempreferences
Version: 12.0 (12.0)
Build Info: SystemPrefsApp-232000000000000~22
Code Type: X86-64 (Native)
Parent Process: launchd [488]
User ID: 502

Crashed Thread: 0 Dispatch queue: com.apple.main-thread

Exception Type: EXC_CRASH (Code Signature Invalid)
Exception Codes: 0x0000000000000000, 0x0000000000000000

Application Specific Information:
com.apple.preferences.parentalcontrols v.400 (Kindersicherung)
objc[2658]: GC: forcing GC OFF because OBJC_DISABLE_GC is set

I was able get around the crash by turning off parental controls for the affected user from the the User Preference Pane. Then I could open and close the Parental Controls Preference Pane; after that I could reenable PCs for the affected account.

I assume the my old preferences were not compatible with the 10.8.2+ version of Parental Controls, and Apple's code didn't handle this very well. Old bug, not fixed. Disappointing, but there's a workaround.

Which leads to the obvious question -- what the heck did Apple change in 10.8.2 Parental Controls? For sure they didn't fix any of the longstanding defects -- like an execrable UI for log review.

The answer is in a 12 page Apple Discussion Thread, pointing to a mislabeled Apple KB article (it says it's 10.6, but it was revised June 2012 and the change came with 10.8.2). Apple changed how they handle https sites when "Try to limit access to adult websites automatically" is selected in Parental Controls.

You see, Apple's Parental Control infrastructure has never worked with SSL encrypted (https) sites [1]. So they have to decide what to do when someone tries to access an https site. Since the https site is effectively invisible, Apple can either decide to trust it completely or distrust it completely. Prior to 10.8.2 Apple's "automatic" limits erred on the side of universal trust. After 10.8.2 they err on the side of universal distrust (which has always been the "Allow access to only these websites" behavior).

So this isn't a bug introduced with 10.8.2, it's Apple being a bit more honest about how crappy OS X Parental Controls always have been. I wonder if the change was made to avoid litigation, or if the transition to all SSL net access made it impossible to keep the old pretense.

In theory an admin user an approve all the https access requests that come up when a user tries to reach one of those sites, but in practice that doesn't scale.

Bottom line: Parental Controls was born lousy, but with 10.8.2 Apple is at least being honest about how bad it really is. [2]

[1] See  OS X Parental Controls: The https bug and our family Google Apps services back in 2010. I think this is related to my employers ability to block dropbox, but inability to block Google Drive without also blocking Google Search.

[2] Parental Controls are no better on iOS by the way -- thanks to the webkit back door. (Bob Tedeschi wrote about this back in 2012.)

No comments: