[md_]

Don't take this the wrong way, but as a non-lawyer, I try to heavily caveat any statement I make about the law.

Would you consider heavily caveating statements you make about information security? A lot of what you say here is basically wrong.

[dmix]

Indeed, this is technical expertise domain of an information security researcher, not a lawyer.

A national security lawyer could provide interesting insight into how the CIA is allowed to use these tools vs NSA.

[libertymcateer]

> I try to heavily caveat any statement I make about the law.

That is appreciated, and you are in the minority.

I'm taking this advice, btw, and being more circumspect when I post in the future.

[md_]

:)

Cheers.

[libertymcateer]

For serious, thank you for taking the time to engage. I do take this seriously.

[md_]

Yep. Same. And I would probably have posted a longer and less confrontational explanation of why you're (mostly) wrong if I weren't tired after a long day of work. ;)

The whole "why not encrypt local resources" thing is an odd red herring that a lot of (even fairly experienced) people trip over. There was a massive public furor over Chrome's chrome://settings/passwords (i.e. lack of a master password) design choice a couple of years ago that was a specific such case in point.

[libertymcateer]

This argument is almost exactly what I was on about. I'd love to see some summary of it and why they came down where they did.

[md_]

Sorry. I went to bed. I'll frame the basic argument for Chrome and then show how it expands to other systems.

Chrome: =======

Someone who can access chrome://settings/password is presumed to have physical access to your powered-on, unlocked machine. E.g. someone who sits at your keyboard when you get up for coffee.

And that person can just as easily install a Chrome extension that sniffs your passwords or steal your raw auth cookies directly from the developer console. (He could even paste some JS into the developer console to intercept the password as-typed by autocomplete!)

(Note that an attacker with access to a locked/powered-off machine or with no local access is not part of the threat model, since they are presumed to be addressed by FDE, screen locks, remote access controls, etc.)

Now, the major counterargument is essentially that a lot of unsophisticated attackers (like spouses) may not know about cookie jars or JavaScript, but they know about "view saved passwords." I find this argument somewhat reasonable, but from some vantage point it's security theater--not knowing about ctrl+j isn't a strong security guarantee, after all. So I view the Chrome team's stance as being a very principled one, namely: don't invest in "security" features where a bypass would not be a bug.

(In some literature this is referred to as a "security boundary", typically defined as "a control which, if bypassed, has a bug." Note the contrast with, for example, spam filters and antivirus, which may be sometimes bypassed while working as intended.)

More generally: ===============

I think what was lacking in this conversation in general was a firmly defined threat model and a firmly defined security boundary. My contention about per-application encryption is that it doesn't represent a security boundary because any attacker who can execute code that can read application-ACL'ed data on disk is by definition either running code at a higher security level (e.g. has root) or is running code at the same security level (and can thus inject code into the browser process itself).

This conversation gets a little more complex when talking about mobile OSes that have per-application sandboxing, but the same observation effectively holds.

Anyway, I'm tired of typing, but hopefully that makes a bit of sense. Let me know if I'm being confusing.