<div dir="ltr"><br><div class="gmail_extra"><div class="gmail_quote">On Fri, Jan 17, 2014 at 12:56 AM, Drake, Brian <span dir="ltr"><<a href="mailto:brian@drakefamily.tk" target="_blank">brian@drakefamily.tk</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"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div></div><div>Are you aware that you’re disclosing your e-mail address? Probably, though not necessarily. What about other information? [1] Perhaps I’m being unreasonably picky here.<br>
<br></div><div>Relating e-mails and HTTP in terms of third parties sniffing the traffic still seems valid.<br></div></div></div></div></blockquote><div><br></div><div>Uhm, maybe I'm thinking too technical, but how can you not be aware you're disclosing your email address when you send an email?<br>
I believe that when you send an email to someone, you know they are going to see your email address, otherwise how would they be able to reply?<br><br></div><div>I agree with you that sniffing is still possible, what I'm saying is that it doesn't matter in this case, because your email (the full email, not just the address) is going to be put on a public mailing list. You are voluntarily sending data, so even if someone's sniffing they'll only see what you are making public.<br>
<br></div><div>If you're afraid you are targeted and you don't want to disclose anything sensitive about you, you are not going to send an email to a public mailing list.<br><br></div><div>The difference, for me, is in that: you can choose not to send emails, you can't choose what a web server is keeping from your visit<br>
</div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div></div><div class="im">
<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>
The problem here is privacy concerns: how could we guarantee that the third party respects EFF rules regarding privacy matters? It's a really complicated topic...</div></div></div></div></blockquote><div><br></div></div>
<div>
Luckily, we’re open about everything and allow users to change the rules themselves, so this probably shouldn’t be a priority for us.<br></div></div></div></div></blockquote><div><br></div><div>Actually.. No*. There is no easy way to change rulesets, unless you are compiling the extension yourself (which is something that almost only developers do).<br>
</div><div>You can disable them very easiily, but you can't change how they work.<br><br></div><div>Also, the rulesets have nothing to do with this: I was talking about the server performing the check and its setup. quoting Yan (which was talking about something else, but this applies<br>
<br><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote">Having said that, if<br>
you or another volunteer wants to set up a server to do this, I would<br>
have no objections. :)<br>
<br>
You'd have to make it very very clear to the user that they are<br>
disclosing their IP address and what website they were visiting by</blockquote><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote">sending a rule to the server.<br>
</blockquote><div>[snip]<br><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote">Having said that, design specs or prototypes with EFF's<br>
privacy paranoia in mind are very, very welcome.<br></blockquote></div><br></div><div>* Meaning that the technical knowledge level required to change a rule on an already-installed HTTPS-E is too high for the regular user<br>
<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div></div><div>It seems very unlikely that users would choose 10000+ ruleset sources, though. I imagined a much smaller number of ruleset sources (each of which provides a single piece of data containing many rulesets), each of which was verified using a hash.<br>
</div><div><br></div><div>If an update to a ruleset source is so recent that it’s too hard to verify that hash against others’ observations, then keep using an old version until more observations become available.<br></div>
<div><br></div><div>Anyway, like I said above, I can see why this shouldn’t be a priority for us.<br></div></div></div></div></blockquote><div><br></div><div>Oh, sorry, my mistake: I believed we were talking about rulesets, not ruleset sources. (ruleset, for me, is the single XML file, like [1], which begins with <ruleset name=[etc...]>)<br>
<br></div><div>If we're talking single rulesets, there are 10000+, but ruleset sources can be checked using the hash of the "default.rulesets" which, on my computer, takes about 0.1s to compute:<br><br><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote">
$ time sha1sum ./extensions/<a href="http://https-everywhere@eff.org/chrome/content/rules/default.rulesets">https-everywhere@eff.org/chrome/content/rules/default.rulesets</a><br>4ac2bdfd12b78ee7d0c3a846b27488544961a675 ./extensions/<a href="http://https-everywhere@eff.org/chrome/content/rules/default.rulesets">https-everywhere@eff.org/chrome/content/rules/default.rulesets</a><br>
<br>real 0m0.081s<br>user 0m0.020s<br>sys 0m0.000s<br></blockquote><div><br></div><div>There's a catch, though: you said that <br><br><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote">
To try to address the fingerprinting concerns, we could try to check the rulesets against what others see.</blockquote><div><br></div><div>The problem here is that you can't check the "default.rulesets" against one provided by other sources, because EFF puts 10000+ rulesets in the extension, but a company might be interested in putting in their source only 10 or 15, giving you mismatching hashes.<br>
<br></div><div>You could check it against someone with the same source, but how do you know the problem is in the ruleset you're currently using? Say you're visiting <a href="http://eviladvertiser.com">eviladvertiser.com</a>, and I have the same source as you; if we check our default.rulesets hashes against each other, there are several scenarios that can happen; the two that interest me are:<br>
</div><div>1) One of us has a different version of the source: what happens? how do you check versions? It's not a good idea to also send that out, makes you more vulnerable to fingerprinting.<br></div><div>2) Since default.rulesets is a collection of multiple rulesets, all with different targets, how do you know that the hash mismatch wasn't triggered by a completely different ruleset (say, aviladvertiser<b>.org</b>) that is a completely different website but was in the same ruleset source?<br>
<br></div><div>The only way to do this check properly is to check individual rulesets according to targets and which rule was hit, but if you do that you go back to the original problem: how do you handle checking 10000+ different rulesets[2] without impacting performances?<br>
<br></div><div>Cheers,<br><br>Claudio<br></div></div></div><div> <br>[1] <a href="https://gitweb.torproject.org/https-everywhere.git/blob/HEAD:/src/chrome/content/rules/EFF.xml">https://gitweb.torproject.org/https-everywhere.git/blob/HEAD:/src/chrome/content/rules/EFF.xml</a><br>
[2] <a href="https://gitweb.torproject.org/https-everywhere.git/tree/HEAD:/src/chrome/content/rules">https://gitweb.torproject.org/https-everywhere.git/tree/HEAD:/src/chrome/content/rules</a><br></div></div></div></div>