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

151–160 of 200 posts

Re: Why the Mac App Sandbox makes me sad

#151

Post by ryannielsen »

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.

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 their Open… features would still work).

User interaction must happen at some point, otherwise the apps have no clue what files to open.

Xcode (and BBEdit's and TextMate's project features) and Dropbox are interesting cases. Dropbox can presumably ask for permission once for each directory the user wants to sync. It does, after all, already use a NSOpenPanel when the user asks to change the sync location. It remains an open question whether it can permanently persist that user-granted exception indefinitely. [1]

Xcode is special because opening a project will be a user-specific action, but then each referenced file will somehow need to be opened. There is no solution I'm aware of for that use case. If you're a developer in a similar boat, I strongly suggest filing a radar explaining how your app is broken by the lack of such a solution. I bet the BareBones crew is already working their WWDR contacts, making their needs clear...

[1] http://www.cocoabuilder.com/archive/cocoa/308884-sandboxing-...

Re: Why the Mac App Sandbox makes me sad

#152

Post by ryannielsen »

guard-of-terra wrote: post #109
gcv wrote: post #82

Earlier quoted context omitted.

Apple distributes the Xcode installer through the App Store. Normal App Store restrictions don't apply.

Can anybody else distribute a foo installer, so normal restrictions would not apply?

Nope. Xcode is special.

Re: Why the Mac App Sandbox makes me sad

#153

Post by pavlov »

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…

- Signed and sandboxed applications are not prevented from using plugins. No code loading restrictions are placed upon such processes.

Really? That's good news if true. Got a reference for that?

In any case, since loading plugins would be subject to the same restrictions as other file access, the app can't maintain persistently accessible references to the plugin files. The app would have to ask the user to manually pick each plugin using a file dialog, each time the app is run. This kind of "manually-aided binary loading" isn't really a plugin API anymore.

Furthermore, Lion-only apps could employ an XPC based plugin architecture and entirely avoid loading code into their address space.

Please elaborate. I still don't see how XPC can be used to implement a plugin architecture, assuming the Apple documentation is correct in stating that XPC services need to be located inside the main application bundle in order to be loaded.

Re: Thunderbolt -- the problem here is that even if a kernel extension driver is already installed, a sandboxed app can't access it. (The example case in my mind would be my own video capture app: it's got direct support for devices by Blackmagic Design, including their new Thunderbolt-based units. I'm using the vendor's API for this. If I were to sandbox this app, it would have to lose this functionality.)

[Edited this reply to add more details.]

Re: Why the Mac App Sandbox makes me sad

#154

Post by ldar15 »

fennecfoxen wrote: post #143
dextorious wrote: post #137

Earlier quoted context omitted.

"""But the Mac's becoming more of an appliance, and while it's safer, easier, and more convenient for most users, it makes it a substantially less desirable machine for me to hack on.""" You do understand that in Lion, say, nothing, absolutely nothing has been taken away from you that you could do back in 10.1 or even NeXT. So, this "the Mac's becoming more of an appliance" is just bullshit, just blindly following th…

Dude. We know how the iPhone works. It's easy to see Apple starting to bring the same sort of model to the MacBook. We're not blind. We can see where this is going, even if it's not there yet, and make reasonably informed guesses about what it's going to be like.

If the App store becomes the only way to install applications, then its back to linux for me. I don't really see that as a horrible dystopian future. Even if Windows 8 hardware gets locked down, there will always be a market for linux boxes. Unless the government mandates otherwise, in which case we've got bigger problems.

Re: Why the Mac App Sandbox makes me sad

#155

Post by lallysingh »

fennecfoxen wrote: post #143
dextorious wrote: post #137

Earlier quoted context omitted.

"""But the Mac's becoming more of an appliance, and while it's safer, easier, and more convenient for most users, it makes it a substantially less desirable machine for me to hack on.""" You do understand that in Lion, say, nothing, absolutely nothing has been taken away from you that you could do back in 10.1 or even NeXT. So, this "the Mac's becoming more of an appliance" is just bullshit, just blindly following th…

Dude. We know how the iPhone works. It's easy to see Apple starting to bring the same sort of model to the MacBook. We're not blind. We can see where this is going, even if it's not there yet, and make reasonably informed guesses about what it's going to be like.

Well, you can also just watch the derivative? When's the last time the OS had a major feature that was aimed at developers? I remember the early OS X releases coming out with advance after advance. The rumored ZFS integration was the peak of this awesomeness... At least dtrace was integrated.

The last thing I've seen is transparently compressed files; not exactly exciting. I think we hit the peak around the leopard-snow leopard range.

Re: Why the Mac App Sandbox makes me sad

#156

Post by natesm »

ryannielsen wrote: post #149
natesm wrote: post #16

Earlier quoted context omitted.

Is it possible to install the plugins to `~/Library/Containers/...` instead of the usual location? Not that loading code is allowed on the App Store anyways, unless you're Apple, of course.

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?

Re: Why the Mac App Sandbox makes me sad

#157

Post by mcherm »

Karunamon wrote: post #76
dlikhten wrote: post #22

Earlier quoted context omitted.

Sandboxing is great since less and less control is in the hands of the app. I am sure apple will keep rolling out features expanding sandboxing, this is just the default impl. This also means that basically it will be harder and harder for apps to be malware in an already hostile system. I wish android had this. Android needs this much more than iOS.

Why is this gettting downvoted? It's good security practice, and the fact that Android needs better sandboxing was a foregone conclusion.

What is foregone about that conclusion? My impression is that Android's sandboxing is quite nice, thank you. In fact, I think the biggest failing is that there need to be stronger ways to ESCAPE the sandbox (eg: to build a virus-checker or a backup program).

Re: Why the Mac App Sandbox makes me sad

#158

Post by xsmasher »

artursapek wrote: post #100
ootachi wrote: post #90

Earlier quoted context omitted.

"Will users forget they can just type a URL in, and instead install everything through their friendly neighborhood web app store? (Don't laugh.)" Who's laughing? All but two of the Web browser manufacturers (Opera and Mozilla, both of which are losing market share) seem to have vested interests in doing exactly this.

This reminds me of Steve demoing the first iPhone, when he pulled out the numpad in the Phone app and called dialing a number "real last-century." I think soon we will all have the bookmarked websites we regularly visit as browser-apps (contacts, if you will) with most of the rest being taken care of by hyperlinks, and once in a while one will have to pull out the URL bar to actually type an address in manually.

It's happened already, with bookmarks and search replacing URLs. Googling for Sony is faster than typing in sony.com, so why not?

The address bar would have faded into near-obsolescence if browsers hadn't smartened it up a bit, making it search your history and commonly used sites.

Re: Why the Mac App Sandbox makes me sad

#159

Post by ryannielsen »

pavlov wrote: post #153
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…

- Signed and sandboxed applications are not prevented from using plugins. No code loading restrictions are placed upon such processes. Really? That's good news if true. Got a reference for that? In any case, since loading plugins would be subject to the same restrictions as other file access, the app can't maintain persistently accessible references to the plugin files. The app would have to ask the user to manually…

> - Signed and sandboxed applications are not prevented from using plugins. No code loading restrictions are placed upon such processes.

> Really? That's good news if true. Got a reference for that?

https://devforums.apple.com/thread/108004 (Apologies to anyone not registered as an Apple developer.)

> Furthermore, Lion-only apps could employ an XPC based plugin architecture and entirely avoid loading code into their address space.

> Please elaborate. I still don't see how XPC can be used to implement a plugin architecture, assuming the Apple documentation is correct in stating that XPC services need to be located inside the main application bundle in order to be loaded.

The app can modify its bundle, so that's not the problem. While I haven't actually tried this myself, there's nothing theroetically preventing the app from copying a service into its Contents/XPCServices directory in response to some user action that makes that service available to the sandboxed app (e.g. they double clicked a file that's of a type registered by the app, or they invoked an open panel within the app somehow).

The bigger problems, and ones that I can't find solid docs on are:

1) Does the service's signature need to match the parent app's signature? The docs actually indicate the service might not even need to be signed.

2) Can the app easily enumerate services, to discover new ones? Presumably, this should be possible but, again, I've never tried it myself.

In the end, it may well be that XPC isn't an option for 3rd party out-of-process plugins. In process plugins are, as noted above, not a problem though.

> Re: Thunderbolt -- the problem here is that even if a kernel extension driver is already installed, a sandboxed app can't access it. (The example case in my mind would be my own video capture app: it's got direct support for devices by Blackmagic Design, including their new Thunderbolt-based units. I'm using the vendor's API for this. If I were to sandbox this app, it would have to lose this functionality.)

Ah, gotcha. I'm a little surprised to hear about that restriction, as I was the BT and Firewire restrictions. I'd have expected all of those to work, as long as your app was only using user-space APIs. Is the mach port lookup restriction what kills these? Have you contacted WWDR? We've got a WWDR contact that has been very helpful and proactive.

Re: Why the Mac App Sandbox makes me sad

#160

Post by heyrhett »

I think that it demonstrates that we've passed the era where people want "a computer" to do things. People want a smartphones, tablets, notebooks, etc. People are not buying these devices for their raw computing power, and they don't want the freedom to access all of it. People want these devices to "work" at their respective tasks.

Apple is becoming the sole gatekeeper of apps to their devices. For example, after begrudgingly allowing 22 or so "fart" apps into the app store, they said, "ok, we gave you some fart apps, now you have enough fart apps, we aren't going to allow any more fart apps into the store". If some developer comes up with the best fart app ever, there is no practical way for him to distribute it any more.

I see this as an insane amount of power for one company to have. Imagine if MS did the same thing with windows. If they did it 10 years ago, they would have been sued for monopolistic practices, but now that Apple's doing it, and Apple is a viable competitor to MS, can't MS do the same thing, and now we are stuck with basically 2 companies deciding all of the software that can be installed on 99% of the computers that people use?

This is a sad future to me.

Post reply on HN