Re: [privoxy-devel] privoxy, https-everywhere & freedombox

[Peter E. <pd...@ef...>]

Unless there are strong reasons to the contrary, I would urge any project
that wants to do well-informed HTTP -> HTTPS rewrites to use the HTTPS
Everywhere ruleset library.  Our open source community has poured a huge
amount of effort into building and maintaining it, and it would be silly to
duplicate or split that effort.  You can look at it here:

https://gitweb.torproject.org/https-everywhere.git/tree/HEAD:/src/chrome/content/rules


On Wed, Nov 21, 2012 at 03:31:04PM -0500, Boruch Baum wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Hello Peter and David.
> 
> On 11/18/2012 12:12 PM, David Schmidt wrote:
> > which two projects do you want to merge ruleset syntaxes for? 
> > FreedomBox+httpseverywhere? httpseverywhere+Privoxy? 
> > FreedomBox+Privoxy?  Or just what?
> httpseverywhere + Privoxy. The goals would be to:
> 1] give the most https rules for all users of either package;
> 2] reduce double-work of collecting new rules;
> 3] eliminate any need for end-users of one package to run a conversion
> script to import rules from the other package.
> 
> 
> > What proposals do you have for a common format?
> I haven't worked on any. My first idea was to canvas the developers of
> the two projects for your thoughts and willingness to go along with
> the notion. At issue might be more coordination of data-set updates
> between the projects than the coding and formatting.
> 
> Peter Eckersley of the httpseverywhere project pointed me to a perl
> script https://github.com/mikecardwell/perl-HTTPSEverywhere that
> already ports "HTTPS Everywhere to proxy-land".
> 
> On 11/15/2012 07:37 PM, Peter Eckersley wrote:
> > An issue to keep an eye on is that we have gradually added more and
> > more things to the ruleset XML format.  They're all documented at
> > https://www.eff.org/https-everywhere/rulesets. Failing to implement
> > all of them is probably not a disaster. Some of them may be
> > impossible to implementin a proxy without man-in-the-middling the
> > connection.  Downgrade rules are an example of that, and <exclusion
> > onpage=""> will be another if we ever implement it:
> > 
> > https://trac.torproject.org/projects/tor/ticket/6200
> > 
> > We could add a new platform type, "browser-internal" or "nonproxy",
> > to disable rulesets with those features within proxies.
> 
> 
> 
> - -- 
> hkp://keys.gnupg.net
> CA45 09B5 5351 7C11 A9D1  7286 0036 9E45 1595 8BC0
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.12 (GNU/Linux)
> 
> iQIcBAEBAgAGBQJQrToFAAoJEDvrUfDmCx9L6i0P/iDWYLQu5/UA2Sve0nseb8dz
> uN8O3+dpnfd2sDkh/UnFTBdZkXOntl77IvXd8ssAxkk5o2ThzCxyo9B/81+AEz18
> jDmk6Wrzay5LG4LVXQJq5apmISHepOoUiiOH3w078RgWGNK1KVDdRAgLMW8e4x8J
> M3yqf7tJ/4Za5CgBEsUiOKwcSKfLQu/RVolG+TNnILucbM83g0xbBGqwqav+COGA
> uHfZlbVHR2R1s9cGTIV8uUKlRCVBz9T0un7ksQYEOE5YqxDEH9ZrDIibFf8xSOUA
> iL8r6SIACRaD4Z+70fTC2L9YPCDK7oNGmVhRdJQohqglx7TYllBRxjaD/jhSvtbX
> WZF9fepx/5ToMIBLt5l7BPH81XYiIhruN3RE8ztBioDXOWLyausXp5JtjDZnR8SS
> YJ15BPwBRRwvfHihvhJk3RFRBxk2QvUR9F5dh5249pF1nYJ2N6md89RByI2QMz2x
> n/voOWjDVopxyMMlDgaxxwrqsW1lO+N4zS6OKKKQJJpHn39OIqwB+0yB/U+sJLlk
> YiQ9Gy7NejxXp44dZieeFKpyZUX9oGVEm7O+5WJkp4jQaRs2wxByqnBs8XtCjnCu
> cIuRgC8k9m62snFlgClSlp+fzQnUqJ7dZwygXiwIXQ65jeX4GfR709vjsQ+5WQGD
> 5freeR6BnR4L4OkPI0ti
> =Vg5T
> -----END PGP SIGNATURE-----

-- 
Peter Eckersley                            pd...@ef...
Technology Projects Director      Tel  +1 415 436 9333 x131
Electronic Frontier Foundation    Fax  +1 415 436 9993