restrictions
Latest
Oman lifts restrictions on secure video chats
In an effort to help businesses and schools function remotely, Oman is lifting restrictions on some video calling services. Its Telecommunications Regulatory Authority (TRA) tweeted that it will allow Skype for Business, Google Meet and Zoom, so that organizations can better communicate "during this exceptional period."
LGBTQ+ creators file lawsuit charging YouTube with discrimination
In a federal lawsuit filed yesterday, a group of LGBTQ+ video creators claims YouTube discriminates against their content. The group alleges that YouTube suppresses their videos, restricts their ability to monetize their channels and enforces its policies unevenly, giving more leeway to producers with large audiences. According to The Washington Post, the suit argues that YouTube deploys "unlawful content regulation, distribution, and monetization practices that stigmatize, restrict, block, demonetize, and financially harm the LGBT Plaintiffs and the greater LGBT Community."
Tencent adds age-based playtime limits to ‘League of Legends’ in China
In the face of pressure from the Chinese government, Tencent and Riot Games have added age-based time limits to League of Legends in China, Polygon reports. Minors now get booted from the game after two hours of play, and the companies use China's national ID numbers -- which are used to make accounts -- to verify ages. Supposedly, the new rules are an attempt to curb gaming addiction.
China's supercomputers are the latest target in US trade war
The US and China have been locked in a race for the world's most powerful supercomputer. China was in the lead with its Sunway TaihuLight, which has a 93 petaflop capacity. But the US surpassed that last year, when it released the Summit, which can run at 200 petaflops -- or 200 quadrillion calculations per second. Now, the US is using export restrictions in an attempt to thwart China's supercomputing efforts.
France bans smartphone use in cars even when you pull over
Road deaths have been on the rise lately in France and with nothing much else to pin it on, authorities are going after scofflaw drivers who text or call. It's now illegal to hold your phone on public roads even when you're pulled over to the side of the road, whether you're blocking traffic or not, Le Figaro reports. The high court ruling means that taking what some consider to be a safe step -- pulling over to talk on the phone -- could still result in points and a fine of 135 euros.
FAA's B4UFLY app tells drone operators if it's okay to fly
Flying drones is a lot more complicated than it used to be. These days, drone pilots need to register their toys with the FAA, be aware of drone-specific laws and even notify local airports of their flights in certain sceneries. It's a lot to keep track of, which is why the FAA has released B4UFLY, a smartphone app designed to keep drone users informed.
Final Fantasy XIV patch 2.4 has a slightly bumpy release
Today you may not hear much from your friends playing Final Fantasy XIV, as the long-awaited Patch 2.4 is now live and kicking. It's a sizable content update full of quests, instances, and of course the new Rogue class and Ninja job. We've been reading up on the patch notes since late last week, although there are a few issues keeping this release from being completely smooth. Square-Enix noted that there are problems with chocobos getting stuck in their stables and said that new character creation may be restricted during more busy periods.
ArcheAge restricts chat for low-level characters
Papa Trion is lowering the boom on naughty chat in ArcheAge, as the studio announced recently that it will be restricting chat accessibility for low-level characters. From now on, players will need to reach level 15 to access faction, shout, trade, need party, and nation chat channels. Presumably this is intended to combat gold-selling spam and other unwanted advertisements from free accounts. Other changes for build 4.11 include a tougher Kraken, healer weapons as quest rewards, and larger warehouses. Trion says that over two million players registered for the sandpark MMO. [Thanks to Varth for the tip!]
League of Legends introduces Ranked Restrictions for toxic players
League of Legends is a really popular game, but it also has a pretty noxious community reputation. That's something that's on the forefront of the mind of the Riot Games team, and it's being addressed with the latest patch. Players voted down for negative behavior are already operating under a chat restriction, requiring them to play a certain number of games before they can speak in the game again. Now those players will see another restriction, though: the inability to access ranked play. Rank restricted players will have a certain number of games that they must play before they can return to queueing for ranked matches just like with chat restrictions. Players who are deeply into negative territory and rank restricted at the end of a given competitive season will also be ineligible for receiving special rewards for ranked play, meaning that poor sportsmanship doesn't pay at any level of the game. While there are potential abuses for the system, it's an obvious effort to make the play experience on all levels a more positive one for players.
EverQuest Next devs decide against class/race restrictions
Should EverQuest Next have class/race combo restrictions? This controversial question was at the forefront of the latest developer roundtable discussion following a player poll that showed 40% of fans were in favor of the game limiting combinations based on lore. Interestingly enough, the developers have decided against the plurality of the playerbase on this issue. The devs said that they never wanted to put players in the position where they'd make decisions they'd later regret. With over 40 classes, multi-classing, and all of the items in the world, the team felt that players would not be able to be informed enough to pick a race in the beginning if it would be restricted, class-wise, down the road. Another issue is if the team added new races and classes in the future, they'd be forced to arbitrarily restrict some people from playing them due to information the players didn't have up front. You can watch the full explanation from the team after the jump!
Kids' iPad magazine Timbuktu rethinks in-app purchasing model
Timbuktu is an iPad magazine meant for children, and as our friends over at TechCrunch have noted, its developers recently rethought how it implements in-app purchases. The previous incarnation of Timbuktu (and most famously, Smurf Village, among others), made in-app purchases too tempting and easy for children. The result was high rates of in-app purchases, which was good for the company, but bad for parents who didn't approve of the large associated costs. Before, Timbuktu had little virtual bubbles that you "popped" to make an in-app purchase. The interface was clearly designed to pique childrens' interest, perhaps too much so. Now, Timbuktu has implemented a subscription plan, so that parents can buy lots of content all at once, and then kids can be free to discover it themselves without accidentally spending any money they're not supposed to. That definitely sounds more reasonable. It's worth noting that there are other ways to block in-app purchases. For example, Apple's Restrictions settings lets you to disable all in-app purchases entirely. Also, you can customize the amount of time iOS will require your Apple ID between successful App Store purchases. By default, it's set to 15 minutes. Keeping your children from spending too much on in-app purchases is an avoidable problem, and it's good to hear companies like the makers of Timbuktu are taking steps as well.
Securing your iPhone or iPad for your children, Part 2: Setup iOS parental controls to prevent in-app purchases
There has been a string of high-profile cases where children have racked up thousands of dollars in credit card charges through in-app purchases. In these cases and others like them, the iOS devices used by the children have not been properly locked down by the parents. In this three-part series, we will show you how to set up a kid-friendly iTunes account, lock down your device to prevent in-app purchases and perform some maintenance that'll prevent your tot from sending emails or tweeting on your behalf. You can jump into part two below, where we take a deep dive into the settings and show you how to lockdown your iOS device. Set up a Passcode The easiest way to lockdown an iOS device is to add a passcode, which will appear when you turn on or wake up the device. The passcode will prevent your child from turning on the device and going to town when you are busy doing dishes, driving or otherwise occupied. Using a passcode is a first-line defense and won't prevent errant purchases. It'll merely give you control over the iOS device and let you determine when your child uses the iPad or iPhone. To set a passcode, go to Settings > General > Passcode Lock. Change the setting so that the Passcode is on, the Require Passcode is set to immediately and the Simple Passcode option is off. A simple passcode is a four-digit number that can be quickly learned by any tech-savvy child who watches their parent tap in the code. Select a longer alphanumeric code that'll be difficult for your child to enter, but easy for you to remember. Enable Restrictions (Parental Controls) Once you have a passcode on your device, you will want to dive into the Restrictions, aka Parental Controls. This is the one area you don't want to ignore. If you have a device that you are using with your child on a regular basis, be sure to configure the parental controls. To find the Restrictions, tap Settings > General > Restrictions. Tap "Enable Restrictions" and enter a four-digit password that your child won't guess. At the top of the Restrictions' screen is a list of apps that are allowed on your device. If you don't want your child accessing the camera, Safari, iTunes and other apps, you can turn them off here. When they are off, they no longer appear on your home screen. Directly underneath the allowed apps is the "Allowed Content" section. This section lets you set the ratings for Podcasts, Music, Movies and other media on the iOS device. You can restrict access to explicit content by adjusting these settings to an age-appropriate level. Also in this section is the In-App Purchases slider which should be set to off, if you want to block all in-app purchases. If you want to allow IAPs, you can leave them on and control purchases by changing the "Require Password" setting to "Immediately" and not the default 15 minutes. This will force your child to enter a password every time they try to make a purchase. Speaking of passwords, don't give your child the password to his or her iTunes account. It will give them unfettered access to their device and will undo all your security settings. Other settings in the Restrictions allow you to control what apps have access to your contacts, calendars and other personal information. You can read more about each of these settings in this support document on Apple's website. Enable Guided Access Guided Access is an accessibility option that was added in iOS 6. This feature limits your device to a single app and lets you control which app features are available. You turn on Guided Access by going to Settings > General > Accessibility > Guided Access. When you turn Guided Access on, you will need to select a passcode to turn it off and adjust the settings. Once again, choose a password that your child won't guess and you won't forget. Once Guided Access is enabled, you can launch the app you want your child to use and then triple-click the home button to turn the accessibility feature on. You can adjust the settings to disable motion input, touch input and hardware button control. You can also select the part of the screen that you want to disable. Once you are ready, click start to turn on Guided Access and your child will be limited to using this one app. You may not use Guided Access all the time, especially with older children, but I would recommend setting it up on each device that you hand over to your kids. You never know when you may need it. I also set it up on my personal devices for those moments when I hand over my iPhone to my children. It's easy to enable and it lets me give my phone to my child without worrying about them getting into my email or Twitter account. Restrict WiFi Usage One nifty way to limit your child's online consumption is to block their access to the internet using the WiFi access timers available on your AirPort wireless router. Macworld's Christopher Breen describes how to block iOS devices in an article from earlier this year. You will need to know the MAC address of the iOS device (Settings > General > About) and must have a Mac with the AirPort Utility software installed on it. You can follow his step-by-step procedure on Macworld's website.
How a kid-friendly app leaks mature content via YouTube
With the rose-hued glasses of nostalgia firmly in place, today's tech-tangled parents may long for a simpler pre-Internet time when kids simply got into fights or stayed out too late, rather than getting tangled up in sexting mishaps or giving out inappropriate personal info on Facebook. For all technology's hazards, however, it has given moms and dads the opportunity to engage and explore our kids' preferences in media and leisure activities collaboratively with them. When we're enabled by parental controls or app ratings to help our kids make good choices, that's a win. When the rating systems or the restrictions don't encompass an edge case, unfortunately, that's a problem. Reader Chris A. emailed us to point out a subtle gap in the App Store's rating system when it comes to games and other apps aimed at kids. The example app here is the Avengers Initiative game (US$6.99 and rated 9+ for cartoon violence), but several others exhibit the same potential issue. In the settings and social content area for Avengers Initiative, there's an option to visit the "Marvel XP" microsite for supplementary content, character profiles, videos and so on. In order to get to the good stuff, you've got to register a Marvel account; in fairness to the company and to Apple, there is an age challenge during registration that requires you to say you're 13 or older in order to sign up. A parent might sign up for a child, however, on the assumption that the web content in Marvel XP would be consistent with the rest of the app. Here's where it gets dicey: the video content in Marvel XP is hosted on YouTube, so if a young person taps on the Hulk's video introduction the player window that comes up includes the YouTube player bar on the bottom. Guess what happens if you tap the YouTube logo in the bottom right corner? Indeed, the device screen is taken over with the full m.youtube.com interface, including the search button. Funky sexy adult-type videos, here we come! You can see the steps to reproduce this in the video below (hosted, un-ironically, by YouTube). Sure, it's an obscure pathway to get to the fun stuff. But this is likely reproducible in most applications with embedded YouTube content, regardless of rating or intended audience. Disabling the YouTube app (pre-iOS 6) doesn't block it, nor would putting restrictions on Safari. It's simply not considered in the ratings matrix. The good news is, there may be a simple fix for these apps that keeps the video, but without the "let me see the whole world" button. YouTube's "modestbranding" flag, applied to the embed HTML snippet, should permit developers to embed video sans logo & link which may in turn keep the tots from meandering around. If the Ghostbusters and Avengers app teams took this simple step, that would help Chris's peace of mind when it comes to his kids' iPad time. Developers who don't have the correct embedding setup should probably let parents know that the apps they're browsing include a video escape clause. Another way around the whole problem: game devs, don't host your video content for your sub-17+ apps on YouTube at all. Pony up for a paid account on Viddler or simply run your own streaming server, instead. Rating apps on content and appropriateness is never going to be a perfect system. Most apps that provide web browser functionality should technically be rated 17+, which has been a point of contention for years now. On some level, that flag makes some sense; there's no way for the iOS restrictions system to control where those apps end up on the big scary Web. Different families will have different tolerances for exposure to edgy or inappropriate content on YouTube. (I think I hit my limit this weekend when the Harry Potter videogame playthrough chosen by my eight-year-old turned out to include a rather impressive amount of profanity.) But it's harder to have the conversation about what's appropriate or allowed if you don't even know about the library of out-there videos that's hiding in plain sight, right behind the Hulk.
Blizzard lifts Diablo 3's Act 1 restriction for new digital buyers
Patch 1.0.3a for Diablo 3 fixes an issue that restricted unverified digital purchasers to playing only up to level 13 and only in Act 1. Blizzard previously listed the restriction as a feature of patch 1.0.3, and later said it was an "unintended consequence" that players were unable to progress past level 13 and the Skeleton King in Act 1.Updating to the most recent patch will eliminate the Act 1 restrictions, but other limitations remain for digital purchasers, "in place to deter credit card fraud," Blizzard writes. These restrictions can last for up to 72 hours and remain as follows: No public game access for unverified digital purchasers No auction house access (real-money or gold) for unverified digital purchasers Unverified digital purchasers cannot trade items or drop items for other players to receive Unverified digital purchasers are not able to chat in any public or game channels Unverified digital purchasers cannot attach a custom message to friend requests, but they can send/accept friend requests, and play with their friends Global Play is not available for unverified digital purchasers
Nokia axes Skype client on Lumia 610, claims user experience wasn't 'up to par'
It took nearly a full month, but Nokia has finally been convinced that Skype is indeed incompatible with low-memory Windows Phones. In reaching out to a spokesperson, the company confirmed to us that it has decided to yank the official client from the Marketplace on the Lumia 610. The device -- which utilizes a scant 256MB of RAM -- originally allowed the service to be downloaded despite Skype's claims that 512MB was the minimum amount of memory required for the app to function properly. The internet phone service, as it turns out, was correct: Nokia, stating that the user experience is "workable" but not "up to par with Nokia's and Skype's expectation," has pulled the plug on any future downloads. Users who managed to snag the app before it disappeared can still enjoy (or hate, depending on your experience) it on their Lumia 610, but until Skype is able to lower the memory restrictions, it looks like everyone else is out of luck. Head below for the full translated statement.
Wings Over Atreia: 3.0 -- it's heeere!
Awwwww yeah! Update 3.0, baby! Come to me, features. Like Christmas for a five-year-old, this day seemed like it would never arrive for those of us who have been waiting for Aion's patch for what feels like forever. And ever. And then some. Aion: Ascension certainly took its jolly sweet time getting here, but now it finally has. Even better, you don't have to dodge creepy clowns or be sucked into a television screen to enjoy it. Now the question is, is the product really worth the hype? I know I have certainly dished out a fair portion of hype in Wings Over Atreia over the past couple of months while sharing my excitement. Too many delectable features were on the menu, things that would breathe more life into the game, for me not to indulge a bit. But as with any hype, there is always a chance for things to not live up to expectations. So is the new patch as grand and glorious as hoped? After my first few days in game, my answer is a definite...%Gallery-153202%
FAA to take 'fresh look' at gadget restrictions on flights
The only thing worse than the Terrible 10,000 Feet is the underlying sense that it's all so unnecessary. Why should using an iPad, Kindle or bag-holding alarm clock be banned during take-off and landing, even with all wireless comms switched off? Nick Bilton from the New York Times has been hounding the Federal Aviation Administration over this issue for a while, but he's suddenly received a reply other than "Just turn it off, sir." A senior official told him that the agency as decided to take a "fresh look" at the rules, not for cell phones, but for the myriad of other gadgets that can make a flight so much more peaceful and productive. Currently, airlines complain that they have to test each model of device individually, on every single plane in the fleet, and with a separate empty flight used for each test, before they're allowed to relax the rules for that model. That's why personal electronic devices remain so closely restricted, but also why there's so much room for a smarter solution -- even if there are still reams of red-tape to overcome before anything changes.
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.
The Daily Grind: How should free-to-play games restrict content?
It's the perpetual trouble of free-to-play games. The development team wants to give players access to as much as possible (so that the players enjoy the game and keep playing), but it also wants to give players incentive to pay (so that the development team can enjoy dinner and keep paying the rent). So there has to be some sort of throttle on what you can get for free, since otherwise the game is no longer operating as a business and has begun working as a charity. With the exception of games such as Guild Wars which require a box purchase, every free-to-play game has to place some restrictions on players who pay nothing. But what restrictions are the most fair? Giving out a baseline amount of content and classes for free, and then offering more content or classes for pay? Slowing experience gains without spending money? Or is there another system that you've seen in play that works better? Every morning, the Massively bloggers probe the minds of their readers with deep, thought-provoking questions about that most serious of topics: massively online gaming. We crave your opinions, so grab your caffeinated beverage of choice and chime in on today's Daily Grind!
Sprint launches Drive First Android app to curb texting and driving, keep chatty teens at bay
Are you concerned that your talky teenager is trying to keep up on the high school gossip whilst behind the wheel? Or are you a more experienced driver looking to get rid of the temptation to update your status at 65 MPH? Sprint's got you covered with Drive First. The app, announced by CEO Dan Hesse at CTIA in March, will lock up your phone when it detects you're in a moving vehicle; calls will be automatically redirected to voicemail and incoming texts can get automatically replied to with a customized message. The service costs $2 / month per phone after a 15-day trial, and unfortunately only is available for Android devices, though BlackBerry and Windows Phone support has been promised in the near future as well. We'd say the more the merrier -- for parents, that is. Head below for the full press release.
