[HTTPS-Everywhere] tentative feature/architecture roadmap

[Andrés Arrieta]

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.
>>


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <https://lists.eff.org/pipermail/https-everywhere/attachments/20180116/688a4c4d/attachment.sig>