3 ms·

This is discussed in the post text, but happy to elaborate here in more detail here! Here is the patch links from Firefox[0] and from Chrome[1] which they speci

This is discussed in the post text, but happy to elaborate here in more detail here! Here is the patch links from Firefox[0] and from Chrome[1] which they specify that active mixed content policies do not apply to the localhost, because the w3c specification was updated to specifically allow this behaviour[2]. You might have to use 127.0.0.1 directly. So yes, it is allowed. If for some reason that doesn't work for your app, the post also mention two secure alternatives: the native client can install a self-signed cert, or you can use a browser extension with the native messaging API. You touched on this too! My point here is not the specific example solution -- there's lots of alternatives and yes it depends on the situation and browser support requirements. But NONE of them are a reason to allow requests from every origin. [0]: https://bugzilla.mozilla.org/show_bug.cgi?id=903966 https://bugzilla.mozilla.org/show_bug.cgi?id=903966 [1]: https://chromium.googlesource.com/chromium/src.git/+/130ee686fa00b617bfc001ceb3bb49782da2cb4e https://chromium.googlesource.com/chromium/src.git/+/130ee68... [2]: https://github.com/w3c/webappsec-mixed-content/commit/349501cdaa4b4dc1e2a8aacb216ced58fd316165 https://github.com/w3c/webappsec-mixed-content/commit/349501...

edejong 7y ago
I see it is fixed now. I thought up this work-around back in 2014, when NPAPI was phased out. Spotify and another large player came up with similar solutions.
- chrisfosterelli 7y ago
  Totally. I do get the constraints and I imagine Zoom had similar thinking here. The image approach, although hacky, can even be secure as-is if they need it for backward-compatibility but it needs to check the headers and not honour requests with the wrong value.
  - edejong 7y ago
    I kind of like the ingenuity of the approach. Never occurred to me to use non-active content.
smallnamespace 7y ago
It seems that the Chromium patches are from 2016, so presumably this would still break older Chrome users? 2016 is in the 50s, and this[1] claims that version <67 has single-digit usage share. [1] https://www.w3schools.com/browsers/browsers_chrome.asp https://www.w3schools.com/browsers/browsers_chrome.asp

edejong 7y ago

I see it is fixed now. I thought up this work-around back in 2014, when NPAPI was phased out. Spotify and another large player came up with similar solutions.

chrisfosterelli 7y ago
Totally. I do get the constraints and I imagine Zoom had similar thinking here. The image approach, although hacky, can even be secure as-is if they need it for backward-compatibility but it needs to check the headers and not honour requests with the wrong value.
- edejong 7y ago
  I kind of like the ingenuity of the approach. Never occurred to me to use non-active content.

smallnamespace 7y ago

It seems that the Chromium patches are from 2016, so presumably this would still break older Chrome users? 2016 is in the 50s, and this[1] claims that version <67 has single-digit usage share. [1] https://www.w3schools.com/browsers/browsers_chrome.asp https://www.w3schools.com/browsers/browsers_chrome.asp