Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why the Mac App Sandbox makes me sad

lacquer.fi

Post reply on HN
Print view View original

161–170 of 200 posts

Re: Why the Mac App Sandbox makes me sad

#161

Post by dmbaggett »

dextorious wrote: post #136
dmbaggett wrote: post #48

This is all so well-played by Apple: evolve ever more locked down systems in seemingly consumer-friendly ways. Once consumers forget they can even install their own applications (except through the app store), OS X distribution will be just as heavily moderated by Apple as iOS distribution. Expect Apple, Microsoft, and Google to exert ever more control over distribution. The software industry is evolving into the "st…

"This is all so well-played by Apple: evolve ever more locked down systems in seemingly consumer-friendly ways. Once consumers forget they can even install their own applications (except through the app store), OS X distribution will be just as heavily moderated by Apple as iOS distribution." The "seemingly" part confuses me. Why seemingly? Either consumers will like the experience (as they seem to do in iOS and coul…

"Seemingly consumer friendly" because it may very well be so in the short term, but not, it seems to me, in the long term.

Short term: less malware, better UX. Long term: software distribution carefully controlled by a cartel.

Re: Why the Mac App Sandbox makes me sad

#162

Post by mitjak »

Angostura wrote: post #20
statictype wrote: post #3

This would worry me if there weren't at least two other major Operating Systems available to choose from. The Mac is moving more towards simplicity and safety - targeting normal consumers. That's fine. Ironically, now Linux and Windows (and anything else that comes up down the line) will have to serve as the 'Computer for the rest of us'

This would worry me if the AppStore were the only way to get aplications on to your Mac. I can see it being very disapointing for developers who enjoyed the convenience of the AppStore, but need additional functions. But I guess they will have to sell ex-Store I can also see the benefit of Apple being able to say that 'Anything you buy on the Store is safe(tm)'. However if Apple every makes teh Appstore a compulsory…

I think if that ever happens, we will basically have iOS X on our hands. Unless they want to completely merge the two operating systems, I don't see that happening anytime soon.

Re: Why the Mac App Sandbox makes me sad

#163

Post by ryannielsen »

natesm wrote: post #156
ryannielsen wrote: post #149

Earlier quoted context omitted.

Plugins can exist anywhere. They can be placed into the app's bundle without necessarily breaking its signing seal, they can exist within the app's container if the app has a way of copying them in (e.g. it advertises a file type, like Aperture's ".ApertureExport" bundle, so the user can double click to load the plugin, or it provides an "Install Plugin" feature somewhere), and they can exist anywhere in the user's h…

This is the one I am referring to: 2.16 Apps that download or install additional code or resources to add functionality or change their primary purpose will be rejected So I guess that you can have a plugin system as long as you don't provide an in-app way to download and install them, like Adium does?

As far as I know, yes, that is the case. I'm not an app store reviewer, though.

Re: Why the Mac App Sandbox makes me sad

#164

Post by bdash »

ricg wrote: post #52
nhaehnle wrote: post #2

In general, this type of sandbox is a Good Thing. I would love to live in a world where the default environment for any program is a very limited sandbox that can only interact with the outside world via standardized UI elements. That is, outside a data store specific to the application, it can only access files via the standard dialogs, and so forth. The potential for malware distribution would be significantly redu…

I just watched the Apple developer videos about App Sandboxing and have to agree that it in most cases it's a good thing. With that new enthusiasm I went ahead and tried the AppSandboxQuickStart code sample that loads a webpage in a WebKit WebView. Enabled sandboxing, app failed because of missing network.client entitlement. Enabled that as the tutorial said to get it to work: app still fails. Turns out that the WebV…

That sandbox violation is not coming from your application. WebProcess is the process used for rendering web content in Safari only.

Re: Why the Mac App Sandbox makes me sad

#165

Post by mbq »

mike-cardwell wrote: post #112
mbq wrote: post #98

Earlier quoted context omitted.

Because it is like X-raying people coming through front door to check if they are hiding anything metal having opened and unsupervised kitchen door. Plumbers are banned, yet you can still be killed with a ceramic knife by a polite assassin or with metal pipe by a brutal crook.

That analogy bears no resemblance to the issue at hand. These changes improve security. Just because they don't improve the security to 100%, that doesn't make them worthless.

The main problem is that it comes with a obvious loss of functionality which I doubt that can be leveraged with security gain -- the other thing is that it gives a faux sense of security to the user (i.e. yes, I have agreed for full file system access, but it was sandboxed, right?). Finally, the system is as weak as the weakest elements, and those seemingly lay in their own code (and can be fixed without hurting the functionality).

Re: Why the Mac App Sandbox makes me sad

#166

Post by jbk »

DrJokepu wrote: post #63
nknight wrote: post #7

I can think of only two GUI apps I semi-regularly use that can't fit within those restrictions: VMware Fusion, and Steam. Plugins are a red herring. Some poorly-designed plugin infrastructures will not be workable, boo-hoo. Valid use cases can be accommodated with proper message passing. Maybe we'll finally get applications that don't crash horribly because of buggy plug-ins?

Xcode, Firefox, Safari, Google Chrome, VLC Player, Dropbox, BBEdit, TextMate, StuffIt, UnRarX. These are all well-known OS X applications, all of them having important features that require being able to open an arbitrary file without user interaction.

As a dev of VLC, I must agree.

Opening a playlist or a file with linked subtitles needs to open an extra file after the first one.

Screen grabbing is nowhere to be found, not to mention CD/DVD access, or advanced networking, hardware decoding...

Re: Why the Mac App Sandbox makes me sad

#167

Post by ryannielsen »

ryannielsen wrote: post #145

Some points of clarification to eliminate some FUD, especially around plugins: - Signed and sandboxed applications are not prevented from using plugins. No code loading restrictions are placed upon such processes. Furthermore, Lion-only apps could employ an XPC based plugin architecture and entirely avoid loading code into their address space. - Plugins do not need to exist within the app's bundle. Plugins don't even…

It also appears that screenshots in in fact allowed. According to Gus Mueller, author of Acorn, the app linked to in the article when screenshots are mentioned: https://twitter.com/ccgus/status/132182964766375937

And confirmed by another Mac dev: https://twitter.com/gte/status/132183576841175041

Re: Why the Mac App Sandbox makes me sad

#168

Post by jbk »

ryannielsen wrote: post #151
DrJokepu wrote: post #63

Earlier quoted context omitted.

Xcode, Firefox, Safari, Google Chrome, VLC Player, Dropbox, BBEdit, TextMate, StuffIt, UnRarX. These are all well-known OS X applications, all of them having important features that require being able to open an arbitrary file without user interaction.

The editors you list all must open a file in response to some user action, right? They don't just automatically know that I want to edit ~/Documents/blah.txt. Ditto for the unarchivers and video players. I'm not certain why the browsers are listed, but they're in the same boat for local files (perhaps opening a file:/// url typed in the address field would be broken, but double clicking a local html file or using the…

> The editors you list all must open a file in response to some user action, right? They don't just automatically know that I want to edit ~/Documents/blah.txt. Ditto for the unarchivers and video players.

You open a playlist of files or a video file with linked subtitles, then you need to be able to open another file, that can be arbitrary located.

Re: Why the Mac App Sandbox makes me sad

#169

Post by mbq »

flomo wrote: post #118
mike-cardwell wrote: post #41

Earlier quoted context omitted.

How can you possibly claim that this wont increase security?

> How can you possibly claim that this wont increase security? I've honestly never heard of a third-party Mac application which contains spyware or steals personal information. It just does not seem like a huge problem which needs to be solved. (Of course there have been security issues with things like Adobe Acrobat and MS Office. But big ISV software is the least likely to be affected by app store restrictions.)

MacDefender?

Re: Why the Mac App Sandbox makes me sad

#170

Post by DrJokepu »

ryannielsen wrote: post #151
DrJokepu wrote: post #63

Earlier quoted context omitted.

Xcode, Firefox, Safari, Google Chrome, VLC Player, Dropbox, BBEdit, TextMate, StuffIt, UnRarX. These are all well-known OS X applications, all of them having important features that require being able to open an arbitrary file without user interaction.

The editors you list all must open a file in response to some user action, right? They don't just automatically know that I want to edit ~/Documents/blah.txt. Ditto for the unarchivers and video players. I'm not certain why the browsers are listed, but they're in the same boat for local files (perhaps opening a file:/// url typed in the address field would be broken, but double clicking a local html file or using the…

I listed the editors due of their project handling and "search in folder" features. I listed the browsers, of course, due to their abilities to browse local files, more specifically, be able to open other referenced local files (images, scripts, links); this is very important for web designers. Archives split into volumes (e.g a sequence of .rar, .r01, .r02 etc. files) are still common in some areas, tipically the user only had to open the first file in the sequence and then the archived opened the rest. Not to mention the obvious case of unextracting all files from an archive.
Post reply on HN