[HTTPS-Everywhere] persistent user-generated rules

Mon Jan 13 06:31:07 PST 2014

I’m just throwing some ideas out there; I’m not in a position to implement
anything like this now:

2. Better way to upload rules

E-mail is (mostly) not secure in any sense. Other people can read it,
change it, and see who you are. It really seems like a bad thing, even
though we seem to be stuck with it.

With the POST idea, you would be using Tor if it’s available, right? On the
server side, you could do some basic validation on the rules when they are
submitted; wouldn’t that make it hard to use this system for spam
distribution or file storage? It would be nice if everyone could write and
everyone could read.

3. Decoupling rules

It seems like a no-brainer to me. Not just because of Adblock Plus, but
because it reminds me of separating style from content (eg CSS from HTML).
And you could argue that we’re almost at the point of having them decoupled
anyway.

To try to address the fingerprinting concerns, we could try to check the
rulesets against what others see. We could do, for rulesets, what people
already do for certificates:
- centralised approach: SSL Observatory
- distributed approach: Perspectives [1] – this should have a custom notary
list, of course

And all of this should also be done over Tor if it’s available.

[1] https://addons.mozilla.org/en-US/firefox/addon/perspectives/

--
Brian Drake

On Sun, Jan 12, 2014 at 2111 (UTC), Claudio Moretti
<flyingstar16 at gmail.com>wrote:

> 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
>
> _______________________________________________
> HTTPS-Everywhere mailing list
> HTTPS-Everywhere at lists.eff.org
> https://lists.eff.org/mailman/listinfo/https-everywhere
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.eff.org/pipermail/https-everywhere/attachments/20140113/c854091c/attachment-0001.html>