[HTTPS-Everywhere] persistent user-generated rules

Tue Jan 7 13:53:58 PST 2014

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 01/07/2014 01:29 PM, Claudio Moretti wrote:
> 
> 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 
> <mailto: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 
> <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).
> 

Yep, this is a likely scenario, which can be mitigated by giving the
user an email body text for copying-and-pasting if they don't want to
use the mailto: link.

> 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?
> 

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. :)

You'd have to make it very very clear to the user that they are
disclosing their IP address and what website they were visiting by
sending a rule to the server. I'd also recommend implementing some
data validation on the ruleset input (to prevent server code injection
and maybe XSS) and DOS protection.

> 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 <http://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 <http://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 <http://example.com> and example.org 
> <http://example.org>. I want source A to handle example.com 
> <http://example.com> and source B to handle example.org 
> <http://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 :)
> 

Thanks a lot for the input! Really appreciate all the help that HTTPS
Everywhere is getting. :)

I'd say that offering custom ruleset subscriptions to third-party
repositories is a longer-term goal than simply letting people add
their own persistent rules, so I'm not going to spend much time on it
for now. Having said that, design specs or prototypes with EFF's
privacy paranoia in mind are very, very welcome.

- -Yan

> 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.

- -- 
Yan Zhu                           yan at eff.org
Technologist                      Tel  +1 415 436 9333 x134
Electronic Frontier Foundation    Fax  +1 415 436 9993
-----BEGIN PGP SIGNATURE-----

iQEcBAEBCgAGBQJSzHdzAAoJENC7YDZD/dnsuNAH/13Suq2AVxoFgE0/KCZP+6WF
MzBUMlEso1ZfXRwvNzzl9r+li0W9slh9UNfQHs10fNAkglcRP7fxy7FZ0gy9FYOP
MUdN3efZ1x4bmQlWRYM5zwalf1QyBPuIedLFvODqH+yJOqj98cAf/gNppVCpbKsn
5avtmhTPItwQaPKuJTrpCmE+g9ZchS3nxeAYBcIjSPpfvTj3pi8oiHbsVkmX85mg
nhO7aHyi9E7UCLreTF7SBEXncRgFidFDMiOHVtCpMjElXQd6q+NtL5V87nMYgx0j
OhNKY1PION2V1BuDDYZgi/Yjpn1OAWKkwJOtgzYMS+5X3KOZAA2EbiKJZ8z5ae4=
=bzKd
-----END PGP SIGNATURE-----