[robotcookies]

The issue I have with Cook's proclaiming support for strong encryption is that Apple still has control over what can and can't install on the user's device. So imagine if some strong agency came and said to a company you can't allow certain apps to install and you can't tell your customers we told you this. "You can allow these apps that claim to encrypt user's messages [list here], but not these [list here]". So some state could still strong arm Apple into compromising privacy and Apple would have their hands clean.

It seems that if you really want to guarantee privacy, you have to give the individual control over what they can install. Telling people to just "trust us" is not really good enough. And Cook is saying they are giving the user ultimate control by not having keys to their encryption but in reality that's nonsense... they are still requiring people to trust them.

[merpnderp]

I use a lot of web apps on my iphone. They don't have access to all the phone's apis, but they do everything I need, without any hindrance from apple oversight.

This is probably the most native looking one of the bunch: https://forecast.io/

[tonyarkles]

From an encryption point of view though, they're relatively useless. Said three-letter agency now doesn't need to block the app, they can instead MITM the traffic to it or compel the organization to inject additional client-side or server-side code to complete the backdoor.

Certificate pinning helps against the MITM problem, but code integrity for downloaded client-side code is pretty tricky. Browsers could add some form of signed code pinning for power users, but it'd be tricky to be able to distinguish between legitimate updates and nefarious activity.