-----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 > <[email protected] <mailto:[email protected]>> wrote: > > > On Tue, Jan 7, 2014 at 9:53 PM, Yan Zhu <[email protected] > <mailto:[email protected]>> 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 [email protected] 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----- _______________________________________________ HTTPS-Everywhere mailing list [email protected] https://lists.eff.org/mailman/listinfo/https-everywhere
