You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Nov 6, 2023. It is now read-only.
Repository navigation
This repository was archived by the owner on Nov 6, 2023. It is now read-only.
@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.
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:
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?
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.
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.
@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:
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
Gather a list of all the mixedcontent rules
Remove the mixedcontent flag from them, and
Disable all of those rules that break, using our fetch tester.
@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.
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.
@Hainish the workaround described in #9971 (comment) does not work anymore and it's not practical.
About 5% of our rules are currently disabled because of mixed content and another unknown number because of incomplete certificate chains (#6966). An option to enable additional rules could enhance coverage/security a lot for advanced users (or Tor browser?). Please consider to reopen this issue.
I'm not opposed to this option, but a potential problem is that users will enable mixedcontent rulesets, and then later see a bunch of broken pages, and not make the connection that enabling the option is what is breaking the pages. These users will then disable HTTPS Everywhere entirely, generate support requests, leave bad reviews etc.
We might take a different approach and add a sort of slider option for security, like Torbutton, with "Safest" the same as "Block all unencrypted requests", "Safer" as regular operation but with mixedcontent rulesets enabled, and "Standard" as what it normally does now.
@J0WI I've updated #9971 (comment) to reflect how to enable mixed content rulesets with the new modular system.
@jeremyn I see how what you describe could be a problem, but I don't see how a security slider would be a solution. I don't think it's necessarily intuitive that raising the security level on a slider will break pages, and people may forget that they changed their security settings. In that case, the negative results you mention will still happen.
Relatedly, in Firefox 60, they're introducing a pref to upgrade mixed content on secure pages, similar to how Upgrade Insecure Requests works. I've requested that this pref be exposed to WebExtensions so that we can enable it.
It is a continuum going from using standard rulesets, to using standard plus mixedcontent rulesets, to blocking everything, so the option is more naturally described with a slider instead of, for example, multiple checkboxes.
The difference between the Torbutton slider UI, and an equivalent simple radio button, is that the slider UI gives space to describe both the pros and (importantly) cons of each setting.
Relatedly, in Firefox 60, they're introducing a pref to upgrade mixed content on secure pages, similar to how Upgrade Insecure Requests works. I've requested that this pref be exposed to WebExtensions so that we can enable it.
That's only for mixed passive content and it's already enabled by default, isn't it?
@J0WI I've updated #9971 (comment) to reflect how to enable mixed content rulesets with the new modular system.
@Hainish I was not able to enable them. store.get({enableMixedRulesets: false}, item => console.log(item)); returns Object { enableMixedRulesets: true }.
Activity
jeremyn commentedon May 20, 2017
@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 commentedon May 21, 2017
#8506 enable mixedcontent on all platform by default.
Bisaloo commentedon May 22, 2017
@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 commentedon May 22, 2017
A more general version of this issue is a way to turn on any combination of
platforms, not justmixedcontent, using a checklist.Hainish commentedon May 24, 2017
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:I suspect that our tagging of these rules as
mixedcontentis 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 themixedcontentrules.jeremyn commentedon May 25, 2017
@Hainish I think this issue is to add the option to enable all the
mixedcontentrules, not that we should enable them all by default.Hainish commentedon May 25, 2017
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 themixedcontentflag from rulesets that still have it, if they aren't breaking?Bisaloo commentedon May 25, 2017
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-contentCSP.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 commentedon May 25, 2017
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 commentedon May 26, 2017
@jeremyn we're using the storage API for all persistence within WebExtensions currently. I was using
localStorageas a synonym, which isn't strictly correct. The specific storage engine is eithersyncorlocal, 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:I get the following results:
Oversee.xml- automatically forwards to HTTPSAEUP.eu.xml- no content shown on HTTP, invalid certificate on HTTPS (using old cipher)Docelu.pl-problematic.xml- HTTPS endpoint does not existDC_Power.eu.xml- automatically forwards to HTTPSMIMS.xml- no difference between HTTP and HTTPS (no mixed content)DjurRattsAlliansen.se.xml- HTTPS endpoint does not existRoccat.org.xml- downgrades you to HTTPzongheng.com.xml- HTTPS endpoint does not existhitfile.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
mixedcontentflag altogether, we shouldmixedcontentrulesmixedcontentflag from them, andjeremyn commentedon May 26, 2017
@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 amixedcontentwarning is outdated. I would probably rather delete any givenmixedcontentruleset than enable it, if I had to choose.Bisaloo commentedon May 26, 2017
I disagree here. I think websites that had a previously fully working
httpsconfiguration 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.14 remaining items
J0WI commentedon Feb 24, 2018
@Hainish the workaround described in #9971 (comment) does not work anymore and it's not practical.
About 5% of our rules are currently disabled because of mixed content and another unknown number because of incomplete certificate chains (#6966). An option to enable additional rules could enhance coverage/security a lot for advanced users (or Tor browser?). Please consider to reopen this issue.
jeremyn commentedon Feb 28, 2018
I'm not opposed to this option, but a potential problem is that users will enable
mixedcontentrulesets, and then later see a bunch of broken pages, and not make the connection that enabling the option is what is breaking the pages. These users will then disable HTTPS Everywhere entirely, generate support requests, leave bad reviews etc.We might take a different approach and add a sort of slider option for security, like Torbutton, with "Safest" the same as "Block all unencrypted requests", "Safer" as regular operation but with
mixedcontentrulesets enabled, and "Standard" as what it normally does now.Hainish commentedon Feb 28, 2018
@J0WI I've updated #9971 (comment) to reflect how to enable mixed content rulesets with the new modular system.
@jeremyn I see how what you describe could be a problem, but I don't see how a security slider would be a solution. I don't think it's necessarily intuitive that raising the security level on a slider will break pages, and people may forget that they changed their security settings. In that case, the negative results you mention will still happen.
Hainish commentedon Feb 28, 2018
Relatedly, in Firefox 60, they're introducing a pref to upgrade mixed content on secure pages, similar to how Upgrade Insecure Requests works. I've requested that this pref be exposed to WebExtensions so that we can enable it.
jeremyn commentedon Feb 28, 2018
It is a continuum going from using standard rulesets, to using standard plus
mixedcontentrulesets, to blocking everything, so the option is more naturally described with a slider instead of, for example, multiple checkboxes.The difference between the Torbutton slider UI, and an equivalent simple radio button, is that the slider UI gives space to describe both the pros and (importantly) cons of each setting.
J0WI commentedon Feb 28, 2018
That's only for mixed passive content and it's already enabled by default, isn't it?
Hainish commentedon Feb 28, 2018
Ah, looks like you're right. Thanks @J0WI.
Hainish commentedon Feb 28, 2018
@J0WI I think the pref is only defaulted to
truefor nigthtly: https://bugzilla.mozilla.org/show_bug.cgi?id=1435733#c7J0WI commentedon Mar 1, 2018
@Hainish I was not able to enable them.
store.get({enableMixedRulesets: false}, item => console.log(item));returnsObject { enableMixedRulesets: true }.Hainish commentedon Mar 1, 2018
@J0WI that result indicates that it is in fact enabled.
Hainish commentedon Mar 1, 2018
@J0WI ah, you're saying that they aren't enabled despite this result?
J0WI commentedon Mar 1, 2018
Exactly.
cschanaj commentedon Apr 4, 2018
See #15070