Anyone making "Sandbox-Safe" Audio Units?

[Jace-BeOS]

Self-contained plug-ins (a compressor with a few GUI resources stored in its bundle, say) should be just fine.

Anything complex with a file system browser (oops, did I say file system? Dirty word nowadays)? Pretty much screwed.

This is part of a push to make all software components self-contained on desktop and iOS, whether or not it's right for the component in question.

For Angry Birds? Sure. Easy & side-effect-free install and uninstall, and no chance of it doing something it shouldn't.

For XCode? Straight up dumb. Making the Mac OS X SDK part of the app bundle is pure stupid.. they've had to brain-damage their own app to make it fit the model. The SDK and the IDE are different components for different purposes & so belong under different hierarchies. (As an aside.. if you're a developer who cares about where all your intermediates & build products get put, they've also made that more difficult. Sure, you can override it, but the default setting show what the intent is: You don't need to know.)

The long term direction and intent is pretty clear, though. Everything on the desktop goes self-contained. Browsing the file-system is no longer to be encouraged, because users have no business thinking in terms of the file-system. User data belongs in the Cloud, whether you like it or not, because Mother knows best, and you, little user, cannot be trusted to look after your own data.

You know what this sounds a lot like? All those command line jockeys and DOS/Unix geeks and developers who swore up and down that there's no reason to have a GUI. They were wrong, too.

As a developer, you want access to internals. As a user, there's no reason to (provided the system does what it's supposed to do, unlike MS's first attempt at WYSIWYG web editing). Seriously, ask yourself if you are the average user or a specialist. Even as a tech person who grew up with this crap, I know full well that it IS crap to a user.

You're not making product to sell to tech geeks. You're making tools for users to do specific tasks.

Change happens and the computer industry has long needed to come out of its infancy and stop being a pile of parts strapped together with the guts hanging out, demanding specialized knowledge for regular use and maintenance. Even developers can benefit from a better working environment. This isn't like the slippery slope of rights losses in the USA. The computer is supposed to be a tool and it's high time they started actually behaving like what they claim to be.

How long before commodity computers can no longer be used to create the software they run? (See any iOS and Android device.) What will us "tech geeks" use then to actually CREATE things on, once the computer becomes a consumer-only device?

It's an unmaintainable pattern.

Logical assessment. But I think there are a few logical, and likely factual, answers:

1. You'll still be able to develop for these devices but the development environment will not be what you know today. Hey, life is like that. Stuff changes. You might find it easier in the end, and, if you don't, someone else probably will. These decisions aren't made specifically to frustrate you.

2. There will be special development systems. This is the case for game developers already. Typically, developing content for a console requires owning the console and a PC with the developer tools on it. A Mac Pro is a likely candidate for this scenario, just as a Mac is required to build iOS apps.

3. It won't change as much as you may fear it will change, or simply not in the worst possible ways.

[AdmiralQuality]

Self-contained plug-ins (a compressor with a few GUI resources stored in its bundle, say) should be just fine.

Anything complex with a file system browser (oops, did I say file system? Dirty word nowadays)? Pretty much screwed.

This is part of a push to make all software components self-contained on desktop and iOS, whether or not it's right for the component in question.

For Angry Birds? Sure. Easy & side-effect-free install and uninstall, and no chance of it doing something it shouldn't.

For XCode? Straight up dumb. Making the Mac OS X SDK part of the app bundle is pure stupid.. they've had to brain-damage their own app to make it fit the model. The SDK and the IDE are different components for different purposes & so belong under different hierarchies. (As an aside.. if you're a developer who cares about where all your intermediates & build products get put, they've also made that more difficult. Sure, you can override it, but the default setting show what the intent is: You don't need to know.)

The long term direction and intent is pretty clear, though. Everything on the desktop goes self-contained. Browsing the file-system is no longer to be encouraged, because users have no business thinking in terms of the file-system. User data belongs in the Cloud, whether you like it or not, because Mother knows best, and you, little user, cannot be trusted to look after your own data.

You know what this sounds a lot like? All those command line jockeys and DOS/Unix geeks and developers who swore up and down that there's no reason to have a GUI. They were wrong, too.

As a developer, you want access to internals. As a user, there's no reason to (provided the system does what it's supposed to do, unlike MS's first attempt at WYSIWYG web editing). Seriously, ask yourself if you are the average user or a specialist. Even as a tech person who grew up with this crap, I know full well that it IS crap to a user.

You're not making product to sell to tech geeks. You're making tools for users to do specific tasks.

Change happens and the computer industry has long needed to come out of its infancy and stop being a pile of parts strapped together with the guts hanging out, demanding specialized knowledge for regular use and maintenance. Even developers can benefit from a better working environment. This isn't like the slippery slope of rights losses in the USA. The computer is supposed to be a tool and it's high time they started actually behaving like what they claim to be.

How long before commodity computers can no longer be used to create the software they run? (See any iOS and Android device.) What will us "tech geeks" use then to actually CREATE things on, once the computer becomes a consumer-only device?

It's an unmaintainable pattern.

Logical assessment. But I think there are a few logical, and likely factual, answers:

1. You'll still be able to develop for these devices but the development environment will not be what you know today. Hey, life is like that. Stuff changes. You might find it easier in the end, and, if you don't, someone else probably will. These decisions aren't made specifically to frustrate you.

2. There will be special development systems. This is the case for game developers already. Typically, developing content for a console requires owning the console and a PC with the developer tools on it. A Mac Pro is a likely candidate for this scenario, just as a Mac is required to build iOS apps.

3. It won't change as much as you may fear it will change, or simply not in the worst possible ways.

Again, this is the Development board, where DEVELOPERS who KNOW something about what they're talking about come to discuss and ask each other questions. If you want to spout uneducated bullshit politics then every other board on this site is the appropriate place.

[Angus_FX]

This was a hilarious post and was amusing. But I have to take issue with your position that these areas are somehow not worth protecting. Why would you ever willingly NOT protect anything vulnerable?

Because all engineering is a trade-off. Some such trade-offs are worth it, some are not. There are some things I'd protect heavily, even on an app too small to be worth attacking (say, a listening TCP port which someone can attack from a remote machine). Others, not so much. It's like deciding whether or not to keep a gun in your house for personal protection (well, being a Brit, the government pretty much took that decision for me, but I'm cool with that).

Let's be clear on what this vulnerability is, in the context of pro-audio software. An attacker would have to find a vulnerability, create a Logic Pro song file containing malformed data to exploit it, trick a load of people in to downloading and opening it before getting found out, crawl their filesystem undetected, find something actually worth stealing, and upload to a remote machine.

The whole point of what exploits do is to attack vulnerabilities wherever they may be found.

No, they attack vulnerabilities that are worth attacking. Which is why you protect the hell out of things like Flash Player and banks, and not street food stalls and Logic Pro.

If we have an opportunity to address long standing design vulnerably in this industry, why would you not want to do so?

Because I don't consider an attack on pro-audio software to steal arbitrary user data to be a remotely likely scenario. It's just not a hack worth hacking.

It's really high time that computers stop being given special excuse to behave badly, including when assaulted by external parties.

Even at the expense of users & developers ceding control to corporations? "You can't run this application, it hasn't been validated by Apple". Is that what you want on the desktop?

Just to point out. Some of these features privilege Apple's own file dialogs above 3rd party ones. By default, users can select files in a system File-Open dialog which they can't from a plug-in's file browser, for example. The plug-in's browser is treated as a second-class citizen.

Now that we can overcome most of these limits and all these design mistakes (which might not have been perceived as such back in their days of conception) have been learned, why aren't we embracing the opportunity to make it right?

As best I can tell, there's been no public, accountable discussion as to whether or not this even is the right solution. Given that its declared reason for imposition makes minimal sense in the context of pro-audio software, you don't think it's worth asking what the actual reasons are? It gets handed down from on high, and that's that.

Neither Microsoft nor any of the Linux distributions have imposed this at a blanket level. Rather, they apply restrictions to specific high-risk activities like web/email programs; and in the case of Linux, it's easy (well, by the standard of anything Linux) to run different apps as different users & isolate them from each other that way, if that's the behaviour you really need.

Developers and users are rather mutually dependent. It is not valuable to excuse computer industry flaws by putting the responsibility on the user to be specially trained to operate the technology. The expectation of computers to be a specialized technical gadget only operated by trained professionals is long out of date, yet the programmers from that era still persist in thinking that way. If you want normal people to buy your products, they should be accessible to them.

Again, it's a trade-off. Automobiles are much less technical than they used to be, yet still require training to operate, and non-technical people seem to be entirely capable of absorbing that training given the right incentive. Don't want to learn that skill? Fine, take the bus, but you'll go where the bus goes & on the bus company's schedule.

[AdmiralQuality]

again, Angus.

[Angus_FX]

2. There will be special development systems. This is the case for game developers already. Typically, developing content for a console requires owning the console and a PC with the developer tools on it. A Mac Pro is a likely candidate for this scenario, just as a Mac is required to build iOS apps.

Special development systems. That will be a very sad day . Where are the next generation of developers, coders, hackers supposed to come from, when the system you use is no longer the system that builds?

To hell with it - I'm buying my kids a Raspberry Pi as soon as they're old enough anyway. But if you've only got an iMac? Now we're no longer talking about first and second class software, but first and second class digital citizens. Sounds like an MPAA wet-dream.

[Jace-BeOS]

]And the audio software products you've produced are...? This is the Dev board. The opinion of Apple fanboy-consumers is irrelevant here.

Hey man, mock and dismiss your customer base as much as you want, at your own peril. Defensiveness isn't an effective posture when faced with inevitable change.

For the record, I'm not an Apple fanboy. If you notice I commented about Apple gutting iWork. Disastrous for existing users. Apple will survive it long term but it'll damage their growth in professional circles and offices. I just happen to be a fan of technology done right for the users of said tech. I moved to Apple computers from Windows computers because they're less of a hassle to me as a user, and I moved to iOS devices from Palm OS devices because of superior functionality and the fact that thy make my daily life easier. I used to make all the same appeals to developers back when I was a BeOS fan. The only difference is that BeOS became irrelevant and Mac OS X became my escape route from Windows misery. I care about advocating for users, not about specific brands. Developers almost universally hate me for it, but they do live and die by users.

Frankly, I'm not built for development. But I've been there a bit, I've been close with developers, and I'm a tech person who's sick of being required to be a tech person just to use tools to make art and music or to write. I have a somewhat unique perspective in that i understand more tech stuff than average users and that I understand users more than average developers. I speak up because others might not (often don't). That's my motive here. Trash it if you feel better doing so.

[AdmiralQuality]

]And the audio software products you've produced are...? This is the Dev board. The opinion of Apple fanboy-consumers is irrelevant here.

Hey man, mock and dismiss your customer base as much as you want, at your own peril. Defensiveness isn't an effective posture when faced with inevitable change.

You're the one who's lubing yourself up for Apple's hot thick shaft. I'm on THE CUSTOMERS' side. (Being one myself.)

[Crandall1]

While AQ is showing his usual people skills, or the utter lack thereof, he does have a point, Jace. This particular forum is for us to discuss our issues and how to work around them. You coming in and saying "put up or shut up," when you don't actually have a horse in this race, is really not moving the conversation forward.

(Although it has engendered some sigfile-worthy quotes from Angus, which almost makes it worthwhile.) If you say you know how developers work, then you'll know that we stand around and yell at the clouds for a while, then take the path that produces the best results for the least effort. Always. In my own case, it took me about half an hour and a couple letters from Sean to move from "f**k THESE GUYS SIDEWAYS" to "hey, maybe this Sandbox shit ain't that bad, even though it's stupid and pointless." This is how we work.

So kindly please move along and let us do our jobs and talk this shit out.

[AdmiralQuality]

While AQ is showing his usual people skills, or the utter lack thereof, he does have a point, Jace. This particular forum is for us to discuss our issues and how to work around them. You coming in and saying "put up or shut up," when you don't actually have a horse in this race, is really not moving the conversation forward.

(Although it has engendered some sigfile-worthy quotes from Angus, which almost makes it worthwhile.) If you say you know how developers work, then you'll know that we stand around and yell at the clouds for a while, then take the path that produces the best results for the least effort. Always. In my own case, it took me about half an hour and a couple letters from Sean to move from "f**k THESE GUYS SIDEWAYS" to "hey, maybe this Sandbox shit ain't that bad, even though it's stupid and pointless." This is how we work.

So kindly please move along and let us do our jobs and talk this shit out.

I hate it when we agree too, Chris.

And yes Jace, we WERE being productive in here. We don't need a lecture from mere users. You'll find COMPLETE consensus among the actual developers discussing this. My opinion on this, while possibly illustrated a little more colorfully, is not substantially different from any other developer on this board. You'll find zero audio software developers saying, "Oh goodie, I'm being forced to change everything! Again!!!" (Except maybe for the ones who are looking forward to charging you for an update of software that used to work on the previous OS. We've had 3 major Apple OS upgrades in 4 years. That's insanity! Wouldn't you rather have your favorite developers working on features instead of just constantly having to "fix" their old software? Which wasn't "broken" to begin with.)

[Jace-BeOS]

Angus: thanks for conversing respectfully and taking the time and care to do so.

My take on the closing of vulnerability in audio apps isn't to protect user data per se but to protect the system from other malignant acts. GarageBand is on all Macs and all iOS devices going forward, so that makes the prevalence of the vulnerability higher, does it not? Not all users will use it, and surely offices would remove it for irrelevancy to workplace function, but it is still a greater presence than Logic.

Yes, engineering is about making compromises. No argument. I'm a bit idealistic, despite plenty experience telling me not to be. As for consensus in the user community, how would you even seek that? Admiral Quality thinks I'm a dipshit for expressing my views as a user, but I don't see any other way to get that consensus even remotely explored by being elitist good-old-boys in a private elite developer club where people like me are disrespected, mocked, and name-called for daring to provide unpopular input.

Yes, Apple is doing what is best for Apple, but I don't think it's always the best tactic to assume all actions have an evil intent to make developers and users suffer in the long term. Paranoia is healthy, though, and I'm not remotely a fan of capitalism, especially seeing how it works in big business in the computer industry.

As for developer machines vs developing on personal machines... I appreciate the concerns. I grew into computers during the very open "everything goes" era myself (and I'm pretty sure there were all the same developer doom and gloom fears expressed on BBSs and in paper documentation when entities like Apple and Microsoft created GUIs and GUI-driven OSs, but there were also systems that were already doing that, and were just as proprietary, like Amiga & Atari ST, and both brought us what we have today on the Mac and Windows platforms for music, when their own original platforms failed on the market... because of competition from the others).

So, like usual, nothing is different except constant change. I don't think it will be the doomsday of the locked-out public that old-school developers fear. Revisit my three "developer potentials" forecasts again; there are other options. iMacs ARE being used for development, obviously. I don't expect them to be closed to that. The whole way of looking at and doing things is being changed. Maybe there SHOULD be a difference between developing a computing device and developing addons for it. Look at Propellerheads' approach with addons to Reason.

Just because you cannot develop on a console doesn't mean you can't develop at all, nor develop for it. I'd also check that your kids really want to become developers before you throw a raspberry pi at them They might confound you and turn into users

[Jace-BeOS]

Okay, I'll take Chris' suggestion and request to heart and bow out now. Just don't reply further to me or I'll feel inclined to reply to it

EDIT: I removed "DSP and Plug-in Development" from my latest posts thingy. Have your fun and I wish you all the best. I love audio tools and I appreciate developers who want to make them because I cannot.

[Urs]

I've had a sleepless night over this but I missed all the fun

So it's good that the basic functionality is still in place with a little symlink. That's not too bad at all and very relieving indeed.

Still, and I've asked this Michael at Apple, why hasn't the code signature been enforced for AUs? Not sure about Mavericks, but on Mountain Lion our cracked plugs load just fine even though the codesign file obviously fails the tampered with binary.

If codesign with our developer certificate isn't enough to trust us, then the hell, what is? - And yes to Angus' point that Logic users with certain plug-ins installed are a very poor target for exploits.

I also had a sit down yesterday with our man from our online reseller. We were discussing their new APIs in respect of possible in-App-purchases. Like, integrate a preset market right into the plug. Not sure if we want to go that way but pretty sure it ain't gonna be easy with sandboxed stuff.

Does "Reveal in Finder", "open website in Safari", "like us on FB" and "open user manual in Preview" still work? What about drag'n'drop? As it often requires a temp file, does that mean it's gone?

[valhallasound]

Still, and I've asked this Michael at Apple, why hasn't the code signature been enforced for AUs? Not sure about Mavericks, but on Mountain Lion our cracked plugs load just fine even though the codesign file obviously fails the tampered with binary.

If codesign with our developer certificate isn't enough to trust us, then the hell, what is? - And yes to Angus' point that Logic users with certain plug-ins installed are a very poor target for exploits.

I think it is being enforced, in that you have to run at a lower security level (or whatever it is called) to run plugins that aren't code signed. The user gets a warning that they will have to enter into dangerous territory, and can choose to do so. If Logic X works like this, that would be great.

Sean Costello

[discoDSP]

Does "Reveal in Finder", "open website in Safari", "like us on FB" and "open user manual in Preview" still work? What about drag'n'drop? As it often requires a temp file, does that mean it's gone?

All those work as expected. Can't confirm drag'n'drop because it's not being used yet.

Corona installer runs the following script for GarageBand X compatibility:

Code: Select all

if [ -d "$HOME/Library/Containers/com.apple.garageband10/Data/" ]
then


	if [ ! -d "$HOME/Library/Containers/com.apple.garageband10/Data/Documents/discoDSP" ]
	then

	sudo ln -s "$HOME/Documents/discoDSP" "$HOME/Library/Containers/com.apple.garageband10/Data/Documents/"    
    
	fi


fi

All OK after lowering security of course.

Interestingly, Corona reads GUI skin preferences from ~/Library/Application Support/discoDSP/corona.settings and it still works outside sandbox folders.

I think it is being enforced, in that you have to run at a lower security level (or whatever it is called) to run plugins that aren't code signed. The user gets a warning that they will have to enter into dangerous territory, and can choose to do so. If Logic X works like this, that would be great.

Edit: Sean, security warning dialog still triggers if your AU is code signed but it's not sandbox ready.

[JonHodgson]

Still, and I've asked this Michael at Apple, why hasn't the code signature been enforced for AUs? Not sure about Mavericks, but on Mountain Lion our cracked plugs load just fine even though the codesign file obviously fails the tampered with binary.

If codesign with our developer certificate isn't enough to trust us, then the hell, what is? - And yes to Angus' point that Logic users with certain plug-ins installed are a very poor target for exploits.

I think it is being enforced, in that you have to run at a lower security level (or whatever it is called) to run plugins that aren't code signed. The user gets a warning that they will have to enter into dangerous territory, and can choose to do so. If Logic X works like this, that would be great.

Sean Costello

I think Urs is not referring to unsigned plugins, but to incorrectly signed ones.

If it's signed, but the signature doesn't match the content of the plugin then something is wrong, either the developer has made a mistake, or, more likely the code has been tampered with, in which case it shouldn't be run (it's almost certainly a crack, and may in addition have malicious code in it).