Hey Yan and Vijay, just wanted to drop in on this:
On Tue, Jan 7, 2014 at 8:01 PM, Yan Zhu <[email protected]> wrote: > Regarding making it easier for people to add rules, what do you think about > putting a mailto:[email protected] 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.
_______________________________________________ HTTPS-Everywhere mailing list [email protected] https://lists.eff.org/mailman/listinfo/https-everywhere
