Update: My friend, Chad, creator of Pear Note, has an interesting perspective that is much more in-depth than what I have written. While I don't agree with his conclusion, he is a successful full-time Mac developer where I have no Mac development experience. Also Chad has more SELinux background that I do.
There has been a lot of gnashing of teeth lately over Apple's forthcoming Sandbox restrictions on software sold through the Mac App Store. In the near future, applications sold through the Mac App Store will be confined by very restrictive security policies. These security policies will make it impossible for applications to do many of the things we are accustomed to applications being able to do, such as interact with other applications. Some have described this change, pejoratively, as the "iOS-ification" of the Mac. I think these people miss some important points.
I used to work at a company where most of my time involved developing either SELinux security policies (a technical mechanism that the operating system uses to restrict applications' behavior) or applications designed to be confined by SELinux policies. Unfortunately, although SELinux is extremely powerful, it isn't used to confine most Linux desktop applications. It exposes users to problems that are beyond their ability (or desire) to troubleshoot and fix. Having spent time working with under-appreciated access control mechanisms, I am really excited to see Sandboxes coming into the mainstream on an operating system known for its ease of use. This is a Good Thing for users.
SELinux is similar in some ways to Mac OS X's (and iOS's) Sandbox mechanism. These mechanisms enforce a system-wide security policy that cannot be overridden through traditional user-based file ownership and permissions. For example, an application executed by you shouldn't be allowed to change or delete all of your data (without asking you first) simply because you own the data. An unconfined application could be tricked into doing just that.
Apple has implemented a trusted process model in OS X Lion to handle risky behaviors. An application confined by a Sandbox profile might not be allowed to write its data to your hard disk. Instead, it has to send its data to a Lion-provided process whose job it is to write the data. That trusted process is only allowed to access data on the hard disk. It is not allowed to receive connections from other computers on the Internet. An attacker on the Internet would have to compromise not only your application, but also the trusted process in order to gain access to your data on your hard disk. Think of a building that requires entry through one door followed by another, and no single person has both keys. You have to co-opt both key holders to gain access.
Many things that applications normally do on their own will now have to be proxied through a trusted interface provided by Lion. Some things, such as adding cover art to iTunes albums, become impossible where no sanctioned interface is provided. In the near term, applications in the Mac App Store will become simpler and less capable because of this. I suspect that over time, though, Apple will provide more robust set of mechanisms that applications will be able to use to do more things. This way, applications will be able to do more on behalf of the user without introducing significant risk.
I like knowing that applications I install through the Mac App Store will be confined by a security mechanism that mitigates mistakes made by the developer. I'm happy with it as long as I can obtain applications from outside the App Store when I'm willing to assume more risk. You have choices. If you want an application that not only won't but can't eat your data (or syphon it off to the Russian mafia) get it from the Mac App Store. If you want an application that has more features--and more risk--buy it
elsewhere from Chad's website.