6 ms·

How exactly would Apple have "disabled" Audio Hijack Pro in 2005? Nothing like Gatekeeper existed back then, and if code signing was a thing it certainly wasn'

How exactly would Apple have "disabled" Audio Hijack Pro in 2005? Nothing like Gatekeeper existed back then, and if code signing was a thing it certainly wasn't in widespread use. Even kernel extensions were completely unsigned until the release of OS X Mavericks in late 2013. Edit: To be clear, I'm sure it would have been technically possible for Apple to kill Audio Hijack. However, I think it would have required either enormous engineering effort (e.g. replacing third party kernel extensions a decade early) or a completely unprecedented policy change (blacklisting a specific hash or bundle identifier, of an app that wasn't malware). I don't think there's an alternate timeline where Apple would have done either of these things, whatever happened in that meeting with Steve Jobs.

msla 4y ago
> How exactly would Apple have "disabled" Audio Hijack Pro in 2005? Would the courts have cared about the technical details? Is "That is currently impossible" ever a reason to not do something a court orders you to do?
- yjftsjthsd-h 4y ago
  > Would the courts have cared about the technical details? It is unlikely that a court would have done anything; we had that court case in the form of VCRs, and sanity prevailed. (IANAL, but the court case that set precedent for "it's not illegal if it has substantial legitimate uses, even if it also allows copyright infringement" seems applicable)
Zak 4y ago
They might have disabled the OS features it depended on to operate, though I have the impression attempting to do that might have made the Mac worse for professional audio production using any software.
- EGreg 4y ago
  Zak, why’d you stop submitting links 10 years ago ?
- Wowfunhappy 4y ago
  I'm not positive about Audiohijack back then, but I know SoundFlower (which shares development history) worked via a kernel extension. Kernel extensions literally have full read/write access to kernel memory. I'm not sure how you'd restrict something like that.
  - goosedragons 4y ago
    Make Kexts a chore to use and discourage everyone from making them as they have recently done?
    - Wowfunhappy 4y ago
      That would mean offering a replacement for kexts, which has in recent times been a multi-year project Apple still isn't fully finished with.
  - Mindwipe 4y ago
    They would move the audio processing out of kernel memory, as they did with decrypted secure video.
sandworm101 4y ago
Back then there was occasional software-specific code in many OSs, famously simcity was addressed by name in win95. So it would not be unprecedented for an os to specifically recognize certain software by name. This lives on today in graphics drivers being optimized for specific games. Inside the black box that is proprietary software, they can do whatever they want.
- Wowfunhappy 4y ago
  Sure, but arbitrarily blacklisting a specific app, for reasons other than malware? I guess Apple could have done that, but—correct me if I'm wrong—in 2005 I think that would have been completely unprecedented, and certainly trivial to bypass. It seems like a pretty odd request to make of Apple, as opposed to contacting Rouge Amoeba directly.
  - sandworm101 4y ago
    "Blacklisting" apps was essentially what antivirus was all about in those days.
  - parker_mountain 4y ago
    > It seems like a pretty odd request to make of Apple, as opposed to contacting Rouge Amoeba directly. A lot of these associations were much less sophisticated about how they viewed technology. It wasn't unreasonable for something like the RIAA to view apple as being responsible for the actors on its platform. It is odd, but not uncommon.
    - Wowfunhappy 4y ago
      The RIAA being dumb about technology is absolutely on brand. I just don't think I believe the counterfactual that Apple would ever have done anything.
lapcat 4y ago
There are a lot of bundle identifier checks in macOS/Mac OS X, including in the system frameworks. Apple could have targeted the AHP bundle id to break things. Of course, RA could have changed the bundle id or done other hijacking to make it work again, but it would be a cat-and-mouse game that Apple would probably win in the end, because RA customers would continually experience breakage on OS updates. Also, the "audio hijacker" was located in a well-known system directory, so Apple could just nuke that directory. That's assuming Apple really wanted to break AHP. It's unclear how much motive Apple had to follow the RIAA request even before the now famous meeting.
- Wowfunhappy 4y ago
  Right, and Apple also could have introduced Gatekeeper and co six years earlier than they ultimately did, just for their friends at the RIAA! But it all seems pretty far-fetched. I don't think I believe the alternate scenario would have ever happened.
  - catiopatio 4y ago
    What about it is far-fetched? Contemporaneously to this story, Apple disabled screen capture of DVD movies and introduced PT_DENY_ATTACH (preventing debugging of the DVD player) at the behest of the MPAA.
AdamJacobMuller 4y ago
Apple could have done any number of things to do that. You're thinking about this from the limited perspective of how Apple could have done it that RA couldn't have worked around (code signing) but that isn't remotely required. All Apple needed to do was to push an update which breaks the software. if (process == "AudioHijack") { dont_stream_audio();} AudioHijack would find some way to work around that, as I'm sure they can, the RA team is wicked smart but their software would be broken for a day/week/month until they did and then Apple would analyze their workaround (using their exponentially greater manpower and better understanding of the system and find a way to break it again. Cue cat and mouse game. The thing is in that scenario, Apple loses nothing when RA fixes their software (they can just tell the RIAA they're trying -- and they are!) but every time Apple breaks Audio Hijack they would be eating away at the userbase and inserting doubt into potential purchasers. Am I going to spend $65 on something which my OS manufacturer clearly doesn't want me using and is probably going to break in a month or three for an indeterminate amount of time. You're seeing this as "can apple unequivocally disable this software" but that is the wrong question, even today it's not true (I can disable gatekeeper/SIP/etc if I'm determined enough and if I want i'll just run Ashai) but the real game here is Apple making it more difficult to use it and the REAL game would have been Apple instilling doubt in existing customers and potential purchasers. Anyway I'm glad Apple didn't do that, RA produces some great software.
- lapcat 4y ago
  > Am I going to spend $65 on something which my OS manufacturer clearly doesn't want me using It was actually much cheaper back in the day, not that it matters much to the argument.
  - AdamJacobMuller 4y ago
    Yeah I figured someone would call that out :) My memory is not good enough anymore to remember how much it was and the button for the wayback machine is too far away to use that.
- GeekyBear 4y ago
  > All Apple needed to do was to push an update which breaks the software. Windows 3.1 famously refused to run on top of Digital Research's DOS. > DR-DOS has problems running windows today, and I assume will have more problems in the future." Allchin replied: "You should make sure it has problems in the future. :-)" https://www.theregister.com/1999/11/05/how_ms_played_the_incompatibility/ https://www.theregister.com/1999/11/05/how_ms_played_the_inc...
quitit 4y ago
The same way that Microsoft was messing with Quicktime on Windows.
- Wowfunhappy 4y ago
  Can you fill me in on that?
  - quitit 4y ago
    tl,dr: Microsoft deliberately introduced bugs into their platform to destabilise Quicktime. The reason I bring it up here is because if Apple so desired they could engineer their platform in a way that prevented RA's software from functioning. --- It's interesting that this isn't better known because Microsoft's tactics through the 90s would make HN users screech. Microsoft had taken aim at a number of businesses and technologies which they saw as competitive threats - the results of which go a long way to explain why we have such limited choice in computing platforms/technologies versus the early 90s. Amongst many important technology providers, they didn't just fall over, they were pushed. This article covers some of it, but there is so much more: http://www.roughlydrafted.com/RD/RDM.Tech.Q1.07/5F0C866C-6DDF-4A9A-9515-531B0CA0C29C.html http://www.roughlydrafted.com/RD/RDM.Tech.Q1.07/5F0C866C-6DD... In summary: Quicktime was one of the many technologies that Microsoft targeted due to being seen as a competitive threat to their business objectives. Microsoft made this known to Apple and industry partners via threats that they followed through with. This included deliberately engineering under the hood problems for Quicktime, presenting fake error messages, silently usurping file associations, stealing code from quicktime to build competitor products, and using their monopoly to force partners to rip quicktime out of their products. (This list is not exhaustive.)

msla 4y ago

> How exactly would Apple have "disabled" Audio Hijack Pro in 2005? Would the courts have cared about the technical details? Is "That is currently impossible" ever a reason to not do something a court orders you to do?

yjftsjthsd-h 4y ago
> Would the courts have cared about the technical details? It is unlikely that a court would have done anything; we had that court case in the form of VCRs, and sanity prevailed. (IANAL, but the court case that set precedent for "it's not illegal if it has substantial legitimate uses, even if it also allows copyright infringement" seems applicable)

Zak 4y ago

They might have disabled the OS features it depended on to operate, though I have the impression attempting to do that might have made the Mac worse for professional audio production using any software.

EGreg 4y ago
Zak, why’d you stop submitting links 10 years ago ?
Wowfunhappy 4y ago
I'm not positive about Audiohijack back then, but I know SoundFlower (which shares development history) worked via a kernel extension. Kernel extensions literally have full read/write access to kernel memory. I'm not sure how you'd restrict something like that.
- goosedragons 4y ago
  Make Kexts a chore to use and discourage everyone from making them as they have recently done?
  - Wowfunhappy 4y ago
    That would mean offering a replacement for kexts, which has in recent times been a multi-year project Apple still isn't fully finished with.
- Mindwipe 4y ago
  They would move the audio processing out of kernel memory, as they did with decrypted secure video.

sandworm101 4y ago

Back then there was occasional software-specific code in many OSs, famously simcity was addressed by name in win95. So it would not be unprecedented for an os to specifically recognize certain software by name. This lives on today in graphics drivers being optimized for specific games. Inside the black box that is proprietary software, they can do whatever they want.

Wowfunhappy 4y ago
Sure, but arbitrarily blacklisting a specific app, for reasons other than malware? I guess Apple could have done that, but—correct me if I'm wrong—in 2005 I think that would have been completely unprecedented, and certainly trivial to bypass. It seems like a pretty odd request to make of Apple, as opposed to contacting Rouge Amoeba directly.
- sandworm101 4y ago
  "Blacklisting" apps was essentially what antivirus was all about in those days.
- parker_mountain 4y ago
  > It seems like a pretty odd request to make of Apple, as opposed to contacting Rouge Amoeba directly. A lot of these associations were much less sophisticated about how they viewed technology. It wasn't unreasonable for something like the RIAA to view apple as being responsible for the actors on its platform. It is odd, but not uncommon.
  - Wowfunhappy 4y ago
    The RIAA being dumb about technology is absolutely on brand. I just don't think I believe the counterfactual that Apple would ever have done anything.

lapcat 4y ago

There are a lot of bundle identifier checks in macOS/Mac OS X, including in the system frameworks. Apple could have targeted the AHP bundle id to break things. Of course, RA could have changed the bundle id or done other hijacking to make it work again, but it would be a cat-and-mouse game that Apple would probably win in the end, because RA customers would continually experience breakage on OS updates. Also, the "audio hijacker" was located in a well-known system directory, so Apple could just nuke that directory. That's assuming Apple really wanted to break AHP. It's unclear how much motive Apple had to follow the RIAA request even before the now famous meeting.

Wowfunhappy 4y ago
Right, and Apple also could have introduced Gatekeeper and co six years earlier than they ultimately did, just for their friends at the RIAA! But it all seems pretty far-fetched. I don't think I believe the alternate scenario would have ever happened.
- catiopatio 4y ago
  What about it is far-fetched? Contemporaneously to this story, Apple disabled screen capture of DVD movies and introduced PT_DENY_ATTACH (preventing debugging of the DVD player) at the behest of the MPAA.

AdamJacobMuller 4y ago

Apple could have done any number of things to do that. You're thinking about this from the limited perspective of how Apple could have done it that RA couldn't have worked around (code signing) but that isn't remotely required. All Apple needed to do was to push an update which breaks the software. if (process == "AudioHijack") { dont_stream_audio();} AudioHijack would find some way to work around that, as I'm sure they can, the RA team is wicked smart but their software would be broken for a day/week/month until they did and then Apple would analyze their workaround (using their exponentially greater manpower and better understanding of the system and find a way to break it again. Cue cat and mouse game. The thing is in that scenario, Apple loses nothing when RA fixes their software (they can just tell the RIAA they're trying -- and they are!) but every time Apple breaks Audio Hijack they would be eating away at the userbase and inserting doubt into potential purchasers. Am I going to spend $65 on something which my OS manufacturer clearly doesn't want me using and is probably going to break in a month or three for an indeterminate amount of time. You're seeing this as "can apple unequivocally disable this software" but that is the wrong question, even today it's not true (I can disable gatekeeper/SIP/etc if I'm determined enough and if I want i'll just run Ashai) but the real game here is Apple making it more difficult to use it and the REAL game would have been Apple instilling doubt in existing customers and potential purchasers. Anyway I'm glad Apple didn't do that, RA produces some great software.

lapcat 4y ago
> Am I going to spend $65 on something which my OS manufacturer clearly doesn't want me using It was actually much cheaper back in the day, not that it matters much to the argument.
- AdamJacobMuller 4y ago
  Yeah I figured someone would call that out :) My memory is not good enough anymore to remember how much it was and the button for the wayback machine is too far away to use that.
GeekyBear 4y ago
> All Apple needed to do was to push an update which breaks the software. Windows 3.1 famously refused to run on top of Digital Research's DOS. > DR-DOS has problems running windows today, and I assume will have more problems in the future." Allchin replied: "You should make sure it has problems in the future. :-)" https://www.theregister.com/1999/11/05/how_ms_played_the_incompatibility/ https://www.theregister.com/1999/11/05/how_ms_played_the_inc...

quitit 4y ago

The same way that Microsoft was messing with Quicktime on Windows.

Wowfunhappy 4y ago
Can you fill me in on that?
- quitit 4y ago
  tl,dr: Microsoft deliberately introduced bugs into their platform to destabilise Quicktime. The reason I bring it up here is because if Apple so desired they could engineer their platform in a way that prevented RA's software from functioning. --- It's interesting that this isn't better known because Microsoft's tactics through the 90s would make HN users screech. Microsoft had taken aim at a number of businesses and technologies which they saw as competitive threats - the results of which go a long way to explain why we have such limited choice in computing platforms/technologies versus the early 90s. Amongst many important technology providers, they didn't just fall over, they were pushed. This article covers some of it, but there is so much more: http://www.roughlydrafted.com/RD/RDM.Tech.Q1.07/5F0C866C-6DDF-4A9A-9515-531B0CA0C29C.html http://www.roughlydrafted.com/RD/RDM.Tech.Q1.07/5F0C866C-6DD... In summary: Quicktime was one of the many technologies that Microsoft targeted due to being seen as a competitive threat to their business objectives. Microsoft made this known to Apple and industry partners via threats that they followed through with. This included deliberately engineering under the hood problems for Quicktime, presenting fake error messages, silently usurping file associations, stealing code from quicktime to build competitor products, and using their monopoly to force partners to rip quicktime out of their products. (This list is not exhaustive.)