<div dir="ltr">I love the ideas!<div><br></div><div>Automatically disabling broken rules could really improve the user experience -- and adding some TravisCI hooks to pull-requests would be great.</div><div><br></div><div>
Two thoughts</div><div>- How would we go about automatically disabling rules? </div><div>Should we have some protected class of "super stable" rules (e.g. Twitter's SSL shouldn't be disabled if there's a transient curl test failure.)</div>
<div><br></div><div>- I like Maxim's idea of UI feedback from users.</div><div>Is there a clever way to have clients detect or optionally report failures?</div><div>On Chrome, we can easily detect 4XX/5XX after HTTPS Everywhere redirects (using webRequest.onCompleted). Maybe we should have a UI feature to report an error if some percentage of redirects results in errors?</div>
<div><br></div><div><br></div><div><div><br></div><div>Best,</div><div>Nick</div><div class="gmail_extra">
<br><br><div class="gmail_quote">On Mon, Aug 18, 2014 at 5:58 AM, Maxim Nazarenko <span dir="ltr"><<a href="mailto:nz.phone@mail.ru" target="_blank">nz.phone@mail.ru</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><div><div><div><div>I second the idea. Some points IMHO worth considering.<br><br></div>1) Perhaps test cases should include both http and httpS urls, so we can make reasonably sure that the page stays the same? At least we would know if unsecure request fails.<br>
</div>2) Should the test cases be stripped before shipping the ruleset? I think yes.<br></div>3) Perhaps the UI should expose a way to contact the maintainers for the rules triggered for the current page, so an end user can quickly report broken rules.<br>
<br></div>Best regards,<br></div>Maxim Nazarenko<br></div><div><div><div class="gmail_extra"><br><br><div class="gmail_quote">On 13 August 2014 18:32, Jacob S Hoffman-Andrews <span dir="ltr"><<a href="mailto:jsha@eff.org" target="_blank">jsha@eff.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi all,<br>
<br>
As HTTPS Everywhere encompasses more sites, we're having trouble validating and maintaining rulesets in a scalable way. I'd like to propose two small changes that should help keep things running smoothly: Every ruleset should have a maintainer, and every ruleset should have a set of test URLs.<br>
<br>
The maintainer requirement is pretty straightforward. We would probably specify it on the top-level ruleset node, e.g.:<br>
<br>
<ruleset name="Twitter" maintainer="<a href="mailto:jsha@eff.org" target="_blank">jsha@eff.org</a> (Jacob Hoffman-Andrews)"><br>
<br>
For the test URLs, we would like at least one URL that exercises each rewriting rule, so it makes sense to hang test URLs off of the rule tag:<br>
<br>
(old)<br>
<rule from="^http://(?:www\.)?t\.co/<u></u>"<br>
to="<a href="https://t.co/" target="_blank">https://t.co/</a>" /><br>
<br>
(new)<br>
<rule from="^http://(?:www\.)?t\.co/<u></u>"<br>
to="<a href="https://t.co/" target="_blank">https://t.co/</a>"><br>
<test href="<a href="https://t.co/kU0aUmcm4u" target="_blank">https://t.co/kU0aUmcm4u</a>" /><br>
<test href="<a href="https://www.t.co/kU0aUmcm4u" target="_blank">https://www.t.co/<u></u>kU0aUmcm4u</a>" /><br>
</rule><br>
<br>
Maintainers would be responsible for choosing the right number of tests to get adequate coverage when a pattern covers multiple hosts, but there would be a test-enforced minimum of two URLs per rule. In the case of bare domain rewrites, the test URLs should cover both '/' and some page other than the root.<br>
<br>
To test these URLs, we would first fetch all of them with curl. Any URLs that return 4xx or 5xx would be marked as ignored for that run. A special maintainer mode would flag for replacement all URLs that return 4xx or 5xx.<br>
<br>
After filtering out failing URLs, we'd load up a headless Firefox instance with the extension (see starting Travis config at <a href="https://github.com/EFForg/https-everywhere/pull/421" target="_blank">https://github.com/EFForg/<u></u>https-everywhere/pull/421</a>), and load each test URL in turn. We would validate that the rewrite rule actually gets triggered, that the page context gets a 200 response, and that not more than 3 subresources caused one of: (mixed content blocking, 4xx, 5xx).<br>
<br>
We'd run ruleset validation for all URLs daily or weekly, and any changes to a given ruleset would automatically trigger validation for that ruleset.<br>
<br>
When a ruleset fails during the daily/weekly check, we'd disable it - either manually or automatically - until someone has time to fix it.<br>
<br>
What do you think?<br>
<br>
Thanks,<br>
Jacob<br>
______________________________<u></u>_________________<br>
HTTPS-Everywhere mailing list<br>
<a href="mailto:HTTPS-Everywhere@lists.eff.org" target="_blank">HTTPS-Everywhere@lists.eff.org</a><br>
<a href="https://lists.eff.org/mailman/listinfo/https-everywhere" target="_blank">https://lists.eff.org/mailman/<u></u>listinfo/https-everywhere</a><br>
</blockquote></div><br></div>
</div></div><br>_______________________________________________<br>
HTTPS-Everywhere mailing list<br>
<a href="mailto:HTTPS-Everywhere@lists.eff.org" target="_blank">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><br clear="all"><div><br></div>-- <br>Nick Semenkovich<br>
Laboratory of Dr. Jeffrey I. Gordon<br>Medical Scientist Training Program<br>School of Medicine<br>Washington University in St. Louis<br><a href="https://nick.semenkovich.com/" target="_blank">https://nick.semenkovich.com/</a>
</div></div></div>