I should have mentioned that the UI step in #3 might also include, per Jeremy Nation's suggestion in https://github.com/EFForg/https-everywhere/issues/12606#issuecomment-330706469 , a design decision on whether and how to let the user enable/disable/reset signed rulesets.
On 01/09/2018 10:20 PM, Sumana Harihareswara wrote: > 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 https://changeset.nyc _______________________________________________ HTTPS-Everywhere mailing list [email protected] https://lists.eff.org/mailman/listinfo/https-everywhere
