sandboxing
Latest
Windows' built-in antivirus tool can run in a secure sandbox
Antivirus programs, by their nature, introduce a degree of risk. Since they have to scan malicious data to stop attacks (and thus need extensive permissions), a piece of malware that exploits antivirus flaws can typically run with impunity. That could be much more difficult if you're using Windows 10's built-in safeguards, though. Microsoft is gradually rolling out a Windows Insider preview where Defender Antivirus has the option of running in a sandbox -- the first "complete" solution to do this, the company said. Should the worst happen and malware targets Defender Antivirus, any hostile actions will be limited to the antivirus tool's environment instead of running amok on your PC.
Firefox's multi-process mode is coming to more users soon
Over the last few months, the developers of Firefox have been slowly rolling out technology that will bring the browser up to par with competitors when it comes to speed, security and reliability. Others like Chrome, Safari and Edge are already designed using multi-process, to separate tabs, add-ons and even rendering from the main browser. As it stands, Firefox 50 users with extensions approved for multi-process are already using the technology, which the team says has increased responsiveness by 400 percent, and 700 percent while pages are loading.
Adobe: Flash Player now sandboxed in Safari on OS X Mavericks
In a move that is designed to make playing Flash content on your Mac more secure, Adobe has announced that Flash Player is sandboxed in Safari on OS X Mavericks. A sandbox profile for the Flash plugin was created by Adobe for inclusion in the Webkit project, with Webkit being the browser engine behind the scenes in Safari. How does the sandbox profile work? It basically tells Webkit (and thus Safari) to allow the plugin to only read and write files to specific items, limiting just how much damage a malicious attacker could do when taking over control of Flash through a vulnerability. This keeps Flash-based infections from being able to persist for any length of time, and should also keep attackers from affecting other apps. Adobe's products, including Flash Player, the Reader program and Acrobat, used to be prime targets for attackers, but sandboxing and other security work has made them less attractive to the bad guys.
Chrome for Android's first post-beta update brings better sandboxing, other tweaks
Chrome users on Android might have felt a bit neglected over the last couple of months, during which Google pushed a few updates to its browser on iOS while leaving its own platform untouched after it dropped the beta tag in June. That changes today as the Android version is getting its own update, which the team says automatically brings improved sandboxing technology on Android 4.1 Jelly Bean to keep any potentially malicious websites contained thanks to the operating system's user ID isolation technology. According to the changelog it also integrates location preferences with system level Google apps settings, brings playback controls to fullscreen YouTube videos and fixes aimed at third-party input method editors (IMEs), which is helpful if you're typing in another language. There's also a few other security fixes and bugs squashed, check the Chrome releases blog for cash payout details or hit Google Play to grab the update.
Google Chrome for Windows gets more secure Flash player, gives users a browsing sandbox safety net
Chrome turned 21 last week, and in that new version, Google's made playing Flash videos in its browser even safer... for Windows users, anyway. This latest release puts Adobe's Flash Player plug-in for Windows in a sandbox, much as Chrome 20 did for Linux. This sandbox is "as strong" as Chrome's extremely robust native version -- even in Windows XP -- which means that Flash-borne malware can't hurt Microsofties. Securing the Flash Player plug-in is the result of two years of work, and was made possible by a new plug-in architecture Google co-developed with Adobe. In addition to the security benefits, the architecture has also brought performance improvements by way of a 20 percent decrease in Flash crashes and GPU acceleration for smoother scrolling and faster Flash rendering. And, while the immediate good news is for Windows users, Google has assured us that a port for OS X is in the works, and it hopes to ship that Mac version soon.
Marco Arment on the Mac App Store's future
Marco Arment, the creator of Instapaper, weighed in with his thoughts on the future of the Mac App Store. He argued that, unless Apple changes some of its rigid policies, the Mac App Store is doomed. He pointed to the recent departure of the email client Postbox, which in part was the result of Apple's strict sandboxing requirements, as an example of what the future holds for the Mac App Store. Because of Apple's policies, Arment predicts that an increasing number of developers are going to leave the Mac App Store. Arment writes, "The problem with sandboxing isn't that any particular app is incompatible with the current entitlements. It's a deeper problem than that: Apple is significantly reducing the number of apps that can be sold in the Store after people have already bought them." This developer departure will not only affect developers, it will also affect customers who bought a piece of software that is now gone from the App Store. Arment says that even he has "lost all confidence that the apps I buy in the App Store today will still be there next month or next year." It isn't just sandboxing that's causing some developers to leave. The lack of a paid upgrade system, no access to important customer information and no volume discounts are making some developers return to selling their software through their own storefronts. Arment makes a compelling argument for buying apps directly from the developer instead of through the Mac App Store, even through the App Store is convenient. You should take the time to read his post and consider what he says the next time you click on the "Buy App" button. #next_pages_container { width: 5px; hight: 5px; position: absolute; top: -100px; left: -100px; z-index: 2147483647 !important; }
Mountain Lion 101: Gatekeeper controls app launches for security's sake
Gatekeeper isn't the most obvious feature of the new OS X Mountain Lion system that you probably downloaded and installed yesterday, but it might be one of the most important. Gatekeeper essentially oversees a list of verified developers who have applied for and received a Developer ID from Apple. It also allows you to specify whether your Mac will install apps only from the App Store, from the App Store and this list, or from anywhere you want. If you choose the Mac App Store only, you'll be able to make sure that everything you install has gone through Apple's approval process, which is about as protected from malware as you can get. When you installed Mountain Lion, every app that was already on your Mac got a free pass as far as Gatekeeper is concerned. The apps were grandfathered in as already having been run and cleared; since Gatekeeper works by preventing the first launch of an app, those apps are OK. In fact, you can keep the "Mac App Store and identified developers" setting turned on for safety while still installing and running non-signed apps; just right-click (or control-click) the unsigned app and choose Open. Gatekeeper will prompt you for a single-app exemption and if you're OK with it, the app will launch from then on. Now, not everybody appreciates Apple's "walled garden." Some developers take issue with the fact that they need to be "verified" by Apple before releasing and running software on the Mac. Gatekeeper is also responsible for "sandboxing" applications, which means keeping applications from changing files on parts of your computer that they don't usually interact with (though this does cause problems for apps that do want to dip into your personal system files, usually just to make things easier on you). At any rate, sandboxing and Gatekeeper are a reality for now. If you want to tweak your Gatekeeper settings, you can find them in the System Preferences screen under Security and Privacy. #next_pages_container { width: 5px; hight: 5px; position: absolute; top: -100px; left: -100px; z-index: 2147483647 !important; }
Sandboxing keeps TextExpander 4 out of the Mac App Store
Smile released TextExpander 4 today, with a whole slew of new features. But don't zip over to the Mac App Store to find it -- the company is one of the first and most notable to remove an app from the Mac App Store as it can't be sandboxed. Sandboxing is required for Mountain Lion apps that will be sold through the Mac App Store, and protects systems and users by limiting the resources apps can access. That doesn't mean that TextExpander 4 cannot be used on Mountain Lion Macs; in fact, Smile made a point in their PR blast this morning that the app is signed with a Developer ID from Apple to work with Gatekeeper in Mountain Lion. The list of new features is pretty lengthy: New fill-in types: multiple line text fields, pop-up menus, optional text sections Supports default values for text and popup fill-ins Edit fill-ins and options with popup interface Expand snippets and switch apps while using fill-ins Improved statistics with graphical display (and the ability to tweet your stats) Hands-on tutorial for new users Contextual menus for snippet editor and list Updated appearance for Lion and Mountain Lion French and German autocorrect groups So if TextExpander 4 isn't in the Mac App Store anymore, how do you purchase it? Easy -- just go to the Smile website and download a fully-functioning demo, and you can purchase a license from within the app. The app sells for US$34.95, a family pack is $44.95, and an office pack (covers five users in an office) is $99.95. Upgrades are free for users who purchased TextExpander after January 15, 2012, and $15 for those who purchased the app before that date. The upgrade can be purchased from the app as well.
Apple publishes guide to iOS security
Security on iOS devices is becoming more of a hot topic these days, what with security notables like Eugene Kaspersky warning of future malware attacks that could take down the immense monoculture operating system. Apple's not ignoring the threat; in fact, the company has published a 19-page iOS security document outlining the company's commitment to security on the mobile platform. The free PDF document, available here, describes Apple's approach to security. The system architecture section details the integration of hardware and software on the devices and how it allows for the validation of activities through all processes. For example, when an iOS device is first turned on it goes through a cryptographically signed boot up process, each step of which proceeds only after verifying the chain of trust. There's a description of how app code signing and sandboxing are used to ensure that apps can't compromise the system or other apps. I personally found the hardware security features built into every iOS device to be fascinating -- a dedicated AES256 crypto engine lodged between flash storage and system memory, using the device's UID and a group ID to cryptographically tie data to a particular device. There's also a fully detailed description of device access and network security. The document should be of great interest (and comfort) to those deploying large numbers of iOS devices in enterprises and government settings.
Does Gatekeeper point the way to an App Store-only OS X?
Apple's announcement of Mountain Lion included many promised new features, including a stronger focus on the Mac App Store than ever before. Two significant new features, iCloud document syncing and Notification Center, are only accessible to App Store apps, and the new Gatekeeper security tool will include a setting to lock a Mac down so it can only run software purchased from the App Store. All this has (probably inevitably) got people wondering if this is the first step towards a version of OS X that will only run programs from the App Store -- a world where indie developers who cannot or will not use the App Store as their distribution platform will be frozen out altogether. I think that's an unlikely end state (making my headline fully Betteridge compliant), and so do some prominent indie developers, but I also think the issue is worth examining. A brief recap of the App Store When Apple added the App Store to iOS in 2008, it was a revolution in more ways than one. For the first time, we had a major general-purpose computing platform where software developers could not freely distribute their work to a wide audience; a platform where users could only purchase and download approved programs from a central, controlling authority. This wasn't a new idea -- gaming consoles have been using this "walled garden" model since the earliest Atari and Mattel consoles -- but it's the first time it had been applied to a device that some might consider a successor to the personal computer. So powerful and successful was this idea that we had to invent neologisms -- "jailbreak", "sideload" -- to describe processes that we had taken utterly for granted for the first thirty-five years of personal computing. Now, I'm not suggesting that the App Store is bad. Although it undeniably introduces new restrictions on how we use our expensive devices, the upside is a frictionless user experience for discovering, installing, upgrading, and uninstalling apps that had never been seen before outside of console gaming. Coupled with Apple's economically viable micropayments infrastructure, this spawned a sprawling "appconomy." Hundreds of millions of users spending billions of dollars on apps from millions of developers; a fluid, dynamic software market the like of which the world has never seen the like of which. Back to the Mac In early 2011, Apple brought some of these principles to the Mac with the release of the Mac App Store. Like its iOS ancestor, this also promoted app discovery and management -- but with one key difference: it's not the only game in town. OS X on the Mac still has its traditional ability to download and install software from... well, anywhere. The Mac App Store also brought some restrictions to what an App Store-purchased app could do, but nothing too onerous. At the same time, it offered access to Apple's payment processing engine, meaning indie devs could spend less time looking after financial transactions and more time cranking out great code (at the cost of the familiar 30% "rake" of Apple fees). Everybody wins. Many developers found that their users quickly moved to accept and then prefer the Mac App Store. Reports of great success with their early releases were plentiful. For example, graphics manipulation program Pixelmator grossed $1 million in 20 days after announcing it would be an App Store exclusive. The authors of the Sparrow email client were very happy with the App Store. Other success stories abounded. Confined to the sandpit For the best part of a year, everything was happy in App Store land... but as of March this year, Apple was going to require all App Store apps to run in a "sandbox" (although this deadline was recently extended to June). This means, amongst other limitations, that each app's access to the underlying system is sharply curtailed, to the point where an app can only read and write to approved directories within the user's home folder -- and it requires explicit permission to do even that. An app has to specify which "entitlements" it needs (specific system permissions and capabilities) to get its work done; Ars Technica's book-length Lion review by John Siracusa has a great sandboxing section examining how this is managed. This set of restrictions affects many existing apps for the worse. Craig Hockenberry of the Iconfactory reported that the company successfully ported xScope (after having problems with a bug relating to symlinks in home directories). He noted, however, that some apps would never be effective in a sandbox; the example was Panic's Transmit, an FTP client, which requires wide filesystem access and probably couldn't be meaningfully ported to the App Store under the sandboxing rules. Hockenberry also told me that two other pieces of popular Iconfactory software, CandyBar and IconBuilder, could never work with sandboxing. The former modifies system files and the latter is a Photoshop plug-in. Some developers, seeing the sandbox writing on the wall, are being forced into difficult decisions regarding their App Store offerings. Manton Reece of Riverfold Software has announced that his ClipStart video library tool will be withdrawn from the App Store altogether because of incompatibility with sandboxing. This is particularly troublesome for users who have already bought the App Store version of his app; Reece cannot easily identify them to give them an upgrade to a non-App Store version, nor can he offer them new versions of the app within the App Store's framework. To his enormous credit, Reece is willing to "honor Mac App Store receipt files" -- presumably via a tiresome manual process -- and provide extra serial numbers for customers migrating to new computers. For similar reasons, and with similar problems for users, Atlassian Software's SourceTree is also leaving the App Store. Even apps that don't seem to require system-wide file access can fall foul of sandboxing. Any sandboxed app can open any file anywhere on the system via the File > Open menu, because the sandbox presents the standard OS X dialog window to the user with special elevated permissions. But Gus Mueller of Flying Meat, father of the image editor Acorn, tweeted "just discovered you can't use AppleScript to tell (sandboxed) Acorn to open an image it hasn't opened already." All this has provoked some understandable bad feelings. As Red Sweater Software's Daniel Jakult forcefully put it, "Shame on you, Apple. Your developers shed blood, sweat, and tears to succeed on the Mac App Store. Now you drop them with misguided policy." Jakult elaborated on his position in a blog post where he outlined the changes he'd like to see made to sandboxing to make it more workable for everyone. Mountain Lion Mountain Lion, the next version of OS X, will add further fuel to the fire. It adds a new security system, Gatekeeper. On its highest setting this will only allow programs downloaded from the App Store to run. This isn't the default, however; on the out-of-the-box medium setting, the Mac will run apps from the App Store and those digitally signed by a process carried out between the dev and Apple. This process doesn't cost the devs anything (beyond their existing $99 annual developer membership fee) and doesn't restrict what the app can do. It is designed to offer a halfway house solution between the locked down App Store and the anything-goes wild blue Internet. After all, Apple might not have a malware problem today, but that could change in the future. Finally, Gatekeeper's lowest setting allows all apps to run unfettered -- just like all previous versions of OS X. It's possible that Apple planned this split approach all along -- although if so, it was rather mean-spirited to not start off requiring sandboxing for all App Store apps. Yanking the rug out under existing apps isn't good for developers or users. It seems more likely to me that these changes are the result of a genuine strategy shift within Apple, or possibly the sandboxing/entitlements infrastructure was simply not fully baked enough in 10.7 Lion to permit most apps to work with it effectively (including those using Apple's own AppleScript interapplication framework). Still, after a somewhat winding road, we're arriving at a good place with Mountain Lion. Users who don't adjust the default setting will be able to run apps from the App Store and elsewhere with a degree of malware protection, and devs can distribute apps that fit the App Store's slightly simplistic model there whilst also distributing signed apps via other channels. Great, right? Well, I still see a few problems with this. Mixed feelings about the App Store Firstly, as it stands, every third-party app on your Mac today won't run on Mountain Lion, as they are not digitally signed. This means if you upgrade you're going to be plagued with "this app is not trusted" messages (you can enable Gatekeeper on OS X 10.7 to get a taste of how annoying this is). If you have a lot of apps -- particularly older apps that might not ever receive digitally signed updated versions -- this might become the Mac equivalent of Vista's hated User Account Control prompt. If so, many existing users might end up turning Gatekeeper off altogether, rather defeating the point. The second problem is the ongoing FUD being generated around the Mac App Store as a result of the ongoing painful process of enforcing sandboxing. Apple has twice extended the deadline to switch it on -- it was originally last November. In the mean time, I and other Mac users I've spoken to have found ourselves holding off on App Store purchases, or actively sought out non-App Store versions of apps, to avoid getting into a state where we have a licence for an app that is removed from the store. The third issue is commercial pressure. What if, in the future, users come to view programs not on the App Store with disdain for missing features or even outright suspicion at a perception of lower software quality? So far I don't think this has happened, but it's a possibility in the future. If sales outside the App Store begin to drop, devs will come under a covert pressure to move to distributing their wares via Apple. They might then face an unpalatable choice between dwindling sales or neutering their programs to comply with sandboxing. App Store only APIs With Gatekeeper and app signing, Apple seems to be proposing a three-tier system -- App Store apps in the first tier, digitally signed apps in the second, other apps in the third. In theory, apps in tier two and three are equal, but the ones in the App Store are limited by the sandboxing requirements. It's not that simple, however. A subtlety arises from the existence of features that are only accessible to the App Store apps. Two big new parts of Mountain Lion -- iCloud document syncing and Notification Center -- are described as being only useable to App Store programs. This widens the gap between the first and second tiers, particularly if the hunches of a few developers I spoke with are right and Apple continues to make marquee OS X features App Store-exclusive. Now to be fair to Apple, there is a big mitigating factor, because both of these services use server-side resources Apple has to maintain with no direct income. iCloud, for one, clearly relies on cloud storage to work and cloud storage doesn't come cheap. Notification Center is more puzzling. At first, I thought it worked primarily like Growl -- in other words, it was a way for an app already running on my Mac to bring something to my attention. Fellow TUAW writer Chris Rawson and Iconfactory's Craig Hockenberry told me I was wrong, so I dug deeper and talked to a few developers. Anand Lal Shimpi's investigation showed that, in the current developer beta, Mountain Lion has two types of notifications -- local ones, that can be sent by any app, and server-side push notifications, which can only be associated with App Store programs. Jonathan George, CEO of Boxcar, told me that for his company the push notifications are far preferable, even on OS X. On iOS, any app that wants to notify the user arbitrarily (except Apple's apps like Calendar and Mail, which can use private APIs) needs server-based push notifications as a workaround for the lack of always-on backgrounding. It initially seemed to me that this is less important for OS X. Consider my Twitter client, which is always running on my Mac. It's checking every few minutes for new messages and can send a ping to Notification Center without any external servers. This, however, can take a few minutes -- a server-side push is realtime, or at least, really really fast. This is clearly better for some types of apps than local-based notifications coming from a polling loop. So what about App Store-only? To come back to the question I opened this piece with: could/would Apple mandate, in a future release of OS X, that the App Store would be the only game in town for getting software onto the Mac? Well, perhaps "could" is the wrong word. Apple certainly could, but I think we're a long way away from a world where most users would approve -- and for those who are comfortable with it, they'll be able to switch Gatekeeper into full-on paranoia mode and achieve the same end. Furthermore, if Apple was planning it for the future, I don't think we'd have seen Gatekeeper's middle setting introduced at all. The mere existence of this feature underscores that Apple is serious about giving users some extra malware protection via code signing without mandating the App Store. Indeed, Panic's Cabel Sasser asked an Apple representative about this when he was briefed on Mountain Lion and he reported that "for what it's worth, they told me point blank that they value independent apps and do not want them gone." This code signing option is not only a technical solution, but also grants indie devs working outside the App Store a veneer of respectability that might help make some less experienced users more comfortable doing business with them. There's also the question of professional-level software. It seems rather unlikely that the Adobes, Avids and Microsofts of this world would be happy to hand 30% of the sales of high end programs like Creative Suite or Office to Apple, as would be required if these apps were put in the App Store. Do those companies need OS X more than Apple needs them? It's debatable, but it's a game of chicken Apple would perhaps be wiser to stay away from. It's not dissimilar to the row about in-app purchases under iOS and apps like Kindle, and Apple lost that one. A tale of two app stores I think Apple, in simultaneously watering down the existing App Store via sandboxing and giving a non-App Store mechanism for developers to bless apps, has created a segmented market. It seems to me we're going to end up with the App Store populated by smaller apps from smaller developers (who will find the support of Apple's payment processing infrastructure compelling) and larger but relatively simple apps for which sandboxing doesn't chafe too much. Meanwhile, we will hopefully still see a vibrant indie dev scene outside of the App Store. Indeed, by enforcing sandboxing, Apple might have just given the alternative channels a lifesaving boost... but by locking key OS X features up to only be accessible to App Store software, it's simultaneously making it harder for non-MAS indie devs to compete. It's too early to tell which of these factors will come to dominate over the others. This is assuming, of course, that Apple sticks by its guns. The slipping schedule for essential sandboxing suggests Apple is perhaps a bit uncertain or conflicted about the way forward here and maybe we will see sandboxing significantly relaxed or expanded before it becomes mandatory. I'll end with one piece of wild speculation, because I'm a blogger and because I'm under my House of Crackpot Theories quota for this month. If an existing sort-of-an-app-store service like MacUpdate took Apple's digital signing certificate and ran with it, it's not impossible we could see an Unofficial App Store emerge. One which requires digital signing of all the apps, and offers developers a payment processing and download hosting service, but does not require sandboxing or unpredictable app approval processes. I think Apple's sandboxing policy may create a gap in the market by wilfully narrowing the scope of the App Store. I don't know if that gap is big enough for someone to wedge an entire new product into, but I'd throw money at anyone who's willing to try. The author would like to thank everyone who helped compile the information in this article: Jonathan George, Craig Hockenberry, Chris Rawson, Erica Sadun, Anand Lal Shimpi, Fraser Speirs, Steve Troughton-Smith, and the other devs I spoke with off the record.
Apple: developers now have until June 1 to sandbox apps for the Mac App Store
Back in the fall, Apple gave developers an ultimatum: sandbox your applications, or see yourself out of the Mac App Store and sell your apps elsewhere. Originally, devs had until March 1st to make the change, which limits the resources apps can access, thereby making a malware infection less likely. Still, sandboxing inherently means less control for developers: the fewer resources an app can use, the less it can actually do. Well, code monkeys, you've now got a few more months to decide which camp you'd rather be in: Apple has extended that deadline to June 1st. As MacRumors notes, the move comes amid mounting concerns from developers, who have been complaining of bugs and other issues associated with the sandboxing process. In a statement on its developer site, Apple gave a pithier explanation, saying it wants to give devs more time to make use of new sandboxing entitlements available in OS X 10.7.3, along with new APIs in Xcode 4.3.
Google's 'Bouncer' service scans the Android Market for malware, will judge you at the door
Google has had its fair share of malware-related problems in the Android Market, but that's hopefully about to change, now that the company has announced a new security-enhancing service. Codenamed "Bouncer," Mountain View's new program sounds pretty simple, in principle: it just automatically scans the Market for malware, without altering the Android user experience, or requiring devs to run through an app approval process. According to Hiroshi Lockheimer, Android's VP of Engineering, Bouncer does this by scanning recently uploaded apps for spyware, trojans or any other lethal components, while looking out for any suspicious behavior that may raise a red flag. The service also runs a simulation of each app using Google's cloud-based infrastructure, and regularly checks up on developer accounts to keep repeat offenders out of the Android Market. Existing apps, it's worth noting, will be subject to the same treatment as their more freshly uploaded counterparts. Lockheimer went on to point out that malware is on the decline in the Market, citing a 40 percent drop between the first and second halves of 2011, and explained some of Android's fundamental security features, including its sandboxing and permission-based systems. Head for the source link below to read the post in full.
Apple to require sandboxing in Mac App Store apps as of March 2012
Apple sent an email to registered developers today that's bound to ruffle some feathers -- again. As of March 2012, Apple will require all apps submitted to the Mac App Store to implement sandboxing. This isn't a new development, as Apple was initially going to require sandboxing starting in November of this year. Apple has apparently delayed implementing the rule for another few months, but the requirement itself may cause challenges for some Mac developers. Apple's motivation behind requiring sandboxing is all about security: "Sandboxing your app 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." But the company's all-or-nothing approach is potentially problematic; "As of March 1, 2012 all apps submitted to the Mac App Store must implement sandboxing," Apple says. Over the past few months, developers ranging from Daniel Jalkut to Dr. Drang to Real Studio to Peter Sichel have pointed to flaws and shortcomings in the sandboxing approach, including a buggy Carbon implementation and questionable support for most AppleScript-centric automation tools. Jason Snell and Andy Ihnatko have weighed in as well, concerned that sandboxing may lead to a dumbing down of Mac App Store options or the death of AppleScript itself. (Not all developers are upset, to be sure.) The sort-of good news is Apple does allow for some exceptions to its pending sandboxing policy. "If your app requires access to sandboxed system resources you will need to include justification for using those entitlements as part of the submission to the Mac App Store," Apple says. But then there's the bad news: "Apps that are being re-engineered to be sandbox compatible may request additional temporary entitlements. These entitlements are granted on a short-term basis and will be phased out over time." Before the inevitable complaints about this policy kick in, it's worth taking a step back and remembering that unlike the iOS platform, the Mac App Store isn't the only legitimate way to get apps onto a Mac. That's probably cold comfort to developers who have found the Mac App Store an easier and more lucrative channel for app distribution than the traditional methods. There's also the fact that any discussion that begins with "The Mac App Store isn't the only way to get apps on a Mac" inevitably ends with the ominous pronouncement "yet." That said, just like some iOS App Store restrictions, this new policy seems a bit on the extreme side. Just like the "no third-party IDEs" rule for the iOS platform last year, it also seems like a policy born in committee that may have sounded like a good idea to Apple at the time but is eventually destined to be modified or deprecated once its real-world implications for the Mac platform become clear. The fact that Apple has already delayed implementing the sandbox requirement by five months could mean further reprieves or workarounds for developers with affected products.
Choose My Adventure: Making the world (a better place?)
Here we are, drawing closer to the end of our Choose My Adventure journey, and I feel like I have just barely gotten started in Xsyon! There is so much left to do; I haven't even scratched the surface of my goals yet. Since construction is a slow process and gathering resources is taking longer and longer each day (you should see the workout I get hauling logs!), my personal fortress is still just a few completed walls and one pillar. I also haven't managed to circumvent the lake, find any chalk, or convince anyone to let me be President/Supreme Ruler of the Lake. All right, maybe I haven't really tried hard at that last goal, but this week has seen your CMA correspondent meeting and greeting neighbors throughout the region, gathering resources, politely declining tribe invites (I will remain true to the vote throughout our adventures), and attempting to improve my skill in architecture. Also, I have enjoyed some relaxing fishing. As jaunts into the wilds for wood became longer each day, I kept watch over my shoulder with a touch of apprehension, always on the lookout for hostile folks and animals alike. There is always some question as to whether or not the elusive animals are in the game, but I have had a couple of run-ins with a mama and baby bear that ended poorly for me, so I try to never let my guard down. What else did I learn this week about life on the shores of Lake Tahoe? Hike past the break to take a look at this week's adventures in Xsyon and then vote on how we approach combat for our final installment of Choose My Adventure.
