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

Mac App Store apps must implement sandboxing as of March 2012

developer.apple.com

Post reply on HN
Print view View original

11–20 of 71 posts

Re: Mac App Store apps must implement sandboxing as of March 2012

#11

Post by sipefree »

kennywinker wrote: post #9

It's time to write the eulogy for application automation and inter-application communication on the Mac. AppleScript (beast that it is) was innovative when it was created, and still has not been replaced. Automator is built on AppleEvents, and with sandboxing will come a sharp decline in the number of applications that can receive AppleEvents and the extinction of apps that send them.

Not at all!

Sandboxing brings with it XPC, which is an IPC framework for doing very fast and awesome message passing.

It's got some great features for separation of privileges. For instance, you might have an XPC sandboxed process for, say, rendering a H.264 video to a buffer. That process never gets access to the filesystem, the graphics card, or anything apart from the strip of memory that contains the file, and the buffer it has to write its pixels to.

Then you can use this to render a H.264 video in your application, and if a buffer overflow is found that could lead to a video containing shellcode to be executed, you have no fear that bad things can happen to the filesystem or users' stuff.

If I'm not mistaken, I'm pretty sure XPC is how they implemented the crazy feature where you open a QuickLook window on an image or something in the Finder, and if you it the Open with Preview(.app) button, the Finder's QuickLook window turns into a Preview window.

Re: Mac App Store apps must implement sandboxing as of March 2012

#13

Post by fleitz »

biot wrote: post #8
LeafStorm wrote: post #2

Apparently, I am not authorized to view any information on sandboxing besides "[a]s of March 1, 2012 all apps submitted to the Mac App Store must implement sandboxing" and that it "is a great way to protect systems and users by limiting the resources apps can access and making it more difficult for malicious software to compromise users' systems." Apple's developer relations with anyone who doesn't want to fork over…

It's free to register as an Apple developer and your ID will then work: http://developer.apple.com/programs/register/ Though to your point, I'm not sure why Apple requires someone to login just to read the docs.

No it isn't. I'm an iOS dev but not Mac and I can't read the docs. You have to pay to read the docs and find out what sand boxing entails. But I suppose if you're not distributing through the App Store why would you even care?

Re: Mac App Store apps must implement sandboxing as of March 2012

#14

Post by kennywinker »

sipefree wrote: post #11
kennywinker wrote: post #9

It's time to write the eulogy for application automation and inter-application communication on the Mac. AppleScript (beast that it is) was innovative when it was created, and still has not been replaced. Automator is built on AppleEvents, and with sandboxing will come a sharp decline in the number of applications that can receive AppleEvents and the extinction of apps that send them.

Not at all! Sandboxing brings with it XPC, which is an IPC framework for doing very fast and awesome message passing. It's got some great features for separation of privileges. For instance, you might have an XPC sandboxed process for, say, rendering a H.264 video to a buffer. That process never gets access to the filesystem, the graphics card, or anything apart from the strip of memory that contains the file, and th…

I tried very hard at WWDC this year to get a comment on this. Nobody would clarify if XPC could be used in the way Apple Events are...

All the documentation I could find were about splitting your single app into multiple processes, and using XPC to communicate between them. Does XPC provide a way to query the interface of an app you don't own? Can I ask for an XPC "dictionary" a la AppleScript?

Re: Mac App Store apps must implement sandboxing as of March 2012

#15

Post by kennywinker »

teilo wrote: post #10

Time to settle down, people. This is not the bad news you think it is. Please take the time to read what exactly is entailed in Sandboxing a Mac App before you presume this is a restriction on your freedom. You can start here: https://developer.apple.com/library/mac/#documentation/Secur... The vast majority of apps on the App store can be sandboxed without effecting their functionality in any way. Sandboxing on OS X…

"Sending Apple events to arbitrary apps With App Sandbox, you can receive Apple events and respond to Apple events, but you cannot send Apple events to arbitrary apps."

"By using a temporary exception entitlement, you can enable the sending of Apple events to a list of specific apps that you specify..."

The word at WWDC was temporary exceptions are temporary and just there to ease the transition to sandboxing. I.e. they will be REVOKED at some point in the future.

Re: Mac App Store apps must implement sandboxing as of March 2012

#16

Post by extension »

This is the only sensible security model for third party software in the world of today. Actually, this is the only sensible security model in the world of ten years ago. Windows has been endlessly criticized for not sandboxing apps. It's gotta be done and Apple is doing the transition the way that has always worked for them: fast and ruthless.

Re: Mac App Store apps must implement sandboxing as of March 2012

#18

Post by lukifer »

cageface wrote: post #17

The real question is this: Is Apple going to eventually make the app store the only way of installing apps on a Mac? I think this is likely and if so is going to be the end of the line for me as an Apple customer.

I draw the line here too. I accept the control tradeoff on iOS because I view them as appliances, not computers, and there are upsides to the curated experience. But if I can't fully control my primary computing device, I'm out. (I'd be okay with the machine shipping in "grandma mode", so long as there's an official way to disable it completely.)

Re: Mac App Store apps must implement sandboxing as of March 2012

#19

Post by glassx »

cageface wrote: post #17

The real question is this: Is Apple going to eventually make the app store the only way of installing apps on a Mac? I think this is likely and if so is going to be the end of the line for me as an Apple customer.

Actually, the real question is: what would Apple gain from killing 90% of the app ecosystem?

There are some apps that can't be really sandboxed (Little Snitch, virtualization tools), some apps you can't sell on the AppStore (video/audio/photoshop plugins) and there's even Apple apps that aren't available there yet (Logic, Filemaker, ).

Also, Macs are the only way to write OS X and iOS apps, it would make the barrier to entry way too high for most people, shutting off potential developers. How would you write, say, your Rails backend to your iOS app, on your Mac, if it was locked down?

But yeah, I would jump ship to Linux immediately as well.

Re: Mac App Store apps must implement sandboxing as of March 2012

#20

Post by lukifer »

Though there have been many disturbing trends in the evolution of the App Store(s), this one is actually quite mild, if not welcome. Honestly, it's always unsettled me a little that any software can just start arbitrarily scribbling bits to the hard drive. (The system folder is protected, but my data isn't.) The concern is only a little about malware, and mostly about buggy code.

All the sandbox requires is that apps only have access to files when the user initiates the action. And unlike most App Store policies, you're also allowed to request specific exceptions as needed by your app, and I'm expecting they'll actually be reasonable about it. [1] This creates more work for developers, but I think overall these changes will help keep users' data safe.

As also mentioned in this thread, these changes have big implications for inter-app communication. But sandboxing doesn't take the capability away; it just requires devs to do more work, again in the name of user security. There will be a big usability hit on apps which don't see regular updates, and apps whose developers neglect to update this aspect of their apps. But the same capabilities will exist, and eventually most apps will catch up to the new norms.

[1] Although if Apple starts making stupid rejections and standing by them, then I take it all back.

Post reply on HN