Google's Schmidt: Android more secure than iPhone

Google’s Schmidt: Android more secure than iPhone

To an extent, this is an amusing anecdote about how out-of-touch Schmidt is. But to be fair, there may well be a genuine disconnect between what Schmidt thinks ‘secure’ means, versus what everyone else thinks it means.

Android’s security is based around blaming the user. ‘But you said it was okay for this malware to have root access, you clicked OK!’

To wit:

1. When installing an app, Android requires the user to accept the app’s requested permissions before it even starts, as a precondition for installing the app. If the user declines those permissions, the app will not install. This dialog is an interruption–it is getting in the way of what the user wanted to do. The obvious result is that it trains users to click OK just to get past it to the thing that they wanted in the first place.

2. Android requires the user to accept all of the permissions an app asks for, or none of them. There is no way to accept only the permissions the user wishes, while declining others. This allows developers to demand unreasonable permissions that they don’t actually need, because they’re holding the entire app hostage from the user. And so–surprise!–many developers on Google Play do exactly that.

3. iOS simply forbids the most dangerous types of actions, like root access to the file system or access to phone call or SMS data. There is no permission dialog for these; they are simply disallowed, both in terms of the APIs not being available for use, and by Apple’s review policy.

Theoretically, Android may have the best security system in the world. But it all falls apart when you wrap it around a horrible UI that not only allows the users to shoot themselves in the foot by overriding the protections, but trains them to do it constantly as a matter of routine operation. It may as well not even exist.

This is why, in practice, Android has a malware problem. But it doesn’t surprise me that Eric Schmidt wouldn’t see it this way. It’s reflective of Google’s culture as a whole, which seems to champion engineering above all else.

But the more concerning thing should be that the company (or at least their effective spokesperson, Schmidt) doesn’t even acknowledge the existence of the problem. Yes, it was an antagonistic question and he had to answer in a way that paints his company in a positive light. But he could have given any number of placating non-answers to this question² which would have resulted in it being a complete non-story that nobody would be talking about today.

Instead, he drew even more attention to the problem, and the fact that Google doesn’t seem to be fixing it. Because you can’t fix something if you don’t even realise that it’s broken.

---

1. I know someone who uses Google Maps on iOS this way, because she doesn’t trust Google to know her location. It makes me crazy to watch her use it this way, but the point is that it’s her choice and that’s what works for her. The device should do what she wants, not the other way around. ↩︎

2. The typical corporate P.R. handbook response is to ramble on with a whole bunch of fluff that means nothing, doesn’t address the question at all, and will make your audience fall asleep listening to it. But that’s not the only way. Consider Tim Cook’s response to Sen. John McCain’s off-the-cuff question about why he has to manually update the apps on his iPhone; Tim said, ‘We’re trying to make them better all the time.’ Simple and to the point. Keeping the message positive, while acknowledging room for improvement. Was that so hard? ↩︎

Laundry Minder v1.1

Laundry Minder v1.1

I managed to ship my app’s iOS 7 update to the App Store just prior to the release of iOS 7, with thanks to the app review team for their quick turn-around.

Not much is different in functionality, but it’s got a nice visual refresh. Say what you want about iOS 7’s visual style, but the default UI elements look a whole lot better out-of-the-box than they ever have before on iOS. Which is good for me, since I’m not a designer by any means, so I mostly just use the built-in stuff unmodified. This time around, I stuck in a nice background pattern from subtlepatterns.com–I know, I know, patterns are supposed to be gone! But I’m quite pleased with the result.

There are a bunch of tiny, subtle improvements I’ve made over the past few years that I never got around to shipping until now. Of course, now that I’ve done those, I’ve found a half-dozen more little things that bother me about it. Sigh.

Also, I finally got around to fully supporting the iPhone 5 (despite having owned one myself since last year!) and the iPad.

I wish I had more time to dedicate to this little app. It’s by no means a big seller, but has a special place in my heart since it’s the app I made in order to learn Objective-C and Cocoa, nearly two (!) years ago, and helped me get a job doing what I really love to do. So, as much as I know it’s not worth spending time on, I can’t let it go just yet.

Plus, I still use it to time my laundry every week.

Thanks once again to my friend Andrew Wignall for the nice icon update, which he did without me even asking. Facing the alternative–my own terrible drawing skills–I would have probably been too embarrassed to ever release the app in the first place.

Thanks for clearing that up

Thanks for clearing that up

Article headline:

Why the Vita TV and other “microconsoles” are destined to fail

First sentence of final paragraph in said article:

This isn’t to say the Vita TV (or other microconsoles based on low-cost portable technology) will be a total bomb.

Okay.

Don’t Trust iTunes Movies in the Cloud

Don’t Trust iTunes Movies in the Cloud

I wondered about the hypothetical situation described in this article at one point, but I thought, nah, that couldn’t possibly be how it works.

It is.

Working in the Shed — Matt Gemmell

Working in the Shed — Matt Gemmell

Whilst I of course still had my phone and could readily have tethered a laptop to it, I chose not to. I did check email and twitter on the phone, but the simple act of it being on a separate (and small) device relegated those tasks to the background, in a way they hadn’t been for years.

I’ve been doing something similar for years: For work, I use a separate OS X user account that only has work stuff in it–no Twitterrific, no RSS, no personal IM or email, not even any saved passwords in Safari. Combined with an office with a door I can close (I work from home, mostly). Nothing fancy, and no special software needed. The iPhone is nearby for personal stuff if I really need it for some reason, but on a good day, I forget it’s even there. It’s amazing what a difference it makes just to not have stuff in your immediate field of vision.

ParcelKit — Seamlessly integrate Core Data with Dropbox

ParcelKit — Seamlessly integrate Core Data with Dropbox

After thinking about it some more, I’m no longer as convinced as I was a few days ago of Dropbox’s inevitable dominance in the realm of third-party iOS app database syncing, for several reasons:

1. Dropbox’s conflict resolution looks not great. I see what they’re going for: it’s fully automatic, so the user never has to make any choices. But there’s an obvious problem with that: sometimes, the algorithm is going to choose wrong. What then? The correct answer is, ‘the old version of the data can still be retrieved’. But as far as I can tell, the real answer is, ‘the data is gone forever’. Hmm.
2. It’s a completely different pattern than Core Data, which is refreshingly simple. However… I happen to like Core Data, and I would miss a lot of the features that Core Data provides for me.
3. I finally found time to watch some of the WWDC ‘13 videos, and I’m tentatively willing to believe that the iCloud improvements in iOS 7 are a step in the right direction.

However, ParcelKit, if it works, just removed reason #2.

Dropbox adds support for synchronised databases

Dropbox adds support for synchronised databases

First thought: iCloud is over. Dropbox is now a complete iCloud replacement for developers, and with a much better chance of it actually, y’know, working. The only apps using iCloud will be Apple’s own apps.

Second thought: If Apple had succeeded in buying Dropbox, this is what iCloud could have been. Alas.

iOS 7 displays Retina versions of iPhone apps on non-Retina iPads

iOS 7 displays Retina versions of iPhone apps on non-Retina iPads

The comments attached to this article¹ express bemusement on why such a seemingly simple thing wasn’t done sooner. The answer, of course, is that it’s not simple.

Here’s the problem domain: A non-Retina iPad has a screen that’s physically about twice as big (by single dimension) as an iPhone, yet has half the pixel density as a Retina device, for an overall total of roughly the same number of pixels of a Retina iPhone. Therefore, you want to be able to show Retina graphics when an iPhone app is running in 2x mode, but not when it’s in 1x mode.

There is no way to do this. iOS apps rely heavily on bitmap graphics, which are are loaded when a view first appears, and then not again, unless the app specifically wants to. You have to start the app either in Retina mode, or non-Retina mode, and then stay in that mode as long as the app is running; you can’t change midway, because the signals to tell an app that this kind of a change has occurred don’t even exist². The reason they don’t exist is because in the context of an iPhone, it makes no sense: Retina status is an aspect of the physical hardware, and is therefore immutable. And it wouldn’t be worth the engineering resources to add this kind of Retina-mode-change-signal into the frameworks now, nor would it be worth the developer outreach efforts and compatibility frustrations to get every single App Store developer on-board with the change–look how many apps still don’t even support iPhone 5!³. Would that many developers rush to support such an iPad-specific edge case, especially considering these are developers who apparently haven’t bothered to support the iPad within the past three years?

In theory, you could always start in Retina mode, and then shrink everything by 50% for ‘1x’ mode (in reality, it would be an 0.5x-of-Retina mode). But the entire point of having Retina graphics is that you can optimise all of the artwork for the actual pixels of the screen. Remember, this is iOS, where everything is bitmaps! A good icon designer will not simply draw an icon once at the highest resolution and then scale it down; they will actually manually draw from scratch–or at least heavily tweak–each and every one of the different sizes, so that they look ideal at every possible resolution. And now you want to destroy their carefully crafted work by turning all of those one-pixel lines into a blurry, anti-aliased mess? Not on Apple’s watch.⁴

This is why the solution that Apple went with in iOS 7 completely removes the 1x/2x toggle button on non-Retina iPads–you either get Retina mode always, or never. In iOS 6, it was never; in iOS 7, it’s always. There is no middle ground.

For Retina iPads, I surmise, the behaviour is unchanged from iOS 6–they’ll show Retina graphics at 1x, because why wouldn’t they?–but at 2x, you’ll see pixel-doubled Retina graphics, because there just isn’t any bigger ‘x’.

Arguably, the way it was in iOS 6 and earlier was simpler for users to understand: All iPads, Retina or not, had a toggle button that displayed an app at the device’s native resolution at 1x, and pixel-doubled at 2x. This change allows non-Retina iPad users to see better graphics, at the expense of making the overall situation more confusing for everyone. I’m not saying the decision was wrong, only that both solutions have downsides and there is no clear winner.

Not a simple as you thought, is it, dear user? Welcome to my world. Please remember this the next time you’re thinking of beginning a sentence, ‘why can’t you just…’

I haven’t personally tried any of this on iOS 7, so all of the above info is either gleaned from the MacRumors article or from my personal experience developing for iOS 6, which, in either case, may be wrong.

Edit: It later occurred to me that this change allows developers to make Retina-only apps for the very first time, but only under the following conditions:

1. The app has no native iPad support (iPhone only)
2. The app requires iOS 7

Under these two conditions, a developer can safely remove any and all non-Retina assets or code, and go Retina-only for their iPhone apps, because as of iOS 7, it is guaranteed that iPhone apps will never ever run in non-Retina mode, regardless of device. The same is not true of iPad apps.

This is almost certainly the reason why Apple made this change.

---

1. Side note about the original, unnecessarily obtuse MacRumors headline: Almost anywhere you see the words ‘leverage’ or ‘utilise’, you can substitute the much simpler word ‘use’, for a sentence that has the exact same meaning yet is much faster for readers (or listeners) to understand. The purpose of language is to communicate, not to make yourself look smart. ↩︎

2. In theory, you could just wait for the view to change as a result of a user action (e.g., the user navigate somewhere else within the app) before changing the mode from or to Retina. But in the meantime, the app would look awful until the user just happened to do something to cause a different view to appear, and they likely wouldn’t understand what was going on at all. Not a good experience. ↩︎

3. Yours truly being only one such egregiously guilty party. ↩︎

4. See what I did there? ↩︎

Can Apple read your iMessages?

Can Apple read your iMessages?

Remember, ‘won’t’ is different than ‘can’t’.

The difference is that ‘won’t’ is equivalent to ‘can be forced to do it in secret by our government’.

I still think Apple is trying to do the right thing here and that it is a net positive for the majority of users who have no knowledge or expectation of encryption. Maybe it can stop some eavesdropping, maybe not–it’s better than not even trying. But that doesn’t mean that you should trust it with your secrets. Trust nothing that you can’t verify yourself.

Also: Hacker News discussion.

iMessage and FaceTime are end-to-end encrypted

[…] conversations which take place over iMessage and FaceTime are protected by end-to-end encryption so no one but the sender and receiver can see or read them. Apple cannot decrypt that data.

Interesting to hear this from the horse’s mouth. iMessage and FaceTime have long been suspected to work this way, but as far as I know, this is the first time Apple itself has confirmed this.

Of course, the fact that we needed Apple to inform us of this precludes it from being useful to people who have a serious need for this kind of security–they must be able to directly observe for themselves that it works that way.

However, that doesn’t diminish the benefits to users who don’t know or care about encryption–those people are (if the quoted statement is accurate) protected from eavesdropping, whether they know it or not–and that makes it worth doing. This includes both innocent people who might be wrongly monitored, as well as criminals who will be that much harder to convict. But that is the price of living in a free society: everyone has privacy, or no-one does. There is no middle ground.

I would love to know more technical details about how this is accomplished.