[HTTPS-E Rulesets] From Development to Stable

Drake, Brian brian at drakefamily.tk
Mon Jan 13 22:03:23 PST 2014


Collecting basic information about when rules are used should be no worse
than collecting basic information about when certificates are observed, via
the SSL Observatory.

If only a small number of users ever visit sites covered by a particular
ruleset, and a large proportion (but still a small number) of those users
disable the ruleset, can we detect this?

I’m still concerned about the other part of my message. Right now, it seems
that, to review a ruleset properly, there are at least four places that I
need to check:

1. Mailing list archives
2. trac.torproject.org bug tracker
3. Github bug tracker
4. Git (to find out the history of the ruleset, especially if I’m using a
stable release but want to account for ruleset changes in the development
branch)

If we want to move rules to the stable branch when they have been
sufficiently tested with no problems, we need to know whether they have had
problems.

--
Brian Drake

All content created by me:
Copyright<http://www.wipo.int/treaties/en/ip/berne/trtdocs_wo001.html>©
2014 Brian Drake. All rights reserved.

On Tue, Jan 14, 2014 at 0536 (UTC), Yan Zhu <yan at eff.org> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
>
>
> On 01/13/2014 09:18 PM, Drake, Brian wrote:
> > Maybe people could opt-in to … is this where we would say
> > “telemetry”? We could collect information about how much the rules
> > actually get used, as well as things like redirect loops, to try to
> > determine if a rule has been tested enough with no problems being
> > found.
>
> This is theoretically a good idea, except in practice there are some
> obstacles:
>
> 1. Stuff like automatically detecting when a page appears "broken" or
> even just Javascript redirects is really, really hard. People have
> tried using metrics like the Levenshtein distance between the DOM tree
> of the HTTP and HTTPS sites, but nothing so far really works.
>
> 2. Given that automatically detecting breakage is tricky, it seems
> that one of our best ways to figure out when something breaks is to
> see how often users disable certain rules. This is hopefully going to
> get merged soon (see other thread).
>
> 3. Info like "how often a rule gets used" is hard to collect safely,
> in the sense that collecting enough of it tends to inadvertently
> create the risk of deanonymizing users. EFF tries as hard as it can
> not to collect and store fingerprintable data on its servers. :)
>
> >
> > What we desperately need as well is an easy way to find any issues
> > already reported with a ruleset.
> >
> > For example, I when I was working on boohoo.com
> > <http://boohoo.com>, I found many rulesets in the development
> > branch (but not yet in stable) that were relevant, carefully
> > checked the rules in them, and found many issues [1]. But since I
> > am not familiar with any of those domains, I might have missed
> > something. Or I might have reported issues that were already known.
> > I have no idea.
> >
> > [1]
> >
> https://lists.eff.org/pipermail/https-everywhere-rules/2014-January/001792.html
> >
> >  -- Brian Drake
> >
> > All content created by me: Copyright
> > <http://www.wipo.int/treaties/en/ip/berne/trtdocs_wo001.html> ©
> > 2014 Brian Drake. All rights reserved.
> >
> > On Tue, Jan 14, 2014 at 0435 (UTC), Yan Zhu <yan at eff.org
> > <mailto:yan at eff.org>> wrote:
> >
> >
> >
> > On 01/13/2014 06:29 PM, Drake, Brian wrote:
> >> What is the process for moving a ruleset from the development
> >> branch to the stable branch?
> >
> > Thank you thank you thank you for asking that question. I opened a
> > ticket for this exact problem a few weeks ago:
> > https://trac.torproject.org/projects/tor/ticket/10310
> >
> > Right now, the answer is "when yan or peter thinks it's important
> > and probably been tested enough." I'll also merge something from
> > dev to stable if someone pokes me about it specifically (ex: in the
> > case of the stackexchange rule, since that was a blocker for Tor
> > launching their own stackexchange site).
> >
> > Anyway, whoever works on that ticket linked above gets my undying
> > love.
> >
> > -Yan
> >
> >
> >
>
> - --
> Yan Zhu                           yan at eff.org
> Technologist                      Tel  +1 415 436 9333 x134
> Electronic Frontier Foundation    Fax  +1 415 436 9993
> -----BEGIN PGP SIGNATURE-----
>
> iQEcBAEBCgAGBQJS1MzKAAoJENC7YDZD/dnsrVgIALQQwOl7I5H2zB4DzwT+X9Rq
> 3D5NhDK0217Bq9PWxV3tMCNNYQ4AG6BzXFHX9sugNi90s32xEtSmV4sVSJ0TLA7o
> 1JLJkZnmGo6UtXltZQpzIcV3Sd0NePqFigQuHH4nclAQ7QK4F9TuXdG3GsmUVbIZ
> 3MUcyd/YLoYqQv5N4yxSxU0SH1drDPTqPX62T9qhsOQvakMFogpTLysLfkI3SNd3
> CQC8qHGrDBSyzfiuiHrihc2eSjIDEBS2Hs0rx7L65/4GkCNcs9Q4XVRwCgeoieQd
> /gdECzjjMr5brXn0QWk9G3s7XRWYAn+bGMnERg2kAKnnhwO8aYtlvXSXBNyil9U=
> =YEuN
> -----END PGP SIGNATURE-----
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.eff.org/pipermail/https-everywhere-rules/attachments/20140114/c4f014ef/attachment-0001.html>


More information about the HTTPS-Everywhere-Rules mailing list