Rated 4 out of 5 stars
Earlier you replied to someone saying:
"No option for viewing what i have blocked so far"
I understand if you're trying to 'hide' sites that you've visited then this is would be a great feature. But, some people could be using this add-on for other reasons. For example, I'm using it to block sites that I don't want cluttering up my history. Usually gaming sites that I don't care to remember what pages I visited and don't need a couple hundred pages stored in my history, slowing things down.
Is there anyway to add this as an option? Maybe turn it off as default, and if it's on, password protect it or something?
Password protection is a suggestion which comes up often instead of 1-way hashing. To put it simply, I do not know what (if anything) I have available in the api to actually get after strong password protection. Additionally, I do not fancy writing my own password protection implementation for HB because it would be hard, I would probably get it wrong, and it would do something that I fundamentally do not care for.
Here is an example, when you hash example.com, it becomes 97612fdad3f6b17f61d6912994b66ea7b7bacc99. For one, that is completely non-human-readable, so we really don't care whether anyone can access that. For two, sha1 has been proven to have collisions, which simply means that even though someone can try infinite inputs to try and get 97612fdad3f6b17f61d6912994b66ea7b7bacc99 as an output, they might find that "asfbniqnqeaviubqqpivvioboqq" also maps to the output 97612fdad3f6b17f61d6912994b66ea7b7bacc99. Just finding an input doesn't win the battle... finding the RIGHT input does. ADDITIONALLY, that may only map to example.com if the haxor attempted to find THAT entry. My personal blacklist has HUNDREDS of these hashes, many of them are "example.com", "www.example.com", "www.foo.net", etc in testing HistoryBlock development... picking the right hash, then generating the rainbow tables then using them may EVENTUALLY find example.com... but even then they only have one of my hashes de-hashed.
Conversely, if the blacklist is password protected and the password is compromised (via a vulnerability in the protection implementation or just brute-forcing the password), then ALL the domains are listed. This is potentially scary.
I WILL look into this to see if I can get an implementation that makes sense (and is off by default), but I will make it TOTALLY understood by any user that it is dangerous (in my opinion) to use the password protection model as opposed to the hash model.