[HTTPS-Everywhere] persistent user-generated rules

[Yan Zhu]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Hey! Thanks for getting back on this. I'm on travel next week and
might be slow to respond/merge stuff, but it'll happen! :)

One quick comment:

> 4. Code review comments regarding injecting STS. Chrome doesn't
> have an API to edit STS records. We could inject STS headers but
> this would be dangerous, since without a way to remove such 
> directives, sites that stop working with https would be broken
> forever.
> 

I mentioned this on Github, but you can nullify STS directives by
injecting a STS header with max-age=0 into the response. Note that
this doesn't actually remove the original STS directive from the
database (at least not in Firefox).

- -Yan

> 
> 
> On Tue, Jan 7, 2014 at 5:42 PM, Claudio Moretti
> <flyingstar16 at gmail.com <mailto:flyingstar16 at gmail.com>> wrote:
> 
> 
> On Tue, Jan 7, 2014 at 9:53 PM, Yan Zhu <yan at eff.org 
> <mailto:yan at eff.org>> wrote:
> 
> In theory this is a fine idea, but I'm not a sysadmin and EFF's
> tech ops team is already overloaded with work as is. Having said
> that, if you or another volunteer wants to set up a server to do
> this, I would have no objections. :)
> 
> 
> 
> Well, technically, if the javascript-git-in-the-extension idea is 
> acceptable, you don't need a server: all is needed is a new git 
> repository on a pre-existing server 
> (/https://git.torproject.org/https-everywhere-rules.git/ /?/) that 
> goes with the the https-everywhere-rules mailing list.
> 
> It should be "write only", of course, meaning that everybody can 
> write to is but only a few chosen ruleset reviewers can read from
> it (otherwise, you'll find your repository being used as a spam 
> distribution point / file storage website in a couple hours or
> less).
> 
> The reviewers can then easily review commits (via authenticated 
> GitWeb or by manually pulling the repo) and replace the "take the 
> attachment, review it, put it in the folder, commit" procedure
> with a "git merge".
> 
> This way, you don't actually have to worry about the server 
> monitoring you (assuming git.torproject.org 
> <http://git.torproject.org> doesn't store that many logs :P In any 
> case, a warning is always good). As for the server protection, I
> can't speak for D[d]oS prevention, but git+write only repo should
> be safe against server code injection and XSS.
> 
> That's all!
> 
> Best regards,
> 
> Claudio
> 
> 

- -- 
Yan Zhu                           yan at eff.org
Technologist                      Tel  +1 415 436 9333 x134
Electronic Frontier Foundation    Fax  +1 415 436 9993
-----BEGIN PGP SIGNATURE-----

iQEcBAEBCgAGBQJS0viSAAoJENC7YDZD/dnsqwAH/2lr0iLS1cuDo+CPU8j8RZba
J2xphEIqgqGzO9vPGxCa/VVRUUJkUswaC9IY7U4fhzR2AZGyJLPbdoM7Eg7X1ffw
RYTrHcrHRkCAQOEPEWDMIQu1PtelS9xak8oL3jVq6PdUNzcIyzueC9nUJoSWcRgN
/si2Vg8fQXPfw8k59lRcst/HYln0LaQR/pJqO8dDOy6dVT40qZDO53GDQ9xCrCEP
vZovRBu7T5PB+hCkuUm4Njgki8MUED/aUFh2bmERyJDL1s7FGNxVlwwdomze5Ir0
FRh4tRsZUbVdAuIpGZIHAteGUCeTJx8ikpmUV5ZpY4NXvfr7uXsVFZ/TxSEUWak=
=xRxt
-----END PGP SIGNATURE-----