This is rather crappy QA or the lack of verification of the QA process at Apple. I really hope they pick up the slack they have been forming over the past ~5 years, it's starting to get predictably bad.
Could also be bad hiring. Mistakes do happen, sure, but the only instances in which I personally noticed a dev accidentally slipping personal data into a log file, they tended to have other issues in their work like an unusually high bug count.
There is a well-known "triangle" of [money, quality, time]. You can fix two factors at most, but that means a third factor will suffer. This decision is made by the management, whether or not they realise this triangle exists.
Language can be a contributing factor. In a language that includes a generic dump routine that can convert an arbitrary data structure into a useful string representation, or that makes it easy to write such a routine if one is not built in, people tend to use that facility to convert things for logging.
Then later someone adds a sensitive field to some data structure, and if anything is logging that structure it will pick up the new field.
In a language like C, where I don't think you can write a nice dump_arbitrary(void * data) function, and so if someone wants to log something they have to write a routine specifically to deal with that particular thing, when someone adds a sensitive field to a struct it does not automatically go into logs. It only goes in if someone specifically updates the logging code to know about the new field.
> In a language that includes a generic dump routine that can convert an arbitrary data structure into a useful string representation, or that makes it easy to write such a routine if one is not built in, people tend to use that facility to convert things for logging.
I'm reminded of one such system I did in C#, where I knew ahead of time that some fields passed to the logger may contain user data. I added a [Sensitive] attribute that a property accessor can be tagged with, and the logger reflected upon this and replaced contents with a placeholder if it was there.
So I don't really buy that as too compelling an excuse. People who are mindful, careful about what they are doing, and respectful of the user will engineer, document, and evangelize solutions.
I'm starting to actually believe I'm observing the effect of the loss of one staff member -- Jobs.
Something like this might happen once. Under Steve, it damned well wouldn't happen twice.
Also, most places, even ones with a lot of money, don't really respect and won't pay for QA. It gets outsourced; they try to get the developers to do it; etc.
In today's environment, there's no overriding incentive.
Back to Jobs; there was an incentive. You didn't want to end up on his shit list.
P.S. I never knew Steve Jobs, although he was involved with an institution I was at, back in our younger years. My impression is from what I've read about him, and how I've seen Apple changing since his death.
This Steve Jobs fetishism makes no sense. Are people seriously implying that bugs never happened under his leadership? Am I the only one who remembers the festering dumpster fire that was iTunes under Steve Jobs?
I didn't -- past a certain, limited point, perhaps -- for a number of years subsequent to his passing.
Now, I'm starting to wonder.
The hardware gains have been pretty incredible, with the custom ARM systems. The privacy stance seems (because I don't really know it in depth) to be a welcome turn.
But some other aspects are seeming to slip, repeatedly. For one thing, there seem to be more and more complaints and problems with regard to the software.
And it took Apple too long to take ownership of some hardware problems, until they figured out the magnitude of the negative PR.
Jobs wasn't perfect. But his ability to be critical and call BS and say "fix it", was very useful.
(Even if iTunes never benefited. I've never used it, except to help a friend digitize some personal media, one time, where the results landed in iTunes, IIRC. I wasn't thrilled with it (kind of frustrating and limited interface, as I recall), but we were able to get the job done.)
Well, maybe I've succumbed -- belatedly -- to the reality distortion field.
But damned if I'd let a product ship while it was logging passwords.
Simple QA is to scan log files for anything that shouldn't be there. It requires no more than defining those values, pattern matching, and patience while it churns.
This is actually a testing pattern that fits well into automation. As opposed to a lot of the "how do we hook into the GUI, so we can click stuff" automated QA I've seen.
How would this be caught in typical QA? Unit tests, acceptance tests, and general "usage" would all miss this bug. The only way this will be caught would be code review (is that QA?), or auditing all log files.
