On 2013-03-28, at 10:42 PM, Jon Callas <j...@callas.org> wrote:

> On Mar 28, 2013, at 6:59 PM, Jeffrey Walton <noloa...@gmail.com> wrote:
> 
>> We've seen it in the past with for example, Apple and location data,

> Well, with locationgate at Apple, that was a series of stupid and unfortunate 
> bugs and misfeatures. Heads rolled over it.

There are a couple interesting lessons from LocationGate. The scary 
demonstrations were out and circulated before the press and public realized 
that what was cached were the location of cell towers, not the phones actual 
location and that there was a good reason for caching that data. But I suspect 
that the large majority of people who remember that, still are under the 
impression that Apple was arbitrarily storing the the actual locations of the 
phone for no good reason.

The scare story spread quickly, with the more hyperbolic accounts getting the 
most attention. The corrective analysis probably didn't penetrate as widely.

The second lesson has to do with the the status of iOS protection classes that 
can leave things unencrypted even when the phone is locked. There are things 
that we want our phones to do before they are unlocked with a passcode. We'd 
like them to know which local WiFi networks they can join and we'd like them to 
precompute our locations so that that is up and ready as soon as we do unlock 
the phones. As a consequence things like WiFi passwords are not (or at least, 
were not) stored in a way that are protected by the device key. The data 
protection classes NSFileProtectionNone and 
NSFileProtectionCompleteUntilFirstUserAuthentication have legitimate uses, but 
it does lead to cases where people may thing that some data is protected when 
their device is off or locked which in fact isn't.

The trick is how to communicate this the people, most of whom do not wish to be 
overwhelmed with information.  There are lots of other things like this 
(encrypted backups and thisDeviceOnly, 10 seconds after lock before keys are 
erased, etc) that really people ought to know. The information about these 
isn't secret, Apple publishes it. But it takes some level of sophistication to 
understand; but mostly what it takes is interest.

> In neither of those cases was anyone trying to spy. In each differently, 
> people were building cool features and some combination of bugs and failure 
> to think it through led to each of them. It doesn't excuse mistakes, but it 
> does explain them. Not every bad thing in the world happens by intent. In 
> fact, most of them don't.

What's the line? Never attribute to malice what can be explained by 
incompetence.

At the same time we are in the business of designing system that will protect 
people and their data under the assumption that the world is full of hostile 
agents. As I like to put it, I lock my car not because I think everyone is a 
crook, but because I know that car thieves do exist.

Cheers,

-j
_______________________________________________
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Reply via email to