[HTTPS-Everywhere] persistent user-generated rules

[Vijay P]

Hey guys, sorry for the delay; last week was crazy.

I'll try to address lots of the stuff people have discussed here:

1. Parsing is slow
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
www.mitro.co) 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.

http://stackoverflow.com/questions/17136245/why-is-javascript-slower-in-a-firefox-add-on-than-in-a-webpage-loaded-in-firefox

2. better way to upload rules
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.

3. Decoupling rules:
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.

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.

5. other code review comments.
I have fixed them and will send out an update shortly.



On Tue, Jan 7, 2014 at 5:42 PM, Claudio Moretti <flyingstar16 at gmail.com>wrote:

>
> On Tue, Jan 7, 2014 at 9:53 PM, Yan Zhu <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
> <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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.eff.org/pipermail/https-everywhere/attachments/20140112/27023a35/attachment.html>