<div dir="ltr">I’m just throwing some ideas out there; I’m not in a position to implement anything like this now:<br><div><div class="gmail_extra"><br></div><div class="gmail_extra">2. Better way to upload rules<br><br></div>
<div class="gmail_extra">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.<br></div><div class="gmail_extra">
<br></div><div class="gmail_extra">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.<br>
</div><div class="gmail_extra"><br></div><div class="gmail_extra">3. Decoupling rules<br></div><div class="gmail_extra"><br></div><div class="gmail_extra">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.<br>
</div><div class="gmail_extra"><br></div><div class="gmail_extra">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:<br>
- centralised approach: SSL Observatory<br>- distributed approach: Perspectives [1] – this should have a custom notary list, of course<br></div><div class="gmail_extra"><br></div><div class="gmail_extra">And all of this should also be done over Tor if it’s available.<br>
</div><div class="gmail_extra"><br>[1] <a href="https://addons.mozilla.org/en-US/firefox/addon/perspectives/">https://addons.mozilla.org/en-US/firefox/addon/perspectives/</a><br><br clear="all"><div><div dir="ltr"><div>--<br>
Brian Drake<br><br>All content created by me: <a href="http://www.wipo.int/treaties/en/ip/berne/trtdocs_wo001.html" target="_blank">Copyright</a> © 2014 Brian Drake. All rights reserved.<br></div></div></div>
<br><div class="gmail_quote">On Sun, Jan 12, 2014 at 2111 (UTC), Claudio Moretti <span dir="ltr"><<a href="mailto:flyingstar16@gmail.com" target="_blank">flyingstar16@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr"><div class="gmail_extra">Ok, I'll just quickly comment on a couple things and then I must confess you lost me :P<br></div><div class="gmail_extra"><br><div class="gmail_quote"><div class="im">On Sun, Jan 12, 2014 at 8:09 PM, Vijay P <span dir="ltr"><<a href="mailto:vijayp@qwsrt.com" target="_blank">vijayp@qwsrt.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">2. better way to upload rules<div>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. </div>
<div><br></div></div></blockquote><div><br></div></div><div>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<br><br>
</div>
<div>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.<br>
</div><div class="im"><div><br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div></div><div>3. Decoupling rules:</div><div>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. </div>
<br></div></blockquote><div><br></div></div><div>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).<br>
<br></div><div>In any case, it's not my call to make :)<br><br></div><div>If anyone else wants to weigh in, you're welcome!<br><br>Cheers,<br><br>Claudio<br></div></div></div></div>
<br>_______________________________________________<br>
HTTPS-Everywhere mailing list<br>
<a href="mailto:HTTPS-Everywhere@lists.eff.org">HTTPS-Everywhere@lists.eff.org</a><br>
<a href="https://lists.eff.org/mailman/listinfo/https-everywhere" target="_blank">https://lists.eff.org/mailman/listinfo/https-everywhere</a><br></blockquote></div><br></div></div></div>