[HTTPS-Everywhere] Hundreds of rulesets will need to be marked platform="mixedcontent" to disable them for Chromium users

Dan Auerbach dan at eff.org
Thu Sep 27 12:09:36 PDT 2012


On 09/26/2012 12:16 PM, Peter Eckersley wrote:
> Yes, we've been thinking about this both for Chromium and for the quality of
> the rulesets in general.  Ondrej's code
> (https://github.com/hiviah/https-everywhere-checker) will take a bit more work
> before it can be used to properly test the whole library, but that's worth
> attempting.  There are some extra problems that would apply to mixed content
> detection, though:
>
>  - Not all mixed content causes a page to break or render incorrectly (eg,
>    blocking an HTTP ad, analytics script or tracking beacon is non-fatal)
>  - Ondrej's code will fetch URLs.  We would then have to parse them to see the
>    URLs of all embedded stuff (doable) and then ideally execute the JavaScript
>    to see if there are any further embeds (less doable).
As long as the user experience is still good, we shouldn't disable the
rule, right? I'd rather block an ad by default and give someone a full
HTTPS experience. I'd argue that only when the user experience is
significantly worse should we disable the rule, as is the case for
nytimes.com
>
> Two other options are to use something like selenium for Chrome (if such a
> thing exists)
Yes, this does exist AFAICT:
https://code.google.com/p/selenium/wiki/ChromeDriver

However, for identifying the mixed content pages, I think we could go a
long way with crowd sourcing.


>  or try to detect the mixed content states from within our
> extension code, and give users a way to keep and send us logs of them, if they
> wish to.
>
> On Tue, Sep 25, 2012 at 08:41:22PM -0500, Jay Weisskopf wrote:
>> Didn't someone create a ruleset test framework a few months back? Could
>> that be adapted to generate a list of "mixedcontent" sites?
>>
>> - Jay

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.eff.org/pipermail/https-everywhere/attachments/20120927/20b5c5ff/attachment.html>


More information about the HTTPS-everywhere mailing list