I was the same way until one day, I tried to run gdb on iTunes, and gdb segfaulted. I did some research and found that Apple added extra code to the OS just to prevent someone from doing exactly that. They spent additional engineering effort just to lock me out of my own computer. (I still wonder what data collection they were trying to hide.)
Anyway, that was the day I deleted OS X and switched back to Linux forever. (I even ran Rockbox on my iPod until I replaced it with a $30 Sansa device with 10x the features.)
Playing devil's advocate here, but what's the media store like on your typical Linux distribution? The reason Apple has to go to such draconian measures is to please their content providers. Without doing so, you wouldn't have an iTunes store with such a wide variety of content.
Apple's margins from content sales are slim; they push content to sell devices. As they've shown with music in the past, they'll get rid of DRM if the content providers allow it. So it's not entirely fair to blame Apple for that one.
When Apple first signed on the labels, iTunes didn't run on Windows. Do we know when these protections first showed up? Was it Apple's way of appeasing the labels before they gained enough mass that the labels couldn't ignore them?
I don't know about the debug protections, but according to Wikipedia's timeline, it was only a matter of 6 months between iTunes Store appearing and iTunes becoming available for Windows.
You seem to be very confused. The facility that blocks gdb is part of the standard ptrace APIs. It was not extra code that Apple added.
In any case, there's also a very simple explanation that should be obvious to anyone who thinks about it as to why Apple did this: because iTunes deals with DRM. A one-line change to block debugging is something I'd absolutely expect any app that uses DRM'd content to do.
PT_DENY_ATTACH certainly isn't part of any standard. It's absolutely a Darwin-specific feature, and is thus "extra code that Apple added", and they presumably did it for exactly this application. And no, other DRM-aware apps on other OSes don't do this.
Yes, but critically in Linux you can turn it off as the administrator of the system. It affects security but not inspectability. Regardless, my response was simply to the idea that Apple was "following standards" when they clearly weren't.
Trivially worked around by starting the program in gdb and running these commands before you run the program:
b ptrace
commands
return 0
cont
end
(In short, every time the app calls ptrace, return a 0 to the caller without executing any ptrace code, and automatically resume execution. Since apps almost never use ptrace for anything else, it's workable to just short-circuit every single call like this rather than trying to check for PT_DENY_ATTACH.)
I can only assume that they're following the letter of their contract with media companies to include anti-debugger measures, while not really trying very hard.
Just to be clear, I'm not trying to defend Apple here, just telling people how they can get around this if they feel like debugging iTunes or whatever.
Besides Apple's nefarious Dr. Evil world domination uses, it can also be used to protect programs from each other. If your browser denies ptrace, it will prevent rogue programs from reading your passwords out of its memory.
I would guess that the gdb thing is to prevent cracking of their DRM, not to hide some PII tracking. Do you know if you can attach gdb to something like Xbox Music (Zune)?
Anyway, that was the day I deleted OS X and switched back to Linux forever. (I even ran Rockbox on my iPod until I replaced it with a $30 Sansa device with 10x the features.)