[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
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
More information about the HTTPS-Everywhere
mailing list