[HTTPS-Everywhere] persistent user-generated rules

[Claudio Moretti]

Hey Yan and Vijay,

just wanted to drop in on this:

On Tue, Jan 7, 2014 at 8:01 PM, Yan Zhu <yan at eff.org> wrote:

> Regarding making it easier for people to add rules, what do you think about
> putting a mailto:https-everywhere-rules at lists.eff.org button in
> popup.html that automatically generates a git patch-formatted email
> containing the new rule?
>
>
IMHO it may cause some problems, especially with people that don't have
anything set up to handle mailto: links (like me); what would happen is
that the default email client would pop up and most people don't have that
set up (aka it'll start Outlook Express and friends).

How about a "custom" sending function? a POST to a specific server that
stores the rule for review or (better, but don't know if it's doable from
the browser) a push in a dedicated git repo that only contains rules and
that can be merged with the "main" rules repo once the rules have been
reviewed?

Imagine the following: HTTPS-E with an integrated git library (there are
javascript clones that may be used like [1] and [2] - didn't test, just
googled them); with a git repo containing rulesets, HTTPS-E would be able
to pull updates from the repo, with all the benefits of compression and
diffs that git has.

Once that is working


>
> * Should we allow people to subscribe to external ruleset feeds? This
> is what AdblockPlus does. Probably yes, as you've suggested.
>

Everyone could set up their own ruleset libraries; it's just a git
repository, you can also use GitHub/Gitorious/YourOwnGitRepo.
With a signature file in it that can be verified (Open PGP JS [3]?) against
a public key distributed with the extension (or available in a location
hardcoded into the extension, just to be sure nobody can fake the official
repo*)




> * Do Firefox/Chrome both offer synchronization API's that perform
> signature verification? Probably not, so we'd have to write some code
> to do this. I would say that being able to sign ruleset updates and
> have clients verify them is a hard requirement for EFF.
>

At least for EFF (see above). Then if somebody else wants to add their own
public key, that can be arranged (config file/DB) but IMHO the EFF key
should always be hardcoded (even if it's not a best practice) for security
purposes.


>
> * Would having a highly-customized ruleset subscription make users
> fingerprintable? Say that an advertising company registers
> [0-9a-z].ads.com and then sets itself up as a source for HTTPS
> Everywhere rules. Unknown to the users, each person who downloads an
> HTTPS Everywhere ruleset subscription from this source gets a
> different rule for *.ads.com. The ad company could then track users
> via essentially this method: http://www.unrest.ca/hsts-privacy-vs-security
>
>
This, though, goes down to "do you trust the source of this ruleset"? We
could put up a big, red banner saying "WARNING! Unless you're sure of what
you're doing, don't add an external source for rules!". Or restrict that
option to developers, with the big red banner: checkbox that says "enable
advanced features" and when one clicks it, the banner pops up.

External rulesets also pose the problem of conflicting rules, circular
rules, unverified mixed content and, most of all (because it happened in
HTTPS-E trunk sometimes, so it _will_ happen pretty much every time in
external sources) incorrectly written rules.
It can be avoided by launching the ruleset validation routine every time a
new source is added or a new version pulled, but even if that is possible,
the question becomes: how do you handle duplicate rules?

Prioritizing is not an option: say I have two sources that both have rules
for example.com and example.org. I want source A to handle example.com and
source B to handle example.org. Prioritizing the single rule is hell (my
/src/chrome/content/rules contains 10397 files at the moment), prioritizing
the entire source is impossible due to my sloppy example up here...

In any case, please feel free to ignore me if I have misunderstood the
point; I'm just trying to offer my (somewhat longer than I though) opinion
:)

Cheers,

Claudio

[1] https://github.com/creationix/js-git
[2] https://github.com/danlucraft/git.js
[3] http://openpgpjs.org/

* I know somebody is thinking "(a) what about DNS/ARP poisoning? And if (b)
somebody replaces the extension wit a malicious one?"
Regarding (a) if your PC is compromised, HTTPS-E is the least of your
problems, whereas about (b) it doesn't matter: if the extension itself is
compromised, it doesn't actually matter _where_ it has been compromised.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.eff.org/pipermail/https-everywhere/attachments/20140107/5eaf78cf/attachment.html>