The Ultimate macOS Thread

Not just cost, but also simple availability of high-storage units. You can't get a 2 TB SSD drive no matter how much you want to pay.

That's what I was originally going to say, but it appears that if money is not an object...
 
Anyone here using Filevault? Whats the hit on battery life and general performance like?
 
Didn't notice any performance drop on my MacBook Pro, then again it was 2011 Core i7 with an SSD so it handled hardware encryption / decryption of everything on the fly :)
 
killpanda said:
What's so horrible about the screen on the 11"?
Click to expand...

For me, it's the aspect ratio. For such a small screen, there's very little vertical space, especially if you tend to leave the dock on the bottom of the screen.
Much prefer the 16:10 ratio of the 13".
 
I too vote for the MBA. You won't notice the speed difference of the CPU, mac software doesn't come on CD/DVDs anymore anyway, and the SSD is faster. Add to that the nicer screen and lighter formfactor, and the choice is easy. I've been drooling over one since they came out, but after getting my ToughBook, can't really justify another laptop (even if it is the polar opposite to the one I have).

Some day I'll take my ToughBook into a mac retailer and do a side-by-side photo :)
 
Last edited:
If I can't find my MacBook Pro back (which might actually just happen since we got the guys who took our stuff on CCTV), I'm probably going to invest in a maxed out 13" Air :)
 
/. said:
"And so it begins: Apple will require that all Mac apps submitted to the Mac App store stick to strict sandboxing requirements. This means you must ask Apple for read or read/write entitlements for additional folders outside your Application Support folder before your app is approved. There are also restrictions on direct hardware access, communication to processes your app did not start, or even something simple as taking a screenshot. All that is needed after this to turn your Mac into an appliance is to only allow app installations from App Store."
Click to expand...
http://apple.slashdot.org/story/11/11/03/1532203/apple-to-require-sandboxing-for-mac-app-store-apps
 
Dr_Grip said:
http://apple.slashdot.org/story/11/11/03/1532203/apple-to-require-sandboxing-for-mac-app-store-apps
Click to expand...

Oh my God! I've been using FreeBSD for years and it has sandboxing as well! Fuck obviously they are trying to trap me in! Oh and the sky is falling, damn you Al Gore.

Sandboxing is a well known security mechanism. Apple has been weary of viruses for a few years and is being extra paranoid. Nothing like an "AppStore spreading virus LOL" story to brighten up the PR department.

If modern OS level security mechanisms scare you, install Windows 9x and be happy.
 
Last edited:
The day the App Store becomes the only way of getting apps, I'm swtiching back to Windows.


However, I just don't see that happening.
 
Buktu said:
The day the App Store becomes the only way of getting apps, I'm swtiching back to Windows.


However, I just don't see that happening.
Click to expand...

Agreed. Everyone should stop freaking out.
 
but... PCI-e x8 2TB SSD'S!!!!!
(for a mere 10k euros)
 
This should help provide an insight into what sand boxing is. Despite what the conspiracy theorists think, I wager the move was done to simplify the certification process. They won't need to test for an application vomiting over /System or what have you if it is sandboxed to /Library/Application Support/ViperBondHiddenSexyCam.

http://arstechnica.com/apple/news/2011/11/apple-pushes-back-sandboxing-deadline-as-devs-struggle-with-tradeoffs.ars?utm_source=rss&utm_medium=rss&utm_campaign=rss
Apple pushes back sandboxing deadline as devs struggle with tradeoffs
By Chris Foresman
Apple has given developers a few more months to either come to grips with its new app sandboxing requirements or say goodbye to the Mac App Store. Apple originally set a November deadline for apps sold through the Mac App Store to use Lion's new sandboxing framework for increased security, but the company told developers on Wednesday that the deadline had been pushed back to March 1, 2012.

Still, while some developers were already prepared for the November deadline, others are struggling with what they see as imposing limitations or reduced functionality in the sandboxing APIs. Ars spoke to a few experts in order to understand the tradeoffs Apple's sandboxing implementation will cause both developers and end users.

Every app its own sandbox

iOS has, from the beginning, required all apps to run in their own "sandbox," partitioned off from other apps and part of the operating system. This increases overall security, as apps can't run roughshod over other parts of the system?they can only, in the worst case, ruin their own sandbox.

Our own John Siracusa described sandboxing in his epic Lion review:

Running an application inside a sandbox is meant to minimize the damage that could be caused if that application is compromised by a piece of malware. A sandboxed application voluntarily surrenders the ability to do many things that a normal process run by the same user could do. For example, a normal application run by a user has the ability to delete every single file owned by that user. Obviously, a well-behaved application will not do this. But if an application becomes compromised, it may be coerced into doing something destructive.
(Be sure to click the link for a more detailed explanation of Mac OS X's particular implementation of sandboxing.)

As Siracusa noted, Apple has slowly added sandboxing facilities into Mac OS X over the last few versions, but added APIs to allow third-party apps to use sandboxing as part of Mac OS X Lion. To encourage developers to adopt the sandboxing APIs, Apple first set a deadline that all apps approved for distribution via the Mac App Store would be required to implement sandboxing by November of this year.

Agile Bits was quick to add sandboxing support to its popular password locker app 1Password in anticipation of the original November deadline. While it took some work on the company's end, including a removal of some functionality and flexibility from the software, Agile Bits believes it was the right way to go.

"We're on board with the approach that customers shouldn't have to care about things like where their files are," Agile Bits spokesperson David Chartier told Ars. "Now that we've implemented it, down the road it's going to eliminate a ton of customer service problems for us, such as people putting their password store in a nonstandard place and then end up accidentally putting it in the trash or deleting it."

For instance, sandboxed apps can't open and close files in arbitrary locations on a user's disk without using the standard open/save dialog boxes. So, for 1Password to automatically open and write to its password database, it has to keep it in a special file system location that only it can use. This is similar to the restricted file system access imposed on iOS apps.

"A small portion of our power users are upset [about the change]," Chartier said, "and I think there are a few things Apple could do better to make things easier on both sides. But in general, we like the idea of sandboxing because its advantages in general security and simplifying things for the end user are worth it."

Bare Bones Software's Rich Siegel agreed that, in principle, sandboxing will benefit a majority of users. "Sandboxing is an excellent solution for the security issues that would otherwise cause Mac OS X to turn into a malware cesspool," he told Ars, "and without subjecting users to a numbing progression of 'Cancel or Allow' dialogs that habituate the user to click 'Allow' in order to get useful work done."

"For 99.44 percent of the applications out there, sandboxing is a workable technology, whose adoption curve is very flat and low-friction, and whose users won't notice any functional difference," Siegel said. "Our Yojimbo largely fits in to that category, I think. It's more of a consumer-level product of the sort that I believe was in mind when Mac OS X sandboxing was designed."

The problem, however, is the remaining 0.56 percent of apps and use cases where certain functionality has been expected and used for many years. For instance, apps that can arbitrarily browse the file system, or tell other apps to do something via AppleScript or other means, violate the sandboxing principle.

Losing control

Sandboxing is designed to prevent apps from doing things that users do not intend?e.g., an exploited app taking over the network and being used for a denial-of-service attack. "Where this runs into trouble, though, is the case of 'implicit user intent,' in which there are things that the user does want to do, but they didn't directly request action," Siegel explained. Bare Bones' BBEdit editor, if sandboxed, would not be able to do a multifile search and replace, show live folder views of complete programming projects, or integrate with version control systems.

"You quickly start running into problems if this sandboxing stuff gets carried to a rigorous and/or logical conclusion," Siegel said. "I'm sure there are lots of businesses who've built automation workflows, which fanatical sandboxing would completely break."

Another popular app that could not be translated to Apple's sandboxed environment is Panic's Transmit FTP app. "Directly displaying or interacting with disk contents is verboten," according to Panic's Cabel Sasser. Developers can request specific exemptions from Apple for various restrictions on a case-by-case basis, but Apple told developers that exemptions would only be granted for a limited time and quickly phased out after the new March 1 deadline.

Apple could mitigate some of the problems with improved APIs for developers to use. "I think Apple has a long way to go to provide equivalent new APIs for all the stuff Mac apps currently do the 'old, insecure' way," Siracusa said. "One can image a set of file system access APIs that also go through some trusted intermediary, but it might be a pain for developers and Apple."

The problem, as many see it, is that developers will either be forced to remove functionality that users have come to rely on or simply not sell their software via the Mac App Store. "The choice that you're given, as a developer, is a Hobson's choice," Siegel said. "The answer seems to be not selling through the Mac App Store, which really isn't an answer at all, because not being in the Mac App Store is not an option unless you're willing to walk away from a majority of your audience. And no sane businessperson would do such a thing."

So, developers can keep making apps that have full functionality, at least for now, but due to the popularity of the Mac App Store, they may only reach a shrinking audience. Or they could limit functionality and gain a wider audience, but the app may not sell well if it doesn't work as well.

Beyond that, the limitations that Apple imposes via sandboxing may not even bring the intended security benefits, either. "I don't think this will benefit security," Jonathan Zdziarski, a computer forensics and security expert, told Ars. "Apple already has a fairly decent security implementation incorporating FileVault 2, address space layout randomization (ASLR), and of course all of the security that's found in the Unix operating environment that's worked just fine for the past 30 years."

The ultimate downside, then, could be complete Apple control over which applications can be run on your system. "Sandboxing will severely limit the functionality of Mac applications, and may even make some applications impossible to use," Zdziarski warned. "The question really is, whether this has to do with security, or Apple's intent to exert control over what's installed on the desktop. This paves the path to lock down desktop machines in the same way that the iPhone or iPad are locked down, essentially eradicating any development that isn't sanctioned by Apple."

While we have grown accustomed to accepting these limitations on our iPhone and iPads, are we ready to give up that control on the desktop? Less technical users may welcome the improved security and simplicity without thinking twice about being able to arbitrarily browse the file system or cross-app scripting. We're just as sure most Ars readers would emphatically say "no way!"
Click to expand...
 
You must log in or register to reply here.
Top