Please, don't retire the rulesets.

[KOLANICH]

Type: other

In the wake of https://www.eff.org/deeplinks/2021/09/https-actually-everywhere and https://www.eff.org/deeplinks/2021/04/https-everywhere-now-uses-duckduckgos-smarter-encryption .

There are plenty of places where http:// URIs reside. While we can bulk-replace them with sed and say that it is the problem of the websites that they don't support https and that all plain http websites must become nonfunctional, it is not a constructive approach.

I have developed a tool https://github.com/KOLANICH-tools/https-everywhere-py/tree/bulk_replace applying HE rulesets to URIs in text files. It is a fork of https://github.com/jayvdb/https-everywhere-py , and a PR has been sent for integrating the code into the upstream, but the upstream project seems to be pretty dead.

Using this tool would help to avoid breakage, while improving security the projects, where "https-only mode" cannot be used.

[zoracon]

While we understand not every site seamlessly supports HTTPS, the crowdsourced rulesets became a wider maintenance burden over time for this project. It provided granular rules for different sites, but with wider adoption (and the mistakes that can come with it) the memory will only increase on the extension's end. We did try to reduce memory and issues with rewriting the rule redirects in Rust, but we decided that partnering with DuckDuckGo's efforts and offering redirect matches through the extension with their list was a reasonable partnership. Rather than creating more projects of divergence to maintain further. We plan to have the rulesets archive hosted for a period of time, but these will be retired.

[KOLANICH]

the memory will only increase on the extension's end.

Can it be mitigated enough by converting some parts of the EFF HE rulesets into Bloom Filters? If I understand correctly, DDG rulesets are Bloom filter-based (so you can reuse the code already in the extension), but there are openness and legal issues with DDG rulesets. Openness is that we cannot just add/remove websites there on demand, that ruleset is not community-driven. Legal ones is that their ruleset is available under a non-free license, also it is NC, and it is very unclear if processing a text file with an automated tool would create a derived work (and SA feels like it is an intended effect).

[zoracon]

We use a bloom filter currently with DDG's Smarter Encryption rules. You can view the details here: https://github.com/EFForg/https-everywhere/blob/master/docs/adrs/bloom-filter-rule-signing.md.

Despite using a bloom filter for efficiency, the maintenance burden of crowd sourcing rulesets, still remains. We want to focus on HE core and provide the best experience, even though we are in the process of deprecation.