[HTTPS-Everywhere] persistent user-generated rules

[Claudio Moretti]

On Fri, Jan 17, 2014 at 12:56 AM, Drake, Brian <brian at drakefamily.tk> wrote:

> 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.
>
> Relating e-mails and HTTP in terms of third parties sniffing the traffic
> still seems valid.
>

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

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.

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.

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


>
> 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...
>>
>
>  Luckily, we’re open about everything and allow users to change the rules
> themselves, so this probably shouldn’t be a priority for us.
>

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).
You can disable them very easiily, but you can't change how they work.

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

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.
>
[snip]

> Having said that, design specs or prototypes with EFF's
> privacy paranoia in mind are very, very welcome.
>

* Meaning that the technical knowledge level required to change a rule on
an already-installed HTTPS-E is too high for the regular user

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.
>
> 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.
>
> Anyway, like I said above, I can see why this shouldn’t be a priority for
> us.
>

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

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:

$ time sha1sum ./extensions/
> https-everywhere at eff.org/chrome/content/rules/default.rulesets
> 4ac2bdfd12b78ee7d0c3a846b27488544961a675  ./extensions/
> https-everywhere at eff.org/chrome/content/rules/default.rulesets
>
> real    0m0.081s
> user    0m0.020s
> sys    0m0.000s
>

There's a catch, though: you said that

To try to address the fingerprinting concerns, we could try to check the
> rulesets against what others see.


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.

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 eviladvertiser.com, 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:
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.
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*.org*) that is a
completely different website but was in the same ruleset source?

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?

Cheers,

Claudio

[1]
https://gitweb.torproject.org/https-everywhere.git/blob/HEAD:/src/chrome/content/rules/EFF.xml
[2]
https://gitweb.torproject.org/https-everywhere.git/tree/HEAD:/src/chrome/content/rules
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.eff.org/pipermail/https-everywhere/attachments/20140117/be8e59ad/attachment.html>