Option to turn mixedcontent rulesets on

[Bisaloo]

How can we turn all mixedcontent rulesets on at once with the WebExtensions HTTPS-Everywhere?

The following command doesn't seem to work anymore:

extensions.https_everywhere.enable_mixed_rulesets;true

Related: #9958

[jeremyn]

@Bisaloo WebExtensions add-ons shouldn't count on having access to about:config, see https://wiki.mozilla.org/WebExtensions/FAQ#Will_I_have_access_to_about:config_or_the_preferences.3F . So it makes sense that HTTPS Everywhere isn't doing anything with that setting.

[ivysrono]

#8506 enable mixedcontent on all platform by default.

[Bisaloo]

@ivysrono, that's not really the purpose of this issue. It is a great find and helps a lot with mixedcontent issue but it doesn't turn on HTTPS-Everywhere platform="mixedcontent" rulesets.

[jeremyn]

A more general version of this issue is a way to turn on any combination of platforms, not just mixedcontent, using a checklist.

[Hainish]

A lot of the rules that have been marked as platform="mixedcontent" were broken when the browsers first introduced MCB. I suspect many sites have fixed their mixed content problems in response to MCB being the default behavior now, but these rulesets should be manually checked rather than blanket-enabled, or else we risk blocking access to site resources. Currently there are ~1325 such rulesets:

user@https-everywhere ~/workspace/https-everywhere/rules (webextensions) $ git grep "mixedcontent" | wc -l
1325

I suspect that our tagging of these rules as mixedcontent is old enough that these rules should probably be reviewed anyway. In https://github.com/EFForg/https-everywhere/blob/master/CONTRIBUTING.md#general-info, I've made a note for those interested in contributing to prioritize the mixedcontent rules.

[jeremyn]

@Hainish I think this issue is to add the option to enable all the mixedcontent rules, not that we should enable them all by default.

[Hainish]

We could add an option to localStorage, as I note in this comment: https://trac.torproject.org/projects/tor/ticket/21323#comment:15

The platform="mixedcontent" attribute was always intended as a short-term solution, see https://bugzilla.mozilla.org/show_bug.cgi?id=878890#c20. I'm inclined to deprecate turning on mixed-content issues by default, since all browsers that we support are blocking mixed content or in the process of turning MCB on. Is there a practical benefit to enabling them all by default rather than ensuring we remove the mixedcontent flag from rulesets that still have it, if they aren't breaking?

[Bisaloo]

Is there a practical benefit to enabling them all by default rather than ensuring we remove the mixedcontent flag from rulesets that still have it, if they aren't breaking?

IMO, yes. I prefer enabling mixedcontent ruleset even if they trigger MCB.

I used to get over the broken parts here and there due to MCB and now, I don't even notice it because I am using the upgrade-insecure-content CSP.

I totally agree we should audit platform="mixedcontent" rulesets and see if we can turn them on by default for all users but I like having the option to turn them on even the ones that actually cause MCB.

[jeremyn]

This "implement a settings page" (in WebExtensions) mini-tutorial looks highly relevant. It uses the storage API, which it says is like localStorage but has advantages such as persisting even if the user clears their data. We should also make sure this setting persists in private browsing mode.

I don't personally enable mixedcontent rules by platform but we should see this feature as allowing users to enable any platform, not just mixedcontent, like I said in a previous comment. The compelling use case is to allow users in China to enable regional/China platform rulesets all at once.

[Hainish]

@jeremyn we're using the storage API for all persistence within WebExtensions currently. I was using localStorage as a synonym, which isn't strictly correct. The specific storage engine is either sync or local, depending on what is available.

For mixedcontent, my suspicion that problematic sites have fixed their issues when they saw their sites were broken, once the browsers started implementing MCB. Putting this to the test on a random sampling:

user@https-everywhere ~/workspace/https-everywhere/rules (webextensions) $ git grep -i mixedcontent | shuf | head -n 10 | cut -d":" -f1
Oversee.xml
AEUP.eu.xml
Docelu.pl-problematic.xml
DC_Power.eu.xml
MIMS.xml
DjurRattsAlliansen.se.xml
Roccat.org.xml
zongheng.com.xml
hitfile.net.xml
Poppy-Sports.xml

I get the following results:

Oversee.xml - automatically forwards to HTTPS
AEUP.eu.xml - no content shown on HTTP, invalid certificate on HTTPS (using old cipher)
Docelu.pl-problematic.xml - HTTPS endpoint does not exist
DC_Power.eu.xml - automatically forwards to HTTPS
MIMS.xml - no difference between HTTP and HTTPS (no mixed content)
DjurRattsAlliansen.se.xml - HTTPS endpoint does not exist
Roccat.org.xml - downgrades you to HTTP
zongheng.com.xml - HTTPS endpoint does not exist
hitfile.net.xml - no difference between HTTP and HTTPS (no mixed content)
Poppy-Sports.xml - invalid certificate on HTTPS (common name mismatch)

There are a lot of issues in this random sampling, but notably none of them are due to mixed content. Note that the rules that had certificate errors or no HTTPS are currently broken in the Tor Browser, for instance. To fix this and get rid of the mixedcontent flag altogether, we should

1. Gather a list of all the mixedcontent rules
2. Remove the mixedcontent flag from them, and
3. Disable all of those rules that break, using our fetch tester.

[jeremyn]

@Hainish Another angle is: here is a list of recent commits with platform="mixedcontent". The most recent one was 4 days ago. Active MCB still breaks sites in the wild so we can't assume that a mixedcontent warning is outdated. I would probably rather delete any given mixedcontent ruleset than enable it, if I had to choose.

[Bisaloo]

For mixedcontent, my suspicion that problematic sites have fixed their issues when they saw their sites were broken, once the browsers started implementing MCB.

I disagree here. I think websites that had a previously fully working https configuration and that saw their website break when MCB was first introduced indeed fix these issues.

But many websites, probably because they are in a slow process of implementing https (but as we saw in the case of Stackexchange, this can take years), still have mixed content issues. I encounter them in almost a daily basis.