<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div>On Wed, 4 Jun 2014 21:05 John Ioannidis wrote:</div><blockquote type="cite"><br>On Wed, Jun 4, 2014 at 7:36 AM, Jerry Leichter <<a href="mailto:leichter@lrw.com">leichter@lrw.com</a>> wrote:<br><br><blockquote type="cite">As software engineers, we're always drawn to make our systems as general<br>and powerful as possible; but it's long been clear that power and security<br>are antithetical. Javascript in browsers is a great example. A browser is<br>fundamentally a display, and yet we've been drawn to include within it the<br>a Turing-complete programming language - which inevitably opens holes for<br>abuse, which then get patched or limited through some kind of wrapping<br>sandbox.<br><br>Meanwhile, the only full defense is browser extensions that simply block<br>Javascript completely - something that's impractical for most major<br>websites today.<br><br>The fundamental problem here is the accepted belief that a browser's<br>quality is related to the faithfulness of its implementation of the<br>Javascript specs - even when those specs lead to browsers that facilitate<br>attacks against their users.<br><br>Let me give a couple of examples of the kind of thing I'm talking about:<br><br>1. Javascript lets you create new windows - and because some companies<br>and programmers have a goal of allowing browser apps to look just like<br>native apps, it lets you create any kind of window at all. As a result,<br>it's impossible for a browser to define a "secure password prompt" window<br>(though some - Safari, for example - have tried): Anything the browser can<br>do, a Javascript hack can do. Other attacks - e.g., clickjacking - are<br>based on the same basic power.<br><br>But why grant that power? A Javascript implementation that always created<br>windows with a specific chrome on them, forced them to be visible, and<br>enforced a minimum size, might inconvenience some developers, but would<br>render a whole class of attacks impossible. You might actually be able to<br>trust that a password prompt really *was* a password prompt.<br><br>2. Javascript implements a ton of environmental queries, from screen<br>resolution and size to fonts on the machine to cache information. This<br>allows for easy fingerprinting of browsers. A Javascript implementation<br>that simply lied about this stuff - rounding screen information to one of a<br>few standardized values, sending back a fixed list of standard fonts in a<br>standard order, and so on - could stop such attacks.<br><br>3. If a Javascript implementation ignored actions that triggered on<br>attempts to close a window, all kinds of extortionate programs would have a<br>much harder time harassing and terrifying ordinary users.<br><br>Of course, what I've said about Javascript applies equally well to other<br>browser facilities. If there are things in HTML5 that make attacks easier<br>while not adding anything significant - don't implement them, or implement<br>them in a way that mitigates the risks, even if doing so violates the<br>standards.<br><br>It's a fundamental (and paradoxical-appearing) result in game theory that<br>sometimes deliberately limiting your own choices improves your position.<br>We've been discussing keeping the level of language in protocols low in<br>the Chomsky hierarchy to limit vulnerabilities in parsers. The same idea<br>applies elsewhere. It'll be a tough lesson to learn, given decades of<br>design philosophy that looks for ever more power - even the tools that<br>disable Javascript are perceived not as limitations but as a way to give<br>the user more choices. But it's a lesson we need to learn if we're to have<br>any hope of building more secure systems.<br><br> -- Jerry<br><br><br></blockquote>Jerry, you know very well why none of these are ever going to happen. Why<br>are you even bothering to enumerate them?<br></blockquote><br><div>I think we are being a little too defeatist here. This is mostly a question of good marketing, not technology. A set of "security extensions" to Javascript that users could opt for might well be adopted if it had wide support from the security community. There are only a few major browser vendors and most have some interest in getting things right. The extensions would need to be well-thought out beforehand, and there is still the cat-herding problem, but getting organized is long overdue. </div><div><br></div><div>And while we are on marketing, might I point out "FalseCrypt" is not an optimal choice of name for a TrueCrypt fork? All for the fork, but really... How about PhoenixCrypt?</div><div><br></div><div>Arnold Reinhold</div></body></html>