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