[HTTPS-Everywhere] tentative feature/architecture roadmap

Sumana Harihareswara sh at changeset.nyc
Tue Jan 9 19:20:04 PST 2018

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

* 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

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

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

More information about the HTTPS-Everywhere mailing list