* Thomas Moertel [2013-03-21 15:58:58-0400]

On Wed, Mar 20, 2013 at 5:05 PM, Johan Tibell wrote:

...

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.

I understand that HashMap exists to provide speed, but are we sure that everyone who uses it for speed understands the security implications?

Regardless of whether speed-first or security-first is the default, users of HashMap can be partitioned into two groups: those who knowingly choose between speed and security, and those who do not. For the first group, either default is safe because members of that group will have the opportunity to choose the other option. But for the second group, only security-first is safe: if it’s not the default, members of the second group won’t have the option to choose it.

Why not simply educate them by placing a prominent notice in the haddock?

The problem for the Haskell Platform is that the second group is likely to be large. The whole point, after all, is to make a curated set of tools and libraries available to a large audience that doesn’t necessarily have the time or knowledge to make its own informed choices. So if we decide, on behalf of this audience, that the Haskell Platform is going to be less secure to get more speed, aren’t we exposing a lot of Haskell users to preventable security risks?

I’m not just arguing the case of HashMap but of the whole Haskell Platform. I’d like to think that a widely used platform should be safe by default and offer danger-with-benefits as an option.

The whole security issue is that, in some cases, the complexity of the code may be unexpectedly bad. Unfortunately, it is already the case with Haskell. Laziness makes it extremely hard to make guarantees about the worst-case complexity of a non-trivial code base. Roman