I've been reading past issues and asking Bill and Jeremy a few questions, and as I see it, this is a tentative roadmap for the next several steps for HTTPS Everywhere, in terms of major architectural changes.
As it is, as I see it, because Bill's just keeping his head above water keeping up with issue and pull request traffic, the project's making pretty slow progress on the features below. So these don't come with any particular schedule estimates. But the rough draft here might make clearer the *order* things would happen in: 1. Signed rulesets https://github.com/EFForg/https-everywhere/tree/sign-rulesets * Highest priority: allow EFF to sign rulesets (to allow downloading rulesets out of band with extension). Bill's task currently: restructure feature to make it comply with new APIs. * [Potential] Discuss how we decide which sites to include in the core ruleset. Some discussion: https://github.com/EFForg/https-everywhere/issues/12606 - This will probably be based on a mix of criteria including Alexa ranking and how sensitive the content is (e.g., software downloads, banking, news and sensitive content are more important). - This is an open question we need to answer to guide further decisions. 2. [Potential] Create dev channel for extension * Create a dev channel/beta channel so that testers can try new features before we release. Possibly we won't do this because merging features into this first, then having to merge again into master, would be more overhead than it's worth. 3. UI for update channel/signed rulesets * This might be rather time-consuming, because we need to design a way for the user to choose multiple sources of rulesets (perhaps calling them channels?). * A security audit performed by an external auditor would be particularly useful before we get well underway with this step. 4. More comprehensive testing * EFF recently had a contractor that built tests and got coveralls to do test coverage. Bill would review and get familiar with the system to see if we can improve, for instance, unit test coverage. 5. [Potential] Separating rulesets into their own repo I'm sure I'm getting some of this wrong and welcome corrections. But I figure having this all in one thread might make it easier to understand what the project's trying to prioritize. -- Sumana Harihareswara Changeset Consulting http://changeset.nyc _______________________________________________ HTTPS-Everywhere mailing list [email protected] https://lists.eff.org/mailman/listinfo/https-everywhere
