Hacker News new | past | comments | ask | show | jobs | submit login

My intent isn't to bash Apple, I love their products and intend to use them for the rest of my life, provided they don't fuck it up.

I don't want to see them fuck it up.

Now:

>Thus, every pro media application distributed without sandboxing was LESS safely distributed than a sandboxed one.

First, they weren't less safely distributed, they were less safely executed. Nothing gets sandboxed until after it's been distributed. The only reason we're discussing both issues here is that Apple has elected to conflate the two with their MAS policies.

I'm only 25, and yet I've installed thousands of pieces of software during my brief time on this planet. Very few of them wreaked havok on my life, so you'll have to forgive me if I remain unconvinced that every single application I run must be sandboxed to maintain the stability and integrity of my system.

My contention is not that sandboxing, generally speaking, is bad for users. It isn't.

My contention is that sandboxing, as Apple has narrowly defined it, is impossible to implement in a large segment of professional applications as they are currently written.

Furthermore, if developers choose to eschew the MAS, users of their applications will be deprived access to useful new tools like iCloud file sharing for reasons that seem arbitrary at best.

Finally, in two weeks time when Apple begins to enforce regulations which will exclude these applications from MAS distribution, but does not remove VST/AU support from Logic Pro, Rewire support from Mainstage, or [insert your favorite hypocrisy here], they may be acting anticompetitively, which is bad news.




First, they weren't less safely distributed, they were less safely executed. Nothing gets sandboxed until after it's been distributed.

Well, it's a pedantic distinction if sanboxing occurs before or after. Since, sure, sanboxing rules are applied at runtime, but sanboxing is also built into the app before distribution (the developers adds the certs, the "ask for permission" bits, etc).

I'm only 25, and yet I've installed thousands of pieces of software during my brief time on this planet. Very few of them wreaked havok on my life, so you'll have to forgive me if I remain unconvinced that every single application I run must be sandboxed to maintain the stability and integrity of my system.

Well, in Windows lots of apps have wrecked havoc with my system. Malware, spyware, what have you. I've hand around 10 instances of my machine being infected in around 8 years of using a Windows machine. In OS X, on the other hand, nothing yet. And sandboxing is a way to ensure it won't be so in the future.

But there's is also another issue for which I think sandboxing is nice, besides malware. It keeps apps from spiting stuff all over the system. Like, how MS Office installs its shit everywhere it can, or how Abode Creative suite does. Same things for lots of small apps. If sandboxing can keep the confided in their own space, that will also be a win.

My contention is that sandboxing, as Apple has narrowly defined it, is impossible to implement in a large segment of professional applications as they are currently written.

Well, I think those rules can change. They already extended the period before sandboxing is applied. I'm sure as limitations are found we will see other changes too.

For some apps, on the other hand, like developer tools, rsync, git etc, they will always have to run without sandboxing.

Finally, in two weeks time when Apple begins to enforce regulations which will exclude these applications from MAS distribution, but does not remove VST/AU support from Logic Pro, Rewire support from Mainstage, or [insert your favorite hypocrisy here], they may be acting anticompetitively, which is bad news.

I'm not sure about the "anticompetitively" thing. It's their store, their rules. If sandboxing is about not trusting apps, then why would Apple require it for their own apps? One would think they trust them already.




Join us for AI Startup School this June 16-17 in San Francisco!

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: