Checking on the firefox-dev test now.

Despite a note to the contrary, it looks like the developer edition is now strictly enforcing xpi signatures. I've updated the https://github.com/EFForg/https-everywhere-docker-base URL to point to the unbranded edition of Firefox Dev, so once that is done building I can re-run the tests and we should be good.

@Hainish Nightly is unbranded by default and does not enforce extension signing.

To disable signature checks, you will need to set the xpinstall.signatures.required preference to "false".

@Hainish It seems that you'd have to modify test/script.py to disable signature checking in the Developer Edition. Did you test it?

@cschanaj this is already set by https://github.com/EFForg/https-everywhere/blob/master/test/firefox/test_profile_skeleton/prefs.js#L10

@cschanaj in the latest Firefox versions this pref does not change the behavior as they've made signature checking mandatory.

@Hainish okay. would you also review and merge this PR?

@cschanaj yes but it'll have to wait until at least tomorrow

@Hainish never mind, but I would like this to be merged before the next release given the performance boost it will provides. thanks.

This is great. Efficiency can be further improved by utilizing a radix trie, indexed by the string reversal of the target (moc.elpmaxe) but this is contingent upon #11203

I agree a radix trie should be the best structure for the domains, but we will have to wait #11203 is completed. So I guess using Map could be a easy fix in the short term. 😄

@Hainish Maybe use a bloom filter or a prefix list?

AFAIK, a bloom filter gives probabilistic results. And thus using a bloom filter might require a major rewrite.

@koops76 bloom filters are only appropriate solutions when false positives are acceptable. That's not true here - we don't want to DoS a site unintentionally!

@Hainish We can verify positives by hashes or simply a list of acceptable targets.

And a bloom filter give boolean results. The searching of applicable results is still inefficient.

@Hainish thanks! I will work on using JSON instead of XML for default.rulesets in a later PR.