On Wed, Mar 20, 2013 at 1:04 PM, Thomas Moertel <span dir="ltr"><<a href="mailto:tom@moertel.com" target="_blank">tom@moertel.com</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>On the speed vs. security trade-off, there’s a good argument for the Haskell Platform to choose security as its default policy: speed problems are obvious and have understandable consequences and remedies, but security problems are hidden and have poorly understood consequences and often lack remedies altogether. You can’t go back in time to remedy being pwned.</div>
<div><br></div><div>Therefore, if we make speed the default, we leave open to harm everybody who fails to fully understand the security implications of their libraries’ default choices, which is just about everybody. But if we make security the default, nobody will be taken unaware, either by speed or preventable security problems.</div>
<div><br></div><div>Yes, those people who need the extra speed will have to suffer the cost of opting-in to the faster implementations, but that cost is predictable and relatively small. The point is that nobody is going to be taken unaware by failing to make the right choice up front. The first time you run your code and it’s too slow, you’ll know. </div>
</blockquote><div><br></div><div>The problem is that if the secure hashing makes HashMap as slow as Map, there's no point in having the former in the first place, as it only exists to provide speed.</div><div> </div>
</div>