The Crash from 'File:///' — More Broadly What Are These Keyboard Sniffer Hooks Doing in a System-wide OS X API?
Update March 14, 2013: this bug is apparently fixed in OS X 10.8.3.
This site is not the first to document the “File:///” bug in Apple OS X, but I have some different thoughts about it than might have been covered elsewhere.
Typingwill crash many programs on OS X 10.8 (those that use the OS X NSText API).
Actually, simply pastingwill crash (I just tried pasting the first few words of the above into TextEdit). Try it in Apple’s and see for yourself.
On my system, when typing—
Crash / hang: Mail, Notes, TextEdit
Works OK: Pages , Keynote, Numbers
Matthew H writes:
I was messing around testing this File url bug you commented on, and was surprised to learn that just *viewing* a file with that url would cause a crash. After first crashing TextEdit following your blog post, I opened the Console log viewer, which then crashed when I clicked the TextEdit crash report.
Using the good old fashioned command line in Terminal, I confirmed the crash report also contained the file url string, making the Console app crash. In addition, the Problem Reporter.app, which is the process that sends crash reports to Apple if you so instruct after a crash, *also* crashed if I clicked for it to show the details of the crash report. Maybe Apple can't fix the bug because their computers crash whenever they open the crash report! Crazy! Thanks for reporting on it.
MPG: I wrote what follows nearly a week before this reader email. It seems particularly a propos to my “When the impact is potentially widespread...” assertion below. And it’s not just about stability— ill-considered global hooks into system code present potential global security breaches too; it’s poor engineering judgment, and this is a serious part what I call Apple Core Rot. And ironic in the context to all the Apple emphasis on sandboxing and similar “lockdown” features.
A system-wide API doing unnecessary and unwanted “sniffing” on the things I type makes me nervous, being inherently inappropriate (that NSTextView also happens to have a severe performance hang with large blocks of text is another indictment, but an unrelated issue per se).
Code which doesn’t just process text as raw data, but that actively looks for certain patterns is by definition a keyboard sniffer, regardless of what its purposes or intent is. That is troubling in its own right for a system-wide API.
More important, code this sloppy does not give me confidence that handling of passwords and passphrases and other sensitive data is done in a way that avoids scattering copies of them around in memory (which also means to disk potentially, e.g., VM paging).
Thisthing is only one little crash bug (affecting dozens if not hundreds or thousands of programs using the NS* API). When the impact is potentially widespread, the expectations for quality necessarily rise commensurately in all respects and especially in the areas of stability, performance and security. This isn’t one bug in one program. Severe criticism is warranted in such cases, criticism along the lines of questioning competence of testing and quality control. Because the idea that this is the last and only bug is ludicrous.
Security is hard, very hard to do right. What security problems might lurk within the NSText APIs with regards to passwords and/or other sensitive data? When a programmer can’t get basic things right (and a huge world-class organization can’t test code properly), it does not breed confidence. Furthermore complexity breeds bugs of all kinds.
Whatever extra stuff this Apple keyboard sniffer code is doing ought to be deracinated and extirpated from the API. Heck, perhaps the sniffer code is even responsible for the multi-minute hangs when pasting large text blocks.