or Connect
AppleInsider › Forums › Mobile › iPhone › Inside App Extensions: Apple, Inc's new Widgets & Keyboards similar to Android's, but secure
New Posts  All Forums:Forum Nav:

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

post #1 of 66
Thread Starter 

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.

post #2 of 66

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.

post #3 of 66
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.
"Fibonacci: As easy as 1, 1, 2, 3..."
Reply
"Fibonacci: As easy as 1, 1, 2, 3..."
Reply
post #4 of 66

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"

post #5 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"
post #6 of 66
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.

post #7 of 66
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!

post #8 of 66

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?

post #9 of 66
Quote:
Originally Posted by derekmorr View Post

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.

"The real haunted empire?  It's the New York Times." ~SockRolid

"There is no rule that says the best phones must have the largest screen." ~RoundaboutNow

Reply

"The real haunted empire?  It's the New York Times." ~SockRolid

"There is no rule that says the best phones must have the largest screen." ~RoundaboutNow

Reply
post #10 of 66
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/

post #11 of 66
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.

post #12 of 66
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.

post #13 of 66

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.  

post #14 of 66
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. 

post #15 of 66
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.

post #16 of 66

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.

post #17 of 66
Haha love the article DED.
post #18 of 66
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.
post #19 of 66
Nothing much to say except that Android is a cluster%uck of an OS with sub-par development tools.

Author of The Fuel Injection Bible

Reply

Author of The Fuel Injection Bible

Reply
post #20 of 66
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?


Edited by tenly - 7/5/14 at 7:54am
post #21 of 66
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.

Author of The Fuel Injection Bible

Reply

Author of The Fuel Injection Bible

Reply
post #22 of 66
Quote:
Originally Posted by tenly View Post
 

Your opinions are clearly delusional.

Glad to see nothing has changed on AI -- anyone who doesn't tout the party line is "delusional" or "a troll." Really mature bunch of commenters, we have here.

 

Quote:
Originally Posted by tenly View Post
 

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.

I don't think reasoning by analogy is helpful here, but to continue your comparison -- the issue isn't who has a better door. When police are reporting crime statistics, they report on break-ins, burglaries, etc, not on how many people lock their doors. The difference isn't just semantics, it matters.

 

Quote:
Originally Posted by tenly View Post

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?

I doubt I could convince most of you about anything. Too many of the commenters here have absolutist views of things, and their posts are filled with hate and venom. Not to mention endless cherry picking and goalpost moving. It's really sad. The amount of closed-mindedness and groupthink on the AI forums is striking.

 

Google Play does an outstanding job of blocking malware. At this year's RSA conference, Google presented stats on Android malware infection. The whole deck is worth reviewing, but if you're pressed for time, review slides 25-27. The last one compares the alarmist Android malware headlines to actual, observed infection rates (which are far, far below 1%).

 

Unfortunately, the tech press does a lousy job of reporting this. You often see poorly written stories, like this one ,"New Android RAT threatens mobile banking users" about new Android malware in South Korea. The story drones on for a dozen paragraphs about how terrible and awful and scary the malware is until you get to last paragraph where you find this gem: "MWR believes the malware may not pose a widespread threat. Security consultant Henry Hoggard told SC via email: 'It's not likely that this will become a major problem, due to the propagation problems - not on Google Play, which requires third-party app install and social engineering or a separate vulnerability in a highly privileged application.'"

 

On the same note, we often see reports about local exploits, like this one. What these reports often leave out is that SE Android often blocks these problems (the one I linked to is blocked on (at least) the Galaxy S4, S5, and Note 3; LG G3 and GFlex; Nexus 4 and 5; HTC One m8, and Sony Z2).

 

Amazingly, some security consultants, when pressed, admit that the alarmist Android malware headlines are BS. "Derek Halliday, a security product manager at Lookout, says that it's important to look at more than specific instances of malware, and that "it is alarmist to claim that malware has increased by hundreds of thousands of percentages.""

post #23 of 66
Quote:
Originally Posted by derekmorr View Post

^ post

Insightful, thanks.
"Fibonacci: As easy as 1, 1, 2, 3..."
Reply
"Fibonacci: As easy as 1, 1, 2, 3..."
Reply
post #24 of 66

This was a great piece. Yes, it had some obvious spin - but that's OK. I think most readers can cut through that language to focus on the factual and philosophical basis behind it.

 

More than anything else, this article reminds me of how futile the "who copied who" arguments are. Everyone "copies" everyone. It seems useless to look back at the origins of one particular feature. I think what matters more is the implementation of said feature.

 

It's true that Apple is not as open as Google in terms of the OS, but on the other hand, I am personally quite happy with the "curated" experience. Security is (or should be) an increasing concern; but it's not just security per se, it's also the way in which applications can change the general user experience in negative ways. For example, I appreciate that apps on iOS must ask to use my location data, or to access my photos or contacts. That's as it should be.

 

There have been so many dodgy attempts by app developers to get things under the radar (on iOS and elsewhere besides), and there are still numerous examples where things go wrong (i.e. you visit a web page and an ad on the page opens App Store without your approval and directs you to some crappy game). So, I appreciate that when Apple looks at implementing some new feature (like extensions), they do so in a very carefully considered way.

post #25 of 66
Quote:
Originally Posted by Ingsoc View Post
For example, I appreciate that apps on iOS must ask to use my location data, or to access my photos or contacts. That's as it should be.

 

From your post it's not clear if you're aware that Android apps must ask to use your location data, photos, contacts, etc. as well.

post #26 of 66
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.

 

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?

 

Quote:
Originally Posted by EricTheHalfBee View Post
 

 

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.

 

 

This is the exact opposite of the argument I usually see on this site when Apple has a vulnerability.   Major security flaws like the 'wireless' hole are poo-poo'd here because everyone knows 'Apple is secure.'  Since nearly 100% of Apple users were on affected version and almost all used a wireless connection at some point, you could argue that Apple users are less secure because any issues affect their entire base.  Never mind that very few users were *actually* hacked (that we know of), the main thing (by your argument) is that they *could have been* hacked.   Either one has valid arguments- but seeing the same argument either supported or brushed off depending on which platform is affected hints at these sites being overly biased (not that that is surprising).

 

If you're feeling defensive about lifting widgets & keyboards from Android and that doing security a little differently absolves Apple from thieving- I say run with it.  In my view there is no need to feel defensive about it and no thieving occurred in the first place.  Keyboards are a no-brainer.  Widgets are very nice to have and I hope iOS users enjoy them.  I'd think a bigger driver is that with the smaller screens of prior iPhones, there really wasn't an elegant use for widgets- your screen could really only show one thing at a time.  Now that Apple is going with larger screens, widgets make more sense (and are a must imo) so add them and make them great. 

post #27 of 66
Quote:
Originally Posted by Frood View Post
 

 

 

This is the exact opposite of the argument I usually see on this site when Apple has a vulnerability.   Major security flaws like the 'wireless' hole are poo-poo'd here because everyone knows 'Apple is secure.'  Since nearly 100% of Apple users were on affected version and almost all used a wireless connection at some point, you could argue that Apple users are less secure because any issues affect their entire base.  Never mind that very few users were *actually* hacked (that we know of), the main thing (by your argument) is that they *could have been* hacked.   Either one has valid arguments- but seeing the same argument either supported or brushed off depending on which platform is affected hints at these sites being overly biased (not that that is surprising).

 

If you're feeling defensive about lifting widgets & keyboards from Android and that doing security a little differently absolves Apple from thieving- I say run with it.  In my view there is no need to feel defensive about it and no thieving occurred in the first place.  Keyboards are a no-brainer.  Widgets are very nice to have and I hope iOS users enjoy them.  I'd think a bigger driver is that with the smaller screens of prior iPhones, there really wasn't an elegant use for widgets- your screen could really only show one thing at a time.  Now that Apple is going with larger screens, widgets make more sense (and are a must imo) so add them and make them great. 

 

More delusions that a casual reader might actually think are true.  There's no reason to feel defensive about Apple implementing widgets and keyboards in the next release of iOS.  You insinuate that they were stolen/copied/lifted from Android which is actually pretty laughable and this article does a good job of explaining why that's not true.

 

Myself, and I hope other members of this community reply publicly to posts that are filled with lies, misinformation or misleading remarks, not because we are defensive and feeling threatened, but more as a service to the casual reader who might otherwise think the information is accurate and factual.

 

I think it's indisputable that Apple does a MUCH better job of providing security updates to their users and getting those updates installed throughout their entire user base quickly and easily.   How would you respond to this claim?  Would you point out that there are 2 or 3 Android models in which this is possible - or would you word it in a way that misleads readers into thinking that this is something that is quick and easy to do on all Android phones?

 

Getting back to the security debate, I still don't understand how a handful of people can show up here and post comments that directly contradict the industry experts without telling us what their personal credentials are or explaining why they know more than the 'experts' know.  To me, it just sounds like a lot of wishful thinking.  A quick Google search for 'Android vs iOS security' overwhelmingly return results that support the "common knowledge" that security is a secondary concern for Android.  Here are a handful of headlines and quotes from this year:

 

Symantec - April 2014 - http://community.norton.com/t5/Norton-Protection-Blog/Android-vs-iOS-Which-is-More-Secure/ba-p/1122152

"If we’re talking purely about the level of threat that exists on the two platforms, it would seem iPhone and iPad users have the better side of the deal"

 

Apple Insider - Feb 2014 - http://appleinsider.com/articles/14/02/27/apple-touts-secure-design-of-ios-as-google-chief-admits-android-is-best-target-for-malicious-hackers

"Speaking at Mobile World Conference, Google's new Android chief Sundar Pichai admitted that security plays second fiddle to "freedom" in the design and implementation of Google's mobile operation system, exposing Android users to an overwhelming, disproportionate share of malware vulnerabilities."

 

DroidReport.com - Feb 2014 - http://www.droidreport.com/android-vs-ios-security-6137

"With Google Android, manufacturers can modify the carrier releasing the device. This then causes Android devices to become more at risk due to poor or unwanted UI modifications."

 

Cybernet - Cyber Security Division - Oct 2013 - http://cybersecurity.cybernet.com/blog/2-reasons-iphone-secure-android/

"Love it or hate it, not only is iOS more secure than Android today, but its position as the front runner in security will continue to grow for the foreseeable future."

post #28 of 66
Quote:
Originally Posted by DroidFTW View Post
 

 

From your post it's not clear if you're aware that Android apps must ask to use your location data, photos, contacts, etc. as well.


The difference is that iOS forces apps to ask permission when they need it, creating a relationship between what they are asking for and why they need it (As is "I'm accessing your contacts to look for friends, ok?"). And users can say no, and the app will continue working (although might not be able to do all it wants to/can do).

 

Under Android (and correct me if I'm wrong), apps ask for a laundry list of access permissions up front when they are installed, so that users have to accept all or nothing, the entire batch. Many users just click ok to complete the install without stopping to read a bunch of arcanely worded, generically abstract ideas that only make sense to engineers or tech enthusiasts. And if they don't accept them all, it won't install.

 

So no, it's not the same. And that's one reason why Android has a problematic ecosystem full of malware and spyware. 

 

Additionally, even "reputable" Android developers like Facebook and Samsung are taking advantage of the "take it or leave it 100%" structure of Android permissions requests to push unnecessary permissions. And then they take advantage of that to do things users wouldn't tolerate if they knew what was happening (like having all their contacts routinely uploaded for data mining, and spying on all the other apps installed on the device and recording what they are doing). This isn't just obscure Chinese malware doing this. It's top to bottom in the Android ecosystem. 

post #29 of 66
Quote:
Originally Posted by Frood View Post
 

 

 

This is the exact opposite of the argument I usually see on this site when Apple has a vulnerability.   Major security flaws like the 'wireless' hole are poo-poo'd here because everyone knows 'Apple is secure.'  Since nearly 100% of Apple users were on affected version and almost all used a wireless connection at some point, you could argue that Apple users are less secure because any issues affect their entire base.  

 

There's a big difference between a security flaw in iOS and a similar one in Android: Apple can patch the issue before many (or any, in the WiFi case) users are actually affected. It then rolls out its updates rapidly to virtually the entire installed base. iOS 7 is now over 90%, and it came out alongside KitKit. Google can fix the same type of problem, but it can't force its licensees to actually run it through QA and package it up for each model they sell, through every carrier they work with (each of whom has their own diddling to do before they make it available to users). So that's why KitKit is still reaching less than 15% of users. Only the newest Android users will ever get KitKat. That leaves a ton of users who are wide open to vulnerabilities after they're found and even after Google actually fixes them. 

 

But that's not the issue at hand. The problem here is that Google has created an ecosystem that is insecure by design. It has set in motion a series of events it can not fix now, even if it could, wanted to, and spent the effort dickering with carriers and manufacturers to actually roll an update out to users. It has facilitated software that is "self vetting," handing every developer virtually full control to do anything, protected by broad permissions demands that users are forced to accept to get the app to work.

 

The only way Google can fix Android is to start over with a correct design, making it incompatible with the hardware and apps / malware already out there. And if that were possible at this point, Microsoft would have done it for Windows Phone.

 

Google can't compete with the ecosystem it already created. It took many years to get rid of the mistakes of Android 2.x, and that old software still makes up 15% of the "active" Google Play users that Google actually decides to recognize in its officially published dashboard stats. 

 

Never mind that very few users were *actually* hacked (that we know of), the main thing (by your argument) is that they *could have been* hacked.   Either one has valid arguments- but seeing the same argument either supported or brushed off depending on which platform is affected hints at these sites being overly biased (not that that is surprising).

 

We know tons of data are being extracted from Android because that's the core monetization for the platform! Google designed a platform to facilitate full control for advertisers because that's what Google is. It makes its money from selling analytics optimized, audience targeting advertisements. That requires spying on as much user data/behaviors as possible.

 

Or are you naive enough to think that Android exists because Google wants to help people actualize themselves? 

 

Apple, in contrast, makes money selling high end hardware. Apple is motivated to create reliable, quality differentiated hardware and software. Google can make good enough stuff that can pass for free and that hardware makers don't have to pay for to use. If Apple did that, nobody would buy its stuff anymore.

 

Apple is actually profit-motivated to protect users' privacy and security. Google is the very opposite!

 

If you're feeling defensive about lifting widgets & keyboards from Android and that doing security a little differently absolves Apple from thieving- I say run with it.  

 

Google didn't create either feature, so it has nothing it "owns" for anyone to steal, certainly not the company that pioneered dynamically bitmapped multitouch screens with virtual keyboards as a smartphone's primary user interface. While Google clung to physical keyboards and an LED trackball.

 

What Apple most certainly didn't "thieve" is Google's implementation of Intents in Android. Because it is seriously flawed, and assumes apps won't be bad. That's very naive. It's something only a company with zero existing experience in developing and managing a consumer platform would do. And that's exactly what Google was when it delivered extents for Android, when Android was a hobbyist platform before anyone was actually using it.  

 

In my view there is no need to feel defensive about it and no thieving occurred in the first place.  Keyboards are a no-brainer.  Widgets are very nice to have and I hope iOS users enjoy them.  I'd think a bigger driver is that with the smaller screens of prior iPhones, there really wasn't an elegant use for widgets- your screen could really only show one thing at a time.  Now that Apple is going with larger screens, widgets make more sense (and are a must imo) so add them and make them great. 

 

Keyboards are literally a "no brainer" for anyone naive enough to think that allowing anybody to freely distribute a key logger for their platform disguised as a keyboard is a good idea. I don't think you conceptually understand the issue here. Opening access to things like keyboards before you even give it any thought is purely braindead.

 

And when Google opened up Android keyboards to third parties, it hadn't even delivered a functional virtual keyboard for Android itself! Google is like an arrogant teenager to thinks he knows everything, when really he's just a moron who should stay in school for a bit longer.

 

Also, Android introduced widgets back when 3.5" iPhone screens were bigger than any Android phone (because Android phones needed to reserve space for all those keys and that LED trackball!). So your historical revisionism needs some work too.

 

Widgets in iOS are intended to serve a different purpose than on Android. 

 

"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."

post #30 of 66

This was a wonderful article, engaging and informative. I look forward to the next in the series.

 

I feel that you get to the heart of why and how Apple does things.

Post from mstone to Benjamin Frost - "Perhaps that explains your lack of mental capacity. If I was your brother, I probably would have repeatedly smashed the side of your head with a cricket bat."
Reply
Post from mstone to Benjamin Frost - "Perhaps that explains your lack of mental capacity. If I was your brother, I probably would have repeatedly smashed the side of your head with a cricket bat."
Reply
post #31 of 66
Quote:
Originally Posted by Corrections View Post
What Apple most certainly didn't "thieve" is Google's implementation of Intents in Android. Because it is seriously flawed, and assumes apps won't be bad. That's very naive. It's something only a company with zero existing experience in developing and managing a consumer platform would do. And that's exactly what Google was when it delivered extents for Android, when Android was a hobbyist platform before anyone was actually using it.  

What do you mean by "assumes apps won't be bad?" The Intents system is just a general mechanism for structured inter-app communication, analogous to pipes on OS X or any other unix system. You can't eavesdrop on a properly coded application via intents any more than you can with pipes on your Mac. 

post #32 of 66
Quote:
Originally Posted by Corrections View Post
 

correct me if I'm wrong

Well, you've taken an inch of truth and stretched it into a mile of opinionated FUD.  I'll give you a quick rundown (at your request).

 

- Android apps do ask for permissions before install and it is an all or nothing request.  You can't accept some permissions and not others.  There are third party solutions that give you access at that level but they aren't that great and certainly wouldn't work for your average user.  iOS most definitely has an advantage in that area.

 

- Is it fair to call the permissions request 'a laundry list of arcanely worded, generically abstract ideas that only make sense to engineers or tech enthusiasts'?  Not by any stretch of the imagination.  I remember you once likened the permissions popup to software EULA's which was even more laughable.  At that time I showed you some examples of a few randomly picked permissions popups, you must have forgotten about them.  There's nothing overly complicated about them.  I'm not sure if it's just too complicated for you in particular or if you're just trying to spread misinformation.  I suspect the latter.

 

- The vast, vast majority of apps don't request permissions that they don't intend on using for legitimate purposes.  Facebook is obviously an exception to this rule and not the norm, but I suspect you knew this so I won't bother going into why those points are obviously FUD.  Facebook has a long history of shady tactics, the fact that they try to get away with everything they can on Android is status quo for how Facebook operates.  Google's even had to change their app store policies due to past FB actions (when FB tried to start getting people to update their app without going thru the Play Store).


Edited by DroidFTW - 7/7/14 at 4:32pm
post #33 of 66
Quote:
Originally Posted by DroidFTW View Post

Well, you've taken an inch of truth and stretched it into a mile of opinionated FUD.  I'll give you a quick rundown (at your request).

- Android apps do ask for permissions before install and it is an all or nothing request.  You can't accept some permissions and not others.  There are third party solutions that give you access at that level but they aren't that great and certainly wouldn't work for your average user.  iOS most definitely has an advantage in that area.

So rather than "correct me if I'm wrong," you agree that what I described was completely accurate, but you don't like what that means so you serve up personal attacks that claim I'm trying to mislead people. That's not very cool

- Is it fair to call the permissions request 'a laundry list of arcanely worded, generically abstract ideas that only make sense to engineers or tech enthusiasts'?  Not by any stretch of the imagination. 

Oh really? Does the typical user understand what this means?



I remember you once likened the permissions popup to software EULA's which was even more laughable. 

It's exactly like an EULA: a bunch of opaque stuff the user "agrees" to because they have to in order to get software to install.

At that time I showed you some examples of a few randomly picked permissions popups, you must have forgotten about them.  There's nothing overly complicated about them.  I'm not sure if it's just too complicated for you in particular or if you're just trying to spread misinformation.  I suspect the latter.

And yet you just admitted that my overview of android permissions was correct.

- The vast, vast majority of apps don't request permissions that they don't intend on using for legitimate purposes. 

This is a good example of a broad generalization thrown out with zero factual support. It's also irrelevant. Android only needs a few terrible apps to be a security quagmire and privacy death trap. How many Windows apps were known to bundle spyware, yet do you argue that Windows didn't have a serious spyware/adware/popups/virus problem?

Facebook is obviously an exception to this rule and not the norm, but I suspect you knew this so I won't bother going into why those points are obviously FUD.  Facebook has a long history of shady tactics, the fact that they try to get away with everything they can on Android is status quo for how Facebook operates.  Google's even had to change their app store policies due to past FB actions (when FB tried to start getting people to update their app without going thru the Play Store).

Facebook is the most popular store app on every platform. Making excuses for android allowing Facebook to be bad just makes you look disingenuous and hypocritical for accusing me--groundlessly-for "just trying to spread misinformation."
post #34 of 66
Quote:
Originally Posted by d4NjvRzf View Post

What do you mean by "assumes apps won't be bad?" The Intents system is just a general mechanism for structured inter-app communication, analogous to pipes on OS X or any other unix system. You can't eavesdrop on a properly coded application via intents any more than you can with pipes on your Mac. 

Google provides copious literature on the subject when you search for "Intent Vulnerabilities"

The TL;DR short version:

"There are two main ways that the security of intents can be compromised:

"Intent interception involves a malicious app receiving an intent that was not intended for it. This can cause a leak of sensitive information, but more importantly it can result in the malicious component being activated instead of the legitimate component. For example, if a malicious activity intercepted an intent then it would appear on the screen instead of the legitimate activity.

"Intent spoofing is an attack where a malicious application induces undesired behavior by forging an intent."

http://blog.palominolabs.com/2013/05/13/android-security/
post #35 of 66
Quote:
Originally Posted by Corrections View Post

 

 

- I agreed with your, with Android it's all or nothing part.  That was the inch of truth I spoke of.  The rest was the mile of FUD and misinformation.  So to say that I thought your overview was correct would really depend on which part you're referring to.

 

- That permission screen looks old.  Here's a current one so that we're both on the same page (the most relevant one).  Does the typical user understand what this means?  Do you see how ridiculous it is to compare this to an EULA which reads like a lengthy legal document (because it is one)?

 

 

- I never once made excuses for Facebook.  I did the exact opposite.  I believe I stated how FB is known for their shady tactics.  They're shady on all platforms so saying that they're shady on the Android platform isn't saying much.  They're also shady on Windows, iOS, and every other platform that can access Facebook.  I also never said that Android (I assume you mean Google there) allows Facebook to be bad.  That's another instance where I said the exact opposite.  I mentioned how Google has had to put Facebook in their place in the past for shady tactics.

post #36 of 66
Quote:
Originally Posted by Corrections View Post


Google provides copious literature on the subject when you search for "Intent Vulnerabilities"

The TL;DR short version:

"There are two main ways that the security of intents can be compromised:

"Intent interception involves a malicious app receiving an intent that was not intended for it. This can cause a leak of sensitive information, but more importantly it can result in the malicious component being activated instead of the legitimate component. For example, if a malicious activity intercepted an intent then it would appear on the screen instead of the legitimate activity.

"Intent spoofing is an attack where a malicious application induces undesired behavior by forging an intent."

http://blog.palominolabs.com/2013/05/13/android-security/

Intent spoofing is certainly a potential danger, but that's why the system lets developers control what other apps can use their components. It's their responsibility to exercise that control if their app can perform sensitive actions. Quoting from that same link, for example, 

 

"If you write a component that you would like to be accessible only to another application you’ve written, you can export the component but protect it with a signature permission that allows access only to other applications signed by your developer key."

 

See also the slide on Custom Permissions and "Enforcing Permissions Programmatically" (https://www.owasp.org/images/c/ca/ASDC12-An_InDepth_Introduction_to_the_Android_Permissions_Modeland_How_to_Secure_MultiComponent_Applications.pdf).


Edited by d4NjvRzf - 7/7/14 at 11:13pm
post #37 of 66
Quote:
Originally Posted by DroidFTW View Post
 

 

- I agreed with your, with Android it's all or nothing part.  That was the inch of truth I spoke of.  The rest was the mile of FUD and misinformation.  So to say that I thought your overview was correct would really depend on which part you're referring to.

 

- That permission screen looks old.  Here's a current one so that we're both on the same page (the most relevant one).  Does the typical user understand what this means?  Do you see how ridiculous it is to compare this to an EULA which reads like a lengthy legal document (because it is one)?

 

 

Well that's not the same subject is it. Do you see "Network" there at all?

 

But now that you bring it up, Google's new over gross simplification of the rights users are signing away to third parties is only making things worse, not better. See: http://www.citeworld.com/article/2450481/mobile-byod/simplified-android-apps-permissions-will-reduce-user-control.html

 

Not that Android malware developers need to ask for permissions. Flaws that affect "nearly 87 per cent of Android users," including versions even through Android 4.4.2 KitKat, leave users vulnerable tools that can override the permissions system, "surreptitiously dialing out to expensive toll services, potentially racking up big charges on unsuspecting customers' phone bills." See: http://www.theregister.co.uk/2014/07/07/android_dialer_vulnerabilities/ (that's from today).

 

- I never once made excuses for Facebook.  I did the exact opposite.  I believe I stated how FB is known for their shady tactics.  They're shady on all platforms so saying that they're shady on the Android platform isn't saying much.  They're also shady on Windows, iOS, and every other platform that can access Facebook.  I also never said that Android (I assume you mean Google there) allows Facebook to be bad.  That's another instance where I said the exact opposite.  I mentioned how Google has had to put Facebook in their place in the past for shady tactics.

 

Read that again. You tried to shift the blame to Facebook, I pointed out that Google's Android platform allows Facebook to do bad things. If it's really that hard to understand what I'm saying (and which one of us said what I just wrote), it's no surprise why you are completely unaware of any security issues affecting Android.

 

I did ask you a question about Windows that you also sidestepped. Too painful to contemplate?

 

One has to be willfully ignorant or purely delusional to insist that Android does not have serious security issues. Google got on stage for a painfully slow discussion at IO of how it plans to address the major problems that are keeping Android products out of the enterprise. Did you even pay any attention? Or were you bamboozled by the BS statistically smoke and mirrors the company danced around before it claimed credit for Apple's exact implementation of CarPlay as if Google invented the entire thing itself? 

 

Really, pick a new god, as Google is simply a joke at this point. 

post #38 of 66
Quote:
Originally Posted by d4NjvRzf View Post
 

Intent spoofing is certainly a potential danger, but that's why the system lets developers control what other apps can use their components. It's their responsibility to exercise that control if their app can perform sensitive actions. Quoting from that same link, for example, 

 

"If you write a component that you would like to be accessible only to another application you’ve written, you can export the component but protect it with a signature permission that allows access only to other applications signed by your developer key."

 

See also the slide on Custom Permissions and "Enforcing Permissions Programmatically" (https://www.owasp.org/images/c/ca/ASDC12-An_InDepth_Introduction_to_the_Android_Permissions_Modeland_How_to_Secure_MultiComponent_Applications.pdf).

 

Describing some possible solution to an existing problem does not change the fact that there is a clear, recognized problem with actual existing software that is widely known about and already being exploited in the real world.

 

You asked, "What do you mean by 'assumes apps won't be bad?'" and then I gave you an answer. Why run to change the discussion to be about how one can indeed assume apps can be bad, while ignoring the clear and obvious corollary that Google allowed those cases to exist by designing a flawed system in its rush to deliver functionality without considering what could happen?

 

Or are you just trolling to demand researched answers to questions you already know the answers to?

post #39 of 66
Quote:
Originally Posted by DroidFTW View Post

Quote:
Originally Posted by Corrections View Post

 

- I agreed with your, with Android it's all or nothing part.  That was the inch of truth I spoke of.  The rest was the mile of FUD and misinformation.  So to say that I thought your overview was correct would really depend on which part you're referring to.

- That permission screen looks old.  Here's a current one so that we're both on the same page (the most relevant one).  Does the typical user understand what this means?  Do you see how ridiculous it is to compare this to an EULA which reads like a lengthy legal document (because it is one)?




- I never once made excuses for Facebook.  I did the exact opposite.  I believe I stated how FB is known for their shady tactics.  They're shady on all platforms so saying that they're shady on the Android platform isn't saying much.  They're also shady on Windows, iOS, and every other platform that can access Facebook.  I also never said that Android (I assume you mean Google there) allows Facebook to be bad.  That's another instance where I said the exact opposite.  I mentioned how Google has had to put Facebook in their place in the past for shady tactics.

I think that that permissions window is equally bad. What does 'uses account' mean? Are you handing over your account password, your name, your address, your phone number or what?
Post from mstone to Benjamin Frost - "Perhaps that explains your lack of mental capacity. If I was your brother, I probably would have repeatedly smashed the side of your head with a cricket bat."
Reply
Post from mstone to Benjamin Frost - "Perhaps that explains your lack of mental capacity. If I was your brother, I probably would have repeatedly smashed the side of your head with a cricket bat."
Reply
post #40 of 66
Quote:
Originally Posted by Corrections View Post
 

 

Describing some possible solution to an existing problem does not change the fact that there is a clear, recognized problem with actual existing software that is widely known about and already being exploited in the real world.

 

You asked, "What do you mean by 'assumes apps won't be bad?'" and then I gave you an answer. Why run to change the discussion to be about how one can indeed assume apps can be bad, while ignoring the clear and obvious corollary that Google allowed those cases to exist by designing a flawed system in its rush to deliver functionality without considering what could happen?

 

Or are you just trolling to demand researched answers to questions you already know the answers to?

It's not just "some possible solution." It's using the system as designed. That intents (which, I'll concede, are unlike pipes in this regard) are integrated with a fine-grained permissions system suggests that rather than assuming that apps won't be bad, the system is designed to help the developer secure their applications against bad apps. You could, however, argue that Google should do more to educate developers in best practices instead of leaving that up to security conferences.

 

Damage caused by incorrect use of a tool is not necessarily an indictment of the tool itself. If you use a sharp knife in the kitchen and cut yourself by using an improper grip, is the knife maker to blame for making the knife so sharp? If you accidentally wipe out a directory by running "rm *"  at the command line, is Apple to blame for shipping a powerful command line with OS X? Is the "rm" utility flawed for accepting wildcards, when the user can easily alias "rm" to "rm -i" to prevent such an accident? You can cause great damage on your Mac with an improperly coded program. Is Apple to blame for providing all those APIs in the first place?


Edited by d4NjvRzf - 7/8/14 at 8:01pm
New Posts  All Forums:Forum Nav:
  Return Home
  Back to Forum: iPhone
  • Inside App Extensions: Apple, Inc's new Widgets & Keyboards similar to Android's, but secure
AppleInsider › Forums › Mobile › iPhone › Inside App Extensions: Apple, Inc's new Widgets & Keyboards similar to Android's, but secure