[HTTPS-E Rulesets] Anyone have time to review and edit this nice batch of rulesets?

[Peter Eckersley]

Is anyone interested in taking a cleanup and editorial pass on the large batch
of rulesets in Vic Garin's remote?  Many of them were generated by HTTPS
Finder -- there are definitely some great rulesets in there (eg, Google
Earth), as well as few that shouldn't be committed, and a few that should be
committed after being combined or edited.

(The best method for doing this is to merge Vic's remote into your own repo,
edit them there, and then push to your own remote)

On Thu, Nov 10, 2011 at 04:20:58PM -0800, Victor Garin wrote:
> I cannot go through them again...I already spent around 4 hours going
> through each rule and removing the HTTPS Finder's credits and then putting
> them on the GIT....
> 
> https://github.com/vicgarin/vicHTTPS
> 
> or
> 
> git://github.com/vicgarin/vicHTTPS.git
> 
> On Thu, Nov 10, 2011 at 11:40 AM, Peter Eckersley <pde at eff.org> wrote:
> 
> > On Thu, Nov 10, 2011 at 11:10:53AM -0800, Victor Garin wrote:
> > > I noticed the Git started getting new rules.
> > >
> > > Any updates on merging my rulesets.
> > >
> > > I spent alot of time putting them in the GIT.
> >
> > Yes we're just looking at them now.  There are some that look like they
> > were
> > generated by HTTPS Finder and will need more human attention.  For
> > instance:
> >
> > - there's a rulset for www8.garmin.com and a separate ruleset for
> >  www.garmin.com.  Shouldn't those be in the same file?
> >
> > - there are separate rulesets for h20386.www2.hp.com and shopping1.hp.com.
> >  Do
> >  we have any confidence that rewriting those two domains won't break
> >  functionality on parts of the HP site? (remember that Referer headers
> > will be
> >  blocked by the rewrite, and the example of https://www.hp.com is not
> >  confidence-inspiring)
> >
> > - There are also other smaller things like an "about.telus.com" ruleset
> > that
> >  rewrites www.about.telus.com (which is a non-existent subdomain)
> >
> > If you're able to take an extra pass over the rulesets to make sure they're
> > all basically tested and sensible, we should be able to merge the results.
> >
> > --
> > Peter Eckersley                            pde at eff.org
> > Technology Projects Director      Tel  +1 415 436 9333 x131
> > Electronic Frontier Foundation    Fax  +1 415 436 9993
> >

-- 
Peter Eckersley                            pde at eff.org
Technology Projects Director      Tel  +1 415 436 9333 x131
Electronic Frontier Foundation    Fax  +1 415 436 9993