Inside App Extensions: Apple, Inc's new Widgets & Keyboards similar to Android's, but secure

Posted:
in iPhone edited July 2014

At WWDC, Apple unveiled a new App Extension architecture for both iOS 8 and OS X Yosemite. Here's how the new extensions enable a new type of widgets in Notification Center for both platforms, along with enabling third party Custom Keyboards for iOS.

 


Widgets Custom Keyboards





Apple introduced a wide variety of new avenues for third party development under iOS 8 and OS X Yosemite that are all tied together by the common thread of App Extensions. The previous article examined Photo Editing Extensions for Apple's new Cloud Kit-savvy Photos app.



This article examines how the same underlying technology is being put to work to create "Today Extensions," which are widgets that will appear in Notification Center, as well as Custom Keyboards for use on mobile devices.

 

Is Apple just really slow at stealing Android features?





Home screen widgets and third party keyboards (which replace the default system keyboard) have been associated with Android for the last five years as something iOS has lacked.



Given that Apple created the concept of Desk Accessories as mini apps for the Mac desktop back in 1981, and that OS X Tiger promoted more recent Dashboard Widgets back in 2005 (before Google even acquired Android), it might make you wonder why Apple is only now introducing standalone widgets for iOS.



Custom Keyboards pose a similar quandary: iPhone presented a virtual onscreen keyboard when it debuted in 2007 as one of its primary differentiating features. Additionally, among the first iOS App Store titles in 2008 was ShapeWriter, a non-traditional keyboard app that input text via gestures using technology developed at IBM and Linköping University, similar to Swype (both of which have since been acquired by Nuance, which has already announced support for Swype as a Custom Keyboard Extension for iOS 8).



While the original ShapeWriter could record text, the user had to copy and paste what they'd entered into the app they wanted to use, making the technology far less useful than custom keyboards integrated right into apps (like the custom numeric keyboard presented in Apple's Numbers, below) or the system itself (enabling input into any installed app).

 


Apple Numbers keypad





Android didn't even debut until nearly a year after ShapeWriter, in part because Google's original concept for Android was a Java Mobile button phone, just like everyone else had been selling.



Android eventually showed up without a working virtual keyboard because Google focused on user input via physical mini keyboards and an LED lit trackball, failing to grasp the value of reconfigurable keyboards that Steve Jobs had touted as a core design concept for the original iPhone in stark contrast to the rest of the industry (below).

 


button phones





In 2009, Google threw open the door to widgets and third party keyboards in Android 1.5 Cupcake, nearly a year before the platform began catching on in the market. That resulted in virtually all Android users being familiar with the concept of both ideas, despite Android having shown up two years late to the iPhone party in terms of virtual keyboards.

 

Why Apple didn't focus on widgets and third party keyboards





Given that Apple had such an early lead, why has the company resisted opening up a third party market for system-integrated custom keyboards and Home screen widgets over the past five years? In a nutshell: performance, privacy and security.



Apple's focus on performance, privacy and security in iOS have trumped Android's widgets and custom keyboard features in the market for premium phones, keeping Apple sustainable profitable as other hardware makers using Android have gone out of business or regularly lost money (including Google's own Motorola, which regularly lost hundreds of millions of dollars).Even if Tim Cook has a time machine, he has no need to travel back to 2009 to urge iOS engineers to focus on widgets and third party keyboards



Consider that Android's best performer, Samsung, has seen its stock appreciate over the last five years by 119.3 percent while Google's stock is up 175.24 percent over the same period.



Over the same five years, Apple stock is up over 362 percent, despite the media's delusional panic throughout 2013. Even if Tim Cook has a time machine, he has no need to travel back to 2009 to urge iOS engineers to focus on widgets and third party keyboards.

 







That's not to say that there's no value in widgets or custom keyboards. Android's promotion of both has highlighted a variety of interesting abilities. And of course, Apple's iOS has also incorporated system-supplied widgets (like Stocks and Weather) and app-specific custom keyboards (again, as in Apple's own Numbers). What Apple hasn't done is fling iOS wide open to unrestricted hobbyist experimentation without considering the consequences.



Google's decision to do just that with Android has manifested the problems associated with rushing poorly conceived, half baked solutions to market. Widgets on Android are commonly associated with battery drain and can help contribute to the noticeable performance lag that still affects the system.

 







Additionally, Google's implementation of both widgets and third party keyboards expose significant security vulnerabilities and privacy issues that many end users wouldn't reasonably assume possible. It's virtually impossible for Google to police whether a third party keyboard spies on users. And it is well known that many actually do, recording users' key presses and uploading the data via the network because there's no functional security boundaries in place to stop such malicious activity from occurring.



Security on Android is largely based upon naive trust. Even apparently legitimate custom keyboard developers have been found to send users' keystrokes back to their servers for processing in clear text making everything they type open to anyone listening.



As an experienced platform vendor that has dealt with malicious security attacks decades before Google was even incorporated, Apple exercises a lot more concern about leaving its platform open to exploit. It also doesn't delegate its basic security design to end users, most of whom have no expertise in navigating the complex issues involved.



In the design of Android, Google has repeatedly bet that nothing bad will ever happen, and has regularly lost that bet at the expense of its users. But the reputation of Android has also become tarnished, particularly affecting valuable clients in government and in the corporate enterprise, where Android remains a minority overall and offers Apple's iPad virtually no competition in tablets at all.

 


iOS enterprise



 

Widgets moving from OS X Dashboard to Notification Center





In both iOS 8 and OS X Yosemite, Apple will present widgets within Notification Center, owing to the relationship between push notifications and widgets' primary role in displaying regularly updated information. For this reason, Apple commonly refers to the new widgets as "Today Extensions."



On OS X, Today Extensions will effectively replace the Dashboard widgets introduced nearly a decade ago in OS X Tiger (below). Dashboard widgets were conceived as desk accessories that could be quickly invoked and dismissed, and were implemented in HTML, CSS and JavaScript to allow for a similar level of security sandboxing as standard web pages. Web standards have been designed not to implicitly trust foreign hosts.

 


OS X Tiger Dashboard Widgets





However, rather than being, effectively, mini web pages like Dashboard widgets, Today Extensions are native code that—like other App Extensions—use a new security model based on Apple's XPC and modern iOS-style Cocoa sandboxing. They are launched by the system and dynamically managed; if they use too much memory on iOS, the system can terminate them to maintain optimum performance.



Building the infrastructure to support such as secure, native implementation has taken years of engineering behind the scenes. XPC, which Apple describes as an "interprocess communication technology that complements App Sandbox by enabling privilege separation," was first introduced in OS X Lion in 2011. Privilege separation is key to allowing App Extensions to perform limited tasks without opening up dangerous new vulnerabilities.



In addition to native performance and a mature security infrastructure, App Extensions also need a viable market supporting them. Dashboard widgets have long languished on OS X after their initial novelty wore off, in part because of the delay involved with launching the web rendering process that animates them when users invoke Dashboard, and in part because free Dashboard widgets lacked a functional business model similar to App Store apps.



Today Extensions (as with all forms of App Extensions) are packaged with new or existing apps, making it possible for developers to market the new widgets as a valuable feature of their paid (or ad supported) apps.

 

Today Extensions on iOS 8 & OS X Yosemite





Today Extensions will work slightly differently on iOS and OS X; on mobile devices, the widgets appear as touchable presentations that lack text input or editing features (meaning that a stocks widget, for example, would need a companion app to edit the list of stocks it presents). On OS X, widgets can be edited in place and can support text input.



These differences are largely due to the fact that on iOS, Notification Center is a temporary pull down designed to present information at a glance. Add a keyboard and editing controls, and the value of presenting widgets would be crowded out by all of the editing UI. Mobile devices also have less processing power and memory available to devote to widgets than a Mac would.Apple's vision for Today Extensions is clearly aimed at presenting quick access to scores, stocks and similar information in the context of other notifications



On iOS, any sort of widget that demands more UI and resources than Notification Center can reasonably accommodate would make more sense to implement as a standalone app—just as Apple implemented its own Stocks and Weather "widget apps" seven years ago on the original iPhone.



In contrast to Android, Apple's vision for Today Extensions is clearly aimed at presenting quick access to scores, stocks and similar information in the context of other notifications, rather than simply padding the Home screen with a busy box of fluff to make up for a lack of significant, native apps.

 

Apple's Notification Center & Android widgets





Like widgets themselves, Notification Center is another feature Android users like to complain that Apple "stole" from an open source project built upon, ironically, the foundation of "copy left" ideology where there is no such thing as stealing.



However—just as with the overall concept of both widgets and a multitouch mobile device designed to launch discrete apps from a home screen of icons—Apple publicly outlined its efforts to develop a central notification system for iOS before Android was even released.



In early 2008 at the release of the App Store and "iPhone OS 2.0," Apple's then head of iOS development Scott Forstall announced the company would be setting up a centralized Push Notification Service as a mechanism for allowing apps to respond to updates from outside services without needing to remain active in the background, constantly polling for new data and eating up battery power, CPU and memory.

 


Windows Mobile Task Manager



Apple's overview of its push notification service.





At the time, Samsung was still promoting Windows Mobile 6, which (like Android today) required users to manually manage background processes and the memory and CPU resources their apps were consuming, an implementation Apple pointed to as an example of a poor design it wanted to dramatically improve upon.

 


Windows Mobile Task Manager



The Task Manager application in Windows Mobile 6.





However, Apple noted later that year that it had greatly underestimated the overwhelming demand for both apps and push notifications, sending the company back to the drawing board and delaying the rollout of its Push Notifications Service until iOS 3.0 in early 2009, following a stress-testing beta program involving the Associated Press and other app developers.



In late 2009, Google, a major iOS developer, filed a patent for "notification of mobile device events," describing a feature it would later add to Android. Android enthusiasts now claim Apple simply copied its Notification Center from Android rather than having laid all the groundwork for touchscreen smartphones, a functional app store and a secure, battery-efficient notifications system.



In 2010, Apple brought its push notifications to the Mac as an API, initially to support FaceTime notifications and then more broadly as a public API in 2011's OS X Lion.

 


Notification Center





Today's basic design of Notification Center (above) appeared on the Mac as a user-facing feature in 2012's OS X Mountain Lion, after first making an appearance on Apple's mobile devices in iOS 5 the previous year.

 

Google patents the type of patent that Google doesn't respect today





Rather than Apple's newest implementation of widgets being "slavishly copied" from Android, the reality is that Google was fully aware of Apple's public work on notifications and—similar to Samsungsought to patent a basic notification listing concept (below) it witnessed others developing first, including prior art developed at Palm for webOS by former Apple engineers.

 







Among those engineers is Rich Dellinger, who worked at Apple from 1999 to 2006 before leaving for Palm, where he developed the "non-intrusive banner notification system used in webOS" (below) that debuted at the beginning of 2009.

 


webOS, Android, iOS 5 notifications





Dellinger returned to Apple after Palm was acquired by HP in 2010. Apple also hired Peter Hajas, who had developed MobileNotifier, an app for jailbroken iOS 4 devices that presented a pull down list of notifications. Apple subsequently released its official Notification Center in iOS 5 (above).



In parallel, Google hired Palm's webOS designer Matias Duarte, who is credited with developing the UI for Android 3.0 Honeycomb, as well as the company's latest web-inspired 'Material Design' appearance for both Android L and future versions of Chrome OS. That work draws clear inspiration from Apple's richly animated UI for iPhone released seven years ago, albeit with a unique color palette.

 

Custom Keyboards as a system plugin





More important than the identity of the first implementation rushed to market is the superior implementation currently available. That's particularly evident among the second type of App Extension that Android users are claiming Apple "stole" from Google: third party, system wide Custom Keyboards.



After belatedly recognizing the value of onscreen keyboards, Google opened up third party access to a core Android system resource back in 2009 to allow anyone to offer custom software for text input. This has been particularly valuable to Android users because Google's default system keyboard was widely considered to not be very good. Google's first attempt at a virtual keyboard was delivered alongside third party options.



As one user noted in a question posed to Android Central years afterward, "my biggest gripe about Android as an iOS user, was that I thought all of the keyboards but the Jelly Bean one were garbage. I found text prediction to be sorely lagging behind iOS, and having to pause to select your word I thought was a bad idea. I'm a fairly rapid typer, and on the iPhone made relatively no mistakes, and never had to backspace at all."



Apple's default keyboards—including support for Chinese finger stroke input—in addition to iOS input features including spell correction and auto correction, have long held a major advantage over the basic keyboard included with Android. So much so that Samsung was found to have infringed Apple's 8,074,172 patent on keyboard auto correction in an effort to make its devices more competitive with iPhones.



At the same time, there are third party custom keyboards that many Android users find compelling, and those input systems were previously impossible to port to iOS because of Apple's abundance of caution to protect users' privacy and security.

 

Apple's strict rules for new Custom Keyboards





With iOS 8's new Custom Keyboard Extensions, developers can implement alternative systems, with a few restrictions. First of all, Custom Keyboards can't be used to type in secure text field objects, such as the users' passcode or other password fields. When a user attempts to enter secure text using a Custom Keyboard (like the new Swype, below), iOS 8 temporarily reverts to the system keyboard, then returns the user back to their preferred keyboard afterward.

 


Swype iOS 8





Custom Keyboards are also prevented from entering "phone pad" input, such as the phone number field in Contacts. Apple also notes that Custom Keyboards "cannot select text or control cursor position" and "cannot offer inline autocorrection controls near the insertion point" due to the way they are implemented."Your first consideration when creating a custom keyboard must be how you will establish and maintain user trust. This trust hinges on your understanding of privacy best practices and knowing how to implement them." - Apple



Apple also outlines that "by default, a keyboard has no network access and cannot share a container with its containing app."



The company's documentation devotes an entire section to "Designing for User Trust," noting to developers, "your first consideration when creating a custom keyboard must be how you will establish and maintain user trust. This trust hinges on your understanding of privacy best practices and knowing how to implement them."



The company spells out three principles of design to earn users trust. Under "Safety of keystroke data," it states "users want their keystrokes to go to the document or text field they're typing into, and not to be archived on a server or used for purposes that are not obvious to them."



Under "Appropriate and minimized use of other user data" it adds,"If your keyboard employs other user data, such as from Location Services or the Address Book database, the burden is on you to explain and demonstrate the benefit to your users."



Finally, under "Accuracy" it notes, "accuracy in converting input events to text is not a privacy issue per se but it impacts trust: With every word typed, users see the accuracy of your code. To design for trust, first consider whether to enable network access. Although network access makes many things possible for a custom keyboard, it also increases your responsibilities."



To turn on network access, a Custom Keyboard must request permission from the user. There are a variety of reasons why a user might opt to allow this, including features such as saving a custom autocorrect dictionary; providing enhanced touch-event processing, input prediction, and speech recognition for dictation; providing quick access to "names, places, and phone numbers relevant to the user" from the user's Contacts or from network supplied data; or autocorrection of nearby place names from Location Services.



Apple outlines specific requirements for developers to implement in their Custom Keyboards when network access is granted by the user, including the instruction, "do not store received keystroke or voice data beyond the time needed to provide text back to the user or to provide features that you explain to the user."



Users who aren't interested in Custom Keyboards will still get the benefit of iOS 8's intelligent QuickType keyboard, which offers predictive text customized to both the app users are typing in and the person they are addressing, in addition to isolating common answers from the context of the conversation (below).

 


iOS 8 QuickType



 

Apple's considered design for App Extensions





As with Photo Editing Extensions, Custom Keyboards and Today Extensions provide third party developers with new ways to extend and add value to users via Apple's platform, which strictly regulates how App Extensions can work.



Apple has also designed App Extensions to benefit developers by highlighting the value of their work. As the company notes, "when users enter your extension, your custom UI can help to show them that they're shifting into a new context. Because users can distinguish your extension from the current app, they can appreciate the unique functionality that you provide."



At the same time, Apple has also given consideration to how users manage their own environment. "Users' awareness of extensions as separate entities also means that they can identify and remove extensions that misbehave or don't perform well," Apple states. The company has also outlined how users will be able to easily specify which Extensions they want to activate or remove.



The inclusion of both Today Extensions and Custom Keyboard functionality into the design of App Extensions indicates that Apple is working to erase any perceived advantages held by alternative operating systems. However, the design of iOS and OS X aren't simply reacting to follow market trends. Apple is also establishing its own unique functionality with App Extensions in ways that are not shared with the rest of the industry, as the following segment will outline.

«134

Comments

  • Reply 1 of 66
    froodfrood Posts: 771member

    Great article Daniel, and hooray Apple!!!  Widgets and keyboards!!!  I think Apple fans are going to be pleasantly re-blown away with the iPhone 6.

  • Reply 1 of 66
    philboogiephilboogie Posts: 7,675member
    Are these specific requirements for developers by Apple the same on Android? After typing that out I guess it's a rethorical question as I doubt they would put in so much time and effort in getting these things right. Having read about so much memory leaks, battery drains, the lot, I guess the SDK and its rules aren't quite the same on Android as they are for iOS. Oh well, for a mere $99 Google can copy these requirements from Apple I guess.
  • Reply 3 of 66
    asciiascii Posts: 5,936member

    After past experience with browser plugins causing security problems, should we or should we not extend plugins to other bundled apps? Something as personal as the Photos app, or something as critical as the keyboard?

     

    There is no way I would trust something as critical as my keyboard to a third party, even one on the App Store. Do you know how much it costs to sell apps on there? Only $100/year. And if you're giving them away free you don't have to provide official government tax documentation.

     

    If you think Apple will be able to safely lock-down these plugins, I ask you to please read Apple's security advisories page. This lists six ways, since Mavericks came out alone, that apps can potentially escape the app sandbox. Even if the security model (as described in this article) is perfect, you still have to consider the implementation.

     

    And where do plugin frameworks ultimately lead anyway? I mean, do Apple think third party devs will have hundreds of new ideas for things to do with a keyboard or photo that Apple can't think of themselves? No, it never works out that way. There will be *one or two* good plugins (such as Flash and Java in the browser) that come to dominate in each plugin-space. And is it really worth developing and maintaining an entire plugin architecture to harvest one or two good ideas? And what if those plugins become so popular that you can't realisticially update the app in ways that might break them, isn't that potentially problematic?

     

    What if there was a way to get the benefit of those 1 or 2 awesome ideas without all the bother of a plugin framework? Well, there is. All iOS apps have to go through the App Store. This gives Apple a single place to watch for innovation. If a 3rd party app has a great new photo processing idea or cool custom keyboard (there's nothing to stop you implementing your own in a UIView) Apple can simply buy the company and port the feature to Photos or iOS with (most likely) less developer time than it takes to develop and maintain a plugin framework. These days a lot of tech companies are founded with the simple goal of being bought out, as opposed to making massive sales of their own.

     

    Apple's answer to Android's plugins should not be a plugin framework of their own, it should be The App Store + their Big Purse. 



    List of Sandbox vulnerabilities in Mavericks: 

    ----------------

    10.9.0 http://support.apple.com/kb/HT6011

    App Sandbox

    Impact: The App Sandbox may be bypassed

    Description: The LaunchServices interface for launching an application allowed sandboxed apps to specify the list of arguments passed to the new process. A compromised sandboxed application could abuse this to bypass the sandbox. This issue was addressed by disallowing sandboxed applications from specifying arguments.

    CVE-2013-5179 : Friedrich Graeter of The Soulmen GbR

     

    10.9.1: http://support.apple.com/kb/HT6084

    App Sandbox

    Available for: OS X Mountain Lion v10.8.5

    Impact: The App Sandbox may be bypassed

    Description: The LaunchServices interface for launching an application allowed sandboxed apps to specify the list of arguments passed to the new process. A compromised sandboxed application could abuse this to bypass the sandbox. This issue was addressed by preventing sandboxed applications from specifying arguments. This issue does not affect systems running OS X Mavericks 10.9 or later.

    CVE-2013-5179 : Friedrich Graeter of The Soulmen GbR

    ATS

    Available for: OS X Mavericks 10.9 and 10.9.1

    Impact: The App Sandbox may be bypassed

    Description: A memory corruption issue existed in the handling of Mach messages passed to ATS. This issue was addressed through improved bounds checking.

    CVE-2014-1262 : Meder Kydyraliev of the Google Security Team

    ATS

    Available for: OS X Mavericks 10.9 and 10.9.1

    Impact: The App Sandbox may be bypassed

    Description: An arbitrary free issue existed in the handling of Mach messages passed to ATS. This issue was addressed through additional validation of Mach messages.

    CVE-2014-1255 : Meder Kydyraliev of the Google Security Team

    ATS

    Available for: OS X Lion v10.7.5, OS X Lion Server v10.7.5, OS X Mountain Lion v10.8.5, OS X Mavericks 10.9 and 10.9.1

    Impact: The App Sandbox may be bypassed

    Description: A buffer overflow issue existed in the handling of Mach messages passed to ATS. This issue was addressed by additional bounds checking.

    CVE-2014-1256 : Meder Kydyraliev of the Google Security Team

     

    10.9.4: http://support.apple.com/kb/HT6296

    Dock

    Available for: OS X Lion v10.7.5, OS X Lion Server v10.7.5, OS X Mountain Lion v10.8.5, OS X Mavericks 10.9 to 10.9.3

    Impact: A sandboxed application may be able to circumvent sandbox restrictions

    Description: An unvalidated array index issue existed in the Dock’s handling of messages from applications. A maliciously crafted message could cause an invalid function pointer to be dereferenced, which could lead to an unexpected application termination or arbitrary code execution.

    CVE-2014-1371 : an anonymous researcher working with HP's Zero Day Initiative

    ----------------

     

    TL;DR "Plugins suck"

  • Reply 4 of 66
    I'd rather Apple be "late" to impliment a feature and get it right than do some crap like Samsung, Windows etc and rush some sh*t out there just to claim "First"
  • Reply 5 of 66
    Dan_DilgerDan_Dilger Posts: 1,583member
    Quote:

    Originally Posted by ascii View Post

     

    After past experience with browser plugins causing security problems, should we or should we not extend plugins to other bundled apps? Something as personal as the Photos app, or something as critical as the keyboard?


     

    Good question! However, Apple's implementation of App Extensions is very different than the Plugin APIs of Netscape, Safari, Aperture, and other apps that expose a way for insecure plugins to extend their functionality. Will detail more in a future segment. 

     

    Also, the vulnerabilities you cite are fixed issues. That's like saying that a car is probably unsafe to drive because it suffered a flat tire that was subsequently replaced. Having third parties find your vulnerabilities and then fixing them is a sign that the system is safer, nor more flawed.

  • Reply 6 of 66
    xpadxpad Posts: 46member
    Quote:

    Originally Posted by ascii View Post

     

    After past experience with browser plugins causing security problems, should we or should we not extend plugins to other bundled apps? Something as personal as the Photos app, or something as critical as the keyboard?

     

    ...

     

    TL;DR "Plugins suck"


     

    Don't you realize how irrational that is? Nothing in this universe is 100% secure, including extensions. But if you want to experience life, you have to take risks. After all, what good is an app if you don't make good use of it?

     

    Extensions allow people to make good use of their apps. Sure, there's a risk, but Apple has accounted for that very well. Not perfectly so (nothing is!), but they've done quite well. What more can you ask?

     

    You remind me of people who keep their furniture covered in plastic, afraid of damaging and normal wear. Well, guess what? You will have a pristine sofa that you've never actually used!

  • Reply 7 of 66
    derekmorrderekmorr Posts: 237member

    Ah, I see it's time for the weekly Android-bashing from Danny boy. How predictable.

     

    Additionally, Google's implementation of both widgets and third party keyboards expose significant security vulnerabilities and privacy issues that many end users wouldn't reasonably assume possible. It's virtually impossible for Google to police whether a third party keyboard spies on users. And it is well known that many actually do, recording users' key presses and uploading the data via the network because there's no functional security boundaries in place to stop such malicious activity from occurring.



    Security on Android is largely based upon naive trust. Even apparently legitimate custom keyboard developers have been found to send users' keystrokes back to their servers for processing in clear text making everything they type open to anyone listening.

     

    I'm getting dizzy from the spin.

     

    A few years ago, Dianne Hackborn, a senior Android engineer at Google, wrote a detailed post on Google+ explaining how Android works - . The piece is mainly about graphics, but it goes into some detail about keyboards. In short, keyboards run in their own sandbox with a seperate window on the screen. 

     

    Many users, myself included, want our soft keyboards to learn our writing styles, and to sync that data across devices. It's a feature. It's not spyware. On SwiftKey, one of the most popular third-party keyboards, cloud-sync is opt-in. See http://swiftkey.com/en/more-about-cloud/ for details, and see http://swiftkey.com/en/data-security/ for info on how they secure data.

     

    The only evidence you cite is a three-year-old story about an app sending data in the clear. Lots of apps, on Android and iOS, sent data in the clear then. Many still do. Even Apple used cleartext for the App Store until last year. This is hardly evidence that third-party keyboards are a spyware cesspool.

     

    By the way, when is AppleInsider going to support SSL for logins? The site currently sends data in the clear.

     

     

    At the time, Samsung was still promoting Windows Mobile 6, which (like Android today) required users to manually manage background processes and the memory and CPU resources their apps were consuming....

    What are you talking about DED? Android does not require users to manually manage background processes, memory or CPU resources. Years ago, there were some users who thought task killers could extend their battery life, but that's been shown to be false for quite some time. And as far as I know, Android doesn't even provide a UI for users to manage memory or CPU resources. More FUD.

     

    With iOS 8's new Custom Keyboard Extensions, developers can implement alternative systems, with a few restrictions. First of all, Custom Keyboards can't be used to type in secure text field objects, such as the users' passcode or other password fields. When a user attempts to enter secure text using a Custom Keyboard (like the new Swype, below), iOS 8 temporarily reverts to the system keyboard, then returns the user back to their preferred keyboard afterward.

    Custom Keyboards are also prevented from entering "phone pad" input, such as the phone number field in Contacts. Apple also notes that Custom Keyboards "cannot select text or control cursor position" and "cannot offer inline autocorrection controls near the insertion point" due to the way they are implemented."


     

    I don't know about you, but this constant switching from a custom keyboard back to stock one sure sounds like a lousy user experience to me. I have to think that if Google had implemented Android keyboards this way, that folks on here would waste no time bemoaning the terrible UX and that such behavior indicates Google didn't take the time to properly secure third-party keyboards....

     

    Apple also outlines that "by default, a keyboard has no network access and cannot share a container with its containing app."

     

    You mean just like Android apps?


  • Reply 8 of 66
    solipsismxsolipsismx Posts: 19,566member
    derekmorr wrote: »
    I don't know about you, but this constant switching from a custom keyboard back to stock one sure sounds like a lousy user experience to me. I have to think that if Google had implemented Android keyboards this way, that folks on here would waste no time bemoaning the terrible UX and that such behavior indicates Google didn't take the time to properly secure third-party keyboards....

    1) Why is there constant switching? How often are you having to access a secure password field?

    2) If Android actually put security first with the keyboard it mocked. It's a lack of security that gets talked about most, and that's OS agnostic.
  • Reply 9 of 66
    Dan_DilgerDan_Dilger Posts: 1,583member
    Quote:
    Originally Posted by derekmorr View Post

     

    A few years ago, Dianne Hackborn, a senior Android engineer at Google, wrote a detailed post on Google+ explaining how Android works - . The piece is mainly about graphics, but it goes into some detail about keyboards. In short, keyboards run in their own sandbox with a seperate window on the screen. 

     

    Having a "sandbox" doesn't mean there is any security involved. As noted in the quote you cited, Android keyboards have sent keystrokes over the network in the clear. That's bad.

     

    Also, a 3rd party keyboard innately has access to anything users type, regardless of being "in a sandbox," so if it has network access, it minimally can do stupid things with it (like send it in over the Internet as clear text) or do malicious things with it (like parse for passwords and private data) 

     

    Many users, myself included, want our soft keyboards to learn our writing styles, and to sync that data across devices. It's a feature. It's not spyware. On SwiftKey, one of the most popular third-party keyboards, cloud-sync is opt-in.

     

    That is clearly presented in the article.

     

    The only evidence you cite is a three-year-old story about an app sending data in the clear. Lots of apps, on Android and iOS, sent data in the clear then. Many still do. Even Apple used cleartext for the App Store until last year. This is hardly evidence that third-party keyboards are a spyware cesspool.

     

    Apple "used cleartext for the App Store" meaning what? That it sent user credentials unencrypted? That it intercepted everything that users typed and sent it to its servers unencrypted? What you are typing makes no sense. 

     

    By the way, when is AppleInsider going to support SSL for logins? The site currently sends data in the clear.

     

    If somebody can intercept your AI Forums password, it's not exactly the same thing as intercepting your banking passwords, your Contacts data, your location, etc.

     

    At the time, Samsung was still promoting Windows Mobile 6, which (like Android today) required users to manually manage background processes and the memory and CPU resources their apps were consuming....



    What are you talking about DED? Android does not require users to manually manage background processes, memory or CPU resources. Years ago, there were some users who thought task killers could extend their battery life, but that's been shown to be false for quite some time. And as far as I know, Android doesn't even provide a UI for users to manage memory or CPU resources. More FUD.

     

    Over the past five years of Android custom keyboards and widgets, the top app on the platform has been task killers, and memory and battery use are the top problems Android users have. You can claim that's not an issue, just like Android fans claim keyboards are not a security threat, but that's ignorant.

     

    I don't know about you, but this constant switching from a custom keyboard back to stock one sure sounds like a lousy user experience to me. I have to think that if Google had implemented Android keyboards this way, that folks on here would waste no time bemoaning the terrible UX and that such behavior indicates Google didn't take the time to properly secure third-party keyboards....

     

    Saying that switching to a secure keyboard for entering secure data is a "lousy user experience" undermines your credibility.

     

    Also, as the article points out, there really isn't any way for Google to "properly secure third-party keyboards," because Google doesn't curate its own apps, let alone the side loaded and alternative app stores that are both the hallmark of Android openness and what the majority of global Android users actually use. 

     

    Apple also outlines that "by default, a keyboard has no network access and cannot share a container with its containing app."

     

    You mean just like Android apps?

     

    What percentage of Android keyboards work without network access? What's the business model? SwiftKey is free and needs full internet access. The business model is data mining. 



    http://www.xda-developers.com/android/swiftkey-and-google-keyboard-ever-heard-of-user-privacy/



  • Reply 10 of 66
    asciiascii Posts: 5,936member
    Quote:

    Originally Posted by Corrections View Post

     

    Also, the vulnerabilities you cite are fixed issues. That's like saying that a car is probably unsafe to drive because it suffered a flat tire that was subsequently replaced. Having third parties find your vulnerabilities and then fixing them is a sign that the system is safer, nor more flawed.


    A list of fixed vulnerabilities is indeed a sign that a system is getting safer. But it's also telling that 3 years after the OS X sandbox came out (Lion was RTM in July 2011), they are still fixing issues (10.9.4 is only a few days old). The Plugins framework constitutes a whole new attack surface that will have to go through it's own period of breaking in. And it's an attack surface that includes things such as photos, and the keyboard itself.

     

    Where I'm coming from is my belief is that the fundamental cause of security issues (talking about any OS here) is complexity. The system gets so complex that even the designers themselves can not forsee all the ways someone might potentially attack it. So if there's any way to achieve functionality goals without introducing new layers of complexity, that is the way to go. I offered one suggestion of simply buying out new innovative apps and integrating their functionality in to Apple apps, but I'm sure there are other solutions. Technical challenges from other companies do not always require a technical response, sometimes a business response will do.

  • Reply 11 of 66
    asciiascii Posts: 5,936member
    Quote:
    Originally Posted by xPad View Post

     

     

    Don't you realize how irrational that is? Nothing in this universe is 100% secure, including extensions. But if you want to experience life, you have to take risks. After all, what good is an app if you don't make good use of it?

     

    Extensions allow people to make good use of their apps. Sure, there's a risk, but Apple has accounted for that very well. Not perfectly so (nothing is!), but they've done quite well. What more can you ask?

     

    You remind me of people who keep their furniture covered in plastic, afraid of damaging and normal wear. Well, guess what? You will have a pristine sofa that you've never actually used!


    Well, I disagree with your premise that plugin frameworks are required for people to make good use of their apps. What is required to make good use of an app is that it have good functionality. Yes, that can be implemented by plugins but it can also be implemented by Apple themselves. And for reasons already stated, I think we would be better off if Apple simply kept a close eye out for innovations in 3rd party photo apps/keyboards and wasted no time in creating their own implementation. We would get all the benefits of a plugin framework with none of the security issues, plus the features would probably have that added Apple magic touch.

     

    As to your broader point, I agree that there is always a tradeoff between security and functionality/ease of use. I just think plugins are bad tradeoff. To generalize from that one example to thinking I would take the safest path in all such tradeoffs (plastic on the sofa) is a premature generalization on your part.

  • Reply 12 of 66
    derekmorrderekmorr Posts: 237member

    Ugh, dude, learn to quote properly. Your post doesn't quote properly, so I'll just respond inline:

     

     

    ---

    DED: "Having a "sandbox" doesn't mean there is any security involved."

     

    Uh, that's exactly what a sandbox means.

     

    DED:  if it has network access, it minimally can do stupid things with it (like send it in over the Internet as clear text) or do malicious things with it (like parse for passwords and private data) 

     

    Evidence, please. Transmitting keyboard data off-device is not evidence of spying. There are plenty of legitimate reasons, and safe ways, to do so. The only "evidence" you found was one app that three years ago didn't use SSL. That's hardly an indictment of the entire platform.

     

    Further, I don't see any technical restriction on an iOS keyboard transmitting data in cleartext or scanning for sensitive info. You seem to want to have it both ways.

     

    --

     

    DED: Apple "used cleartext for the App Store" meaning what? That it sent user credentials unencrypted? That it intercepted everything that users typed and sent it to its servers unencrypted?

     

    Read the article. The App Store downloaded content in cleartext, allowing HTML injection. This allowed attacks to steal passwords and swap apps. See http://www.elie.im/blog/web/apple-finally-turns-https-on-for-the-app-store-fixing-a-lot-of-vulnerabilities/ for more.

     

    --

     

    DED: "If somebody can intercept your AI Forums password, it's not exactly the same thing as intercepting your banking passwords, your Contacts data, your location, etc."

     

    Given how many people reuse passwords, it could be a serious problem. And, honestly, in 2014 there is zero excuse not to submit a login form over HTTPS.

     

    --

     

    DED: "Over the past five years of Android custom keyboards and widgets, the top app on the platform has been task killers, and memory and battery use are the top problems Android users have. You can claim that's not an issue, just like Android fans claim keyboards are not a security threat, but that's ignorant."

     

    Again, evidence please. The current Top Free and Top Selling app lists are not filled with task killers.  Also, you seem to just keep repeating that third party keyboards are a security threat. Can you provide any credible evidence that they are? For example, a reasonable estimate of the number of people who were negatively affected by installing one? Any actual evidence of harm?

     

    --

    DED: "Saying that switching to a secure keyboard for entering secure data is a "lousy user experience" undermines your credibility."

     

    Of course, that's not what I said. I said that having the OS switch between keyboards would be a bad user experience.

     

    -- 

    DED: because Google doesn't curate its own apps, let alone the side loaded and alternative app stores that are both the hallmark of Android openness and what the majority of global Android users actually use. 

     

    Oh not this again. The Bouncer system analyzes all apps in the Play Store. Further, the Play Store Developer Distribution Agreement requires all apps to safeguard the user's privacy (section 4.3).

     

    Also, what is your evidence that the majority of global Android users use third-party stores? Aside from China, where Google Play isn't usually available, I haven't see good data on popularity of third-party stores. But even if a user installs an app from a third-party store, if the device has Google Play Services installed, the app will be scanned.

     

    Can we please put this "Android is insecure" meme to rest? I know Apple fanboys love it, but it's just nonsense. Unless you have actual evidence of actual people actually being harmed by it, then it's just FUD.

     

    --

    DED: "What percentage of Android keyboards work without network access? What's the business model? SwiftKey is free and needs full internet access. The business model is data mining."

     

    Again, more spurious claims. Swiftkey requires network access to download updated language models. The device sync feature is opt-in. They also sell themes via in-app purchases.  

  • Reply 13 of 66
    Dan_DilgerDan_Dilger Posts: 1,583member
    Quote:

    Originally Posted by ascii View Post

     

    Well, I disagree with your premise that plugin frameworks are required for people to make good use of their apps. 


     

    Again, App Extensions are not plugins.

     

    Also, acquiring third party apps and bundling them would also involve security risks. 

  • Reply 14 of 66
    Dan_DilgerDan_Dilger Posts: 1,583member
    Quote:

    Originally Posted by derekmorr View Post

    "Having a "sandbox" doesn't mean there is any security involved."

     

    Uh, that's exactly what a sandbox means.

     

    No, it does not. If you type into an app "in a sandbox" (or into an app component in a sandbox, like a custom keyboard), and that bit of software has internet access, there is no automatic umbrella of security that prevents your key presses from being sent somewhere. 

     

    Everything else you wrote is similarly just argumentative and incorrect and a waste of time to argue, apart from this particularly flawed statement:

     

    Can we please put this "Android is insecure" meme to rest? I know Apple fanboys love it, but it's just nonsense. Unless you have actual evidence of actual people actually being harmed by it, then it's just FUD.

     

    The fact that the US government will not allow the purchase of Android devices apart from a very short list of Samsung models using Knox should be plenty of evidence. Also, corporations are clearly choosing not to use Android tablets nor support the majority of Android phones, resulting in usage share that's half that of the general population. These same companies overwhelmingly adopted Windows. That should tell you something profound about the security problems in Android and the difficulty of diapering those wide open holes.

     

    But I have no interest in a Usenet-style argument with someone who desperately wants to believe that "Android is secure" and demands "actual evidence" instead of simply doing a google search on the subject. I'm also not going to present you evidence of the earth being round or that industry is contributing to climate change.


  • Reply 15 of 66
    derekmorrderekmorr Posts: 237member

    Again, could you please quote properly?

     

    Quote:
    Originally Posted by Corrections View Post

    there is no automatic umbrella of security that prevents your key presses from being sent somewhere. 

     

    Way to move the goal posts. No device sandbox protects against sending cleartext data. But that's not the same as "Having a "sandbox" doesn't mean there is any security involved." The Android and iOS sandboxes protect against on-device attacks. I haven't seen any evidence that the iOs sandbox will prevent third-party keyboards on iOS from sending data in cleartext. Do you know of any?

     

    Quote:
    Originally Posted by Corrections View Post

    Everything else you wrote is similarly just argumentative and incorrect and a waste of time to argue

     

    You mean because I linked to primary sources that directly refute your claims?

     

     

    Quote:

    Originally Posted by Corrections View Post

    But I have no interest in a Usenet-style argument with someone who desperately wants to believe that "Android is secure" and demands "actual evidence"

     

    So much win in that! That made my night.

  • Reply 16 of 66
    jpthorjpthor Posts: 2member
    Haha love the article DED.
  • Reply 17 of 66
    moreckmoreck Posts: 187member
    Thanks for the fantastic article! This gives me some great insight to use as ammo if one of my Android-loving friends tries to say anything about Apple "copying" Google.
  • Reply 18 of 66
    Nothing much to say except that Android is a cluster%uck of an OS with sub-par development tools.
  • Reply 19 of 66
    tenlytenly Posts: 710member
    Quote:
    Originally Posted by derekmorr View Post

     

    Again, could you please quote properly?

     

     

    Way to move the goal posts. No device sandbox protects against sending cleartext data. But that's not the same as "Having a "sandbox" doesn't mean there is any security involved." The Android and iOS sandboxes protect against on-device attacks. I haven't seen any evidence that the iOs sandbox will prevent third-party keyboards on iOS from sending data in cleartext. Do you know of any?

     

     

    You mean because I linked to primary sources that directly refute your claims?

     

     

     

    So much win in that! That made my night.


     

    Your opinions are clearly delusional.

     

    You don't need "evidence that someone has been harmed" to prove a security hole exists.

     

    If my house has a lock on the front door and your house does not, the front door to my house is obviously more secure than yours.  The fact that your house hasn't been broken into does nothing to prove security.

     

    Android is full of known security holes.  Whether a hacker takes advantage of those holes or not, does not change the fact that they exist and that there is a security problem.

     

    The news is full of reports that large corporations and governments are passing on Android because it is not as secure as iOS and other products.

     

    Convince me and convince everyone reading this comment thread why we should ignore the findings of the professional Security and IT groups within the government and these large corporations.  Why should we believe you - some random person on the internet (with no credentials) - that Android is in fact secure, when everyone we hear from that has credentials and understands what a security vulnerability is - is telling us that it's not?

  • Reply 20 of 66
    ericthehalfbeeericthehalfbee Posts: 4,485member
    Quote:

    Originally Posted by tenly View Post

     

     

    Your opinions are clearly delusional.

     

    You don't need "evidence that someone has been harmed" to prove a security hole exists.

     


     

    Bingo. Sounds an awful lot like the argument made by a few other well-known trolls here at AI. Always demanding "proof" that something happened when they know damn well it's virtually impossible.

     

    A similar analogy would be to look at Windows. I myself have NEVER had an issue with any type of virus/malware on my PCs simply because I take steps to prevent it. However, I'd be a raving lunatic to claim that Windows PCs never get malware based on my experiences.

Sign In or Register to comment.