Allow subscription to external rule feeds

The ultimate direction we want to go is towards an adblock plus model, where people can subscribe to rule feeds that are relevant to them, maintained by third parties. This involves both altering our XML schema to include a 'rulefeed' envelope tag, and adding a bit of UI to add and manage subscription urls.

It also depends upon a few enhancements being completed first. These are in the child ticket list below:

added component::https everywhere/eff-https everywhere priority::high severity::normal status::new type::enhancement labels

Trac:
Status: new to accepted
Description: The ultimate direction we want to go is towards an adblock plus model, where people can subscribe to rule feeds that are relevant to them, maintained by third parties. This involves both altering our XML schema to include a 'rulefeed' envelope tag, and adding a bit of UI to add and manage subscription urls.

It also depends upon a few enhancements being completed first. These will be added as dependency tickets to this ticket.

to

The ultimate direction we want to go is towards an adblock plus model, where people can subscribe to rule feeds that are relevant to them, maintained by third parties. This involves both altering our XML schema to include a 'rulefeed' envelope tag, and adding a bit of UI to add and manage subscription urls.

It also depends upon a few enhancements being completed first. These are: TicketQuery(parent=#2161)
Owner: pde to mikeperry

Trac:
Description: The ultimate direction we want to go is towards an adblock plus model, where people can subscribe to rule feeds that are relevant to them, maintained by third parties. This involves both altering our XML schema to include a 'rulefeed' envelope tag, and adding a bit of UI to add and manage subscription urls.

It also depends upon a few enhancements being completed first. These are: TicketQuery(parent=#2161)

to

The ultimate direction we want to go is towards an adblock plus model, where people can subscribe to rule feeds that are relevant to them, maintained by third parties. This involves both altering our XML schema to include a 'rulefeed' envelope tag, and adding a bit of UI to add and manage subscription urls.

It also depends upon a few enhancements being completed first. These are in the child ticket list below:

This never got to be high on my priority list, because it seemed best to keep everyone's attention focused on keeping a single ruleset library as correct as possible, rather than letting them fragment into multiple libraries. But I'm starting to wonder whether we might want this simply to decrease the amount of time between a ruleset being fixed, and users receiving the fixes in their browsers. It still takes at least a month before 80% of users upgrade to a new stable release, and there's an additional lag of 2-4 weeks between stable releases, so it often takes months for users to receive trivial ruleset bugfixes.

There would be some tricky questions about doing auto-polled ruleset libraries though. Would we require that they be signed by the offline signing key, for instance?

Trac:
Points: N/A to N/A
Actualpoints: N/A to N/A

Recently there has been some interest and discussion in this feature on the tor-talk mailing list: Using HTTPS Everywhere to redirect to .onion

Trac:
Cc: N/A to adrelanos@riseup.net

Bumping this in priority since there's been multiple requests for decoupling the update mechanisms for the extension and the ruleset. I am more strongly in favor of EFF shipping frequent ruleset updates (ex: every week) rather than allowing third parties to ship updates, since a malicious ruleset can totally pwn one's browser. My implementation proposal is here: https://lists.eff.org/pipermail/https-everywhere/2014-March/001997.html

This would be a good GSoC project.

Trac:
Priority: normal to major

Trac:
Username: reubot
Cc: adrelanos@riseup.net to adrelanos@riseup.net, reuben_p@yahoo.com

Set all open tickets without a severity to "Normal"

Trac:
Severity: N/A to Normal

Trac:
Owner: mikeperry to N/A
Status: accepted to assigned
Cc: adrelanos@riseup.net, reuben_p@yahoo.com to adrelanos@riseup.net, reuben_p@yahoo.com, mikeperry

Change tickets that are assigned to nobody to "new".

Trac:
Status: assigned to new

mentioned in issue #4969 (moved)

mentioned in issue #9868 (moved)

moved to tpo/applications/https-everywhere-eff#2161 (closed)