Apple Crippled Its DTrace Port
Linnen writes in to note that one of developers of Sun's open source system tracing tool, DTrace, has discovered that Apple crippled its port of the tool so that software like iTunes could not be traced. From Adam Leventhal's blog: "I let it run for a while, made iTunes do some work, and the result when I stopped the script? Nothing. The expensive DTrace invocation clearly caused iTunes to do a lot more work, but DTrace was giving me no output. Which started me thinking... did they? Surely not. They wouldn't disable DTrace for certain applications. But that's exactly what Apple's done with their DTrace implementation. The notion of true systemic tracing was a bit too egalitarian for their classist sensibilities..."
Could this to help prevent circumvention of DRM?
From the DTrace source (in an #IFDEF APPLE):
/*
* If the thread on which this probe has fired belongs to a process marked P_LNOATTACH
* then this enabling is not permitted to observe it. Move along, nothing to see here.
*/
Luckily no malicious programmer will mark their malware's process with this flag!
It's like this every time kdawson takes a turn posting stuff to the front page. Wish he'd join up with his natural comrades at digg.com and take the tired rewarmed leftovers of 19th and 20th century politics away with him.
Isn't this a F/OSS program? Couldn't you just recompile an uncompromised version of the source?
Knowledge is power. Knowledge shared is power multiplied.
"Do you want to spend the rest of your life selling sugared water or do you want a chance to change the world?"
Is it just my imagination or is this post a dupe? And a positively moderated dupe at that (twice!).
Not that I mind, but suddenly I feel at least 50% less efficient.
Quack, quack.
Yes, it's annoying - every time we examine the system we are now looking at everything except for iTunes (and possibly Spy-WaR3 ;-). But this issue is about more than just that.
I've introduced DTrace to many companies. While most people love it, some developers of closed source software are concerned about people DTracing their code. DTrace allows customers to gather proof of bugs that are embarrassing, hard to fix, or that the developers have deny existed. I've been asked many times if DTrace can be disabled for an application, usually to avoid negative publicity from the bugs that DTrace will expose. The answer has always been no. It's been great to see developers accept this reality and escelate bug fixing.
This is expected - DTrace visibility should improve overall code quality in IT. Hopefully it will also encourage employers to hire better programmers - since if customers don't use DTrace to point out embarassing bugs, then competitors may. It also erodes reasons to stay closed source - customers can use DTrace to see the code anyway.
Giving developers another option, to disable DTrace visibility, is allowing a backwards step from the future.
It is DRM'd to only run on Apple hardware. There is nothing technical that prevents it from running on any modern PC since that is indeed what Macs are now. However that won't work, hence there are groups out there that have to hack it to disable that and allow it to run on any hardware.
You can argue till your blue in the face that they need to do this, doesn't change what they are doing. If it wasn't DRM'd, it'd run fine on any hardware that met its technical requirements.
There are two differences here, how a corporation treats internals, and how it treats externals. As I understand the issue, (bear in mind my computer systems knowledge can by written legibly on a 3"x5" card in crayon), Apple disabled a tool used (among other things) to detect malign software, without publishing the fact.
You may choose to associate with GE, and yet still have objections the Ford plant next door putting out high quantities of Carbon Monoxide. You may also have objections to freely associating with GE, and discovering after working there for 20 years that they release enough benzene into the environment in your plant to triple your cancer risk.
Now, is disabling one tool very few people use worth government action to stop it. Perhaps not. Is disabling one tool very few people use a reasonable thing for a private individual responsible for keeping his own company's network secure something he should consider before allowing this vendors products inside his firewall? Different question.
In what situation is this a problem if you are not probing iTunes? If you're trying to get info from another program, iTunes won't be the application currently runing on the CPU when the event happens.
"Without Apple DRM, iTunes (store) would be impossible due to the idiot record labels."
Well, they're selling mp3's on amazon with no DRM.
Or are you going to give the credit to apple for that? Next thing you know, you'll be saying "this isn't so bad" and follow it up with "the record labels have the right to protect their property".
Melodrama aside, it looks like dtrace needs to be fixed to properly deny access. Access is currently denied, as appropriate, but used more CPU than needed to do so. Not exactly broken (which implies a design failure), but a bug.
Hardly a bug worthy of saying "Apple crippled its dtrace port."
Care about electronic freedom? Consider donating to the EFF!