<div dir="ltr"><br><div class="gmail_extra">Hey Yan and Vijay,<br><br>just wanted to drop in on this:<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jan 7, 2014 at 8:01 PM, Yan Zhu <span dir="ltr"><<a href="mailto:yan@eff.org" target="_blank">yan@eff.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Regarding
making it easier for people to add rules, what do you think about<br>
putting a mailto:<a href="mailto:https-everywhere-rules@lists.eff.org">https-everywhere-rules@lists.eff.org</a> button in<br>
popup.html that automatically generates a git patch-formatted email<br>
containing the new rule?<br>
<br></blockquote><div><br></div><div>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).<br>
<br></div><div>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?<br>
</div><div><br></div><div>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.<br>
<br></div><div>Once that is working<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
* Should we allow people to subscribe to external ruleset feeds? This<br>
is what AdblockPlus does. Probably yes, as you've suggested.<br></blockquote><div><br></div><div>Everyone could set up their own ruleset libraries; it's just a git repository, you can also use GitHub/Gitorious/YourOwnGitRepo.<br>
</div><div>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*)<br>
</div><div><br><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
* Do Firefox/Chrome both offer synchronization API's that perform<br>
signature verification? Probably not, so we'd have to write some code<br>
to do this. I would say that being able to sign ruleset updates and<br>
have clients verify them is a hard requirement for EFF.<br></blockquote><div><br></div><div>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.<br>
</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
* Would having a highly-customized ruleset subscription make users<br>
fingerprintable? Say that an advertising company registers<br>
[0-9a-z].<a href="http://ads.com" target="_blank">ads.com</a> and then sets itself up as a source for HTTPS<br>
Everywhere rules. Unknown to the users, each person who downloads an<br>
HTTPS Everywhere ruleset subscription from this source gets a<br>
different rule for *.<a href="http://ads.com" target="_blank">ads.com</a>. The ad company could then track users<br>
via essentially this method: <a href="http://www.unrest.ca/hsts-privacy-vs-security" target="_blank">http://www.unrest.ca/hsts-privacy-vs-security</a><br>
<br></blockquote><div><br></div><div>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.<br>
<br></div><div>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.<br>
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?<br><br></div>
<div>
Prioritizing is not an option: say I have two sources that both have rules for <a href="http://example.com">example.com</a> and <a href="http://example.org">example.org</a>. I want source A to handle <a href="http://example.com">example.com</a> and source B to handle <a href="http://example.org">example.org</a>. 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...<br>
</div><div> <br></div><div>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 :)<br></div><div><br></div><div>Cheers,<br>
<br>
Claudio<br></div><div><br>[1] <a href="https://github.com/creationix/js-git">https://github.com/creationix/js-git</a><br>[2] <a href="https://github.com/danlucraft/git.js">https://github.com/danlucraft/git.js</a> <br>[3] <a href="http://openpgpjs.org/">http://openpgpjs.org/</a><br>
<br></div><div>* I know somebody is thinking "(a) what about DNS/ARP poisoning? And if (b) somebody replaces the extension wit a malicious one?"<br></div><div>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.<br>
</div></div></div></div>