|| and ^ were added late, so they might cause bugs anywhere.

I've checked the code, and it looks like the pipe can break the hashing code, because it's not in the IsCharacterWildCard(). For example, "||com/" does not match "http://example.com/".

The content_filter could be improved a lot in many interesting ways.

All the extensions with ad-block subscriptions take a very long time to load and update filters. I haven't tried to debug them, but I suspect that it is the API being very slow to load filters one-by-one and not the extensions themselves.

I also suspect that the matching algorithm can be improved, especially for the huge lists. /content_filter/tests/data/hugelist.ini has 4k lines... fanboy-ultimate.txt is over 90k (~50k without CSS rules). Currently they seem to check every filter's hash for the given URL in the FilterURLList::Find(). One beautiful optimization would be to store most rules starting with || in a hash table with the domain as a key (with 2-level domain minimum and, say, 4-level maximum). That should make matching over that set faster, especially since you often have to check multiple URLs with the same domain. More general rules could also use something of [ url_length * log(filter_list_length) ] complexity, although I'm not sure what's possible there and how would it compare to the current approach.

The API and format could be improved too. Caching hashes between browser restarts and differential list updates come to mind.