<div dir="ltr">Hey guys, sorry for the delay; last week was crazy.<div><br></div><div>I'll try to address lots of the stuff people have discussed here:</div><div><br></div><div>1. Parsing is slow</div><div>There are a number of things that could be causing firefox to be really slow. One possibility (which we ran into while building our extension for <a href="http://www.mitro.co">www.mitro.co</a>) is that add-ons developed using the add on sdk don't have JIT enabled. I'm not actually sure if the https-everywhere Firefox extension would be susceptible to this behaviour or not, but it's worth a look. We solved this issue by moving the processing into a webworker.<br>
</div><div><br></div><div><a href="http://stackoverflow.com/questions/17136245/why-is-javascript-slower-in-a-firefox-add-on-than-in-a-webpage-loaded-in-firefox">http://stackoverflow.com/questions/17136245/why-is-javascript-slower-in-a-firefox-add-on-than-in-a-webpage-loaded-in-firefox</a><br>
</div><div><br></div><div>2. better way to upload rules</div><div>I agree with Claudio that email is probably not a great way to do this. git-in-js is kind of cool, but personally, I think it makes sense to limit the number of third party dependencies in an extension that has full access to every page that 0.5+M people browse. I really like the idea of using a POST to a well-known server to upload these data. We would, of course, need to warn users about the potential of lack of anonymity before they upload anything. I would suggest running this on google app engine since it's relatively lightweight and will scale lightly, and probably won't cost much, but I'm not sure how the EFF feels about running stuff on Google's infrastructure. </div>
<div><br></div><div>3. Decoupling rules:</div><div>I think that we really should allow rules to be decoupled, much like adblock plus. The EFF could host various versions of the rules, digitally signed. The extension would, by default, use the stable set of rules, but people could opt into canary or even rules created by totally different people. This isn't too hard to do, if we serve JSON over HTTPS with some digital signature verification. </div>
<div><br></div><div>4. Code review comments regarding injecting STS.</div><div>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.</div>
<div><br></div><div>5. other code review comments.</div><div>I have fixed them and will send out an update shortly.</div><div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Jan 7, 2014 at 5:42 PM, Claudio Moretti <span dir="ltr"><<a href="mailto:flyingstar16@gmail.com" target="_blank">flyingstar16@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="im"><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jan 7, 2014 at 9:53 PM, Yan Zhu <span dir="ltr"><<a href="mailto:yan@eff.org" target="_blank">yan@eff.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div style="overflow:hidden">In theory this is a fine idea, but I'm not a sysadmin and EFF's tech<br>
ops team is already overloaded with work as is. Having said that, if<br>
you or another volunteer wants to set up a server to do this, I would<br>
have no objections. :)</div></blockquote></div><br></div><div class="gmail_extra"><br></div></div><div class="gmail_extra">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 (<i><a href="https://git.torproject.org/https-everywhere-rules.git" target="_blank">https://git.torproject.org/https-everywhere-rules.git</a></i> <i>?</i>) that goes with the the https-everywhere-rules mailing list.<br>
<br>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).<br>
<br>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".<br>
<br>This way, you don't actually have to worry about the server monitoring you (assuming <a href="http://git.torproject.org" target="_blank">git.torproject.org</a> doesn't store that many logs :P In any case, a warning is always good).<br>
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.<br><br></div><div class="gmail_extra">That's all!<br><br></div><div class="gmail_extra">
Best regards,<br></div><div class="gmail_extra"><br>Claudio<br></div></div>
</blockquote></div><br></div>