[HTTPS-Everywhere] tentative feature/architecture roadmap

[Sumana Harihareswara]

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