Thanks a lot for this list! Andrés Arrieta Electronic Frontier Foundation | Tech Projects Manager W: 415.436.9333 x123
On 15/01/18 12:15, Sumana Harihareswara via HTTPS-Everywhere wrote: > 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. >>
signature.asc
Description: OpenPGP digital signature
_______________________________________________ HTTPS-Everywhere mailing list [email protected] https://lists.eff.org/mailman/listinfo/https-everywhere
