[HTTPS-Everywhere] persistent user-generated rules

Claudio Moretti flyingstar16 at gmail.com
Sun Jan 12 13:11:50 PST 2014


Ok, I'll just quickly comment on a couple things and then I must confess
you lost me :P

On Sun, Jan 12, 2014 at 8:09 PM, Vijay P <vijayp at qwsrt.com> wrote:

> 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.
>
>
Well, about the Google thing, I'm inclined to believe the only answer well
be: no way. But that's my opinion, let's wait for an official one :P

The POST might be cool, but I believe (as Yan mentioned previously) it'll
bee too difficult to implement (at least without a volunteer that can set
it up). The git-in-js, on the other hand, will only be used on submit of a
new rule, no calls outside of that, and can be stripped to the two basic
functions we need (commit and push) and being all javascript can be pretty
easily audited. I think.



> 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.
>
>
Well, we (meaning somebody who actually know how to do it, i.e. not me)
should also audit the signature check functions. Again, we could use a JS
signature library, but the problems you mentioned in #2 arise again (and
may be actually worse, because we're talking about data validation, not a
simple send to a known server).

In any case, it's not my call to make :)

If anyone else wants to weigh in, you're welcome!

Cheers,

Claudio
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.eff.org/pipermail/https-everywhere/attachments/20140112/f3ffdec7/attachment.html>


More information about the HTTPS-Everywhere mailing list