Thanks all for the comments, replied inline below: On Wed, Feb 8, 2023 at 9:18 AM Daniel Bratell <[email protected]> wrote:
> It sound like the user has already agreed to seeing "insecure" and > possibly compromised content in that case, but it could absolutely make > something worse. > > Is there a use counter for how often a user demands to see an "insecure" > page? That would act as an upper limit, and maybe it's already small > enough. (Or maybe not). > Unfortunately we don't have a use counter tied to the setting, we only log mixed content used counters when the actual content is loaded. > /Daniel > On 2023-02-08 17:24, Rick Byers wrote: > > It sounds like the only potential concern is a security one - where > content previously blocked at the site's request was no longer blocked. Is > that right? If so then I'd defer to security reviewers and approve from a > web compat perspective without any metrics. > > Yeah, there are no compatibility concerns here since this won't prevent anything from loading or functioning > > > > Rick > > On Wed, Feb 8, 2023 at 10:01 AM Yoav Weiss <[email protected]> wrote: > >> Any use counters for when it is used? >> > Unfortunately we do not have one for block-all-mixed-content, just for the actual loading of mixed content (which doesn't help in this case since it's being blocked from loading). > >> On Saturday, February 4, 2023 at 12:46:16 AM UTC+1 Carlos IL wrote: >> Contact [email protected] >> >> ExplainerNone >> >> Specificationhttps://www.w3.org/TR/mixed-content/#strict-checking >> >> Summary >> >> block-all-mixed-content is a CSP directive that causes Chrome to hard >> block all http resource loads on https sites. After the launch of >> autoupgrades for passive mixed content, the directive is a no-op since >> passive (image, video, and audio) mixed content is autoupgraded to https >> before block-all-mixed-content is evaluated (and fails to load if not >> available over https), and active mixed content is hard blocked by default. >> block-all-mixed content still has an effect when a user has allowlisted a >> site (using the "Insecure Content" site setting toggle) to allow mixed >> content, but that is a fairly niche use case (and it seems unlikely that >> sites are relying on that functionality). >> >> So this can have a visible effect when users explicitly allow mixed >> content *and* the site is trying to prevent that? And the effect in this >> case would be that the mixed content resources are not broken? >> >> block-all-mixed-content was previously defined in the MIX spec, but was >> marked as obsolete when MIX and MIX2 were merged and the concept of >> autoupgrades was introduced. It is already marked as deprecated in MDN docs. >> >> >> Blink componentBlink>SecurityFeature>MixedContent >> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3ESecurityFeature%3EMixedContent> >> >> Motivation >> >> block-all-mixed content is already marked as obsolete in the Mixed >> Content spec, is a no-op in most cases, and removing it would simplify >> Chrome's mixed content handling code. >> >> >> Initial public proposal >> >> TAG review >> >> TAG review statusNot applicable >> >> Risks >> >> >> Interoperability and Compatibility >> >> The spec change that made this directive obsolete went through comments >> in webappsec and has already been merged to the spec (since 2020) >> >> *Gecko*: No signal >> >> *WebKit*: No signal >> >> Did other vendors ship this? If so, are they planning to unship it? >> >> >> *Web developers*: No signals >> >> *Other signals*: >> >> WebView application risks >> >> Does this intent deprecate or change behavior of existing APIs, such that >> it has potentially high risk for Android WebView-based applications? >> >> >> Debuggability >> >> Is this feature fully tested by web-platform-tests >> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> >> ?No >> >> Flag name >> >> Requires code in //chrome?False >> >> Estimated milestones >> >> No milestones specified >> >> >> Link to entry on the Chrome Platform Statushttps://chromestatus.com/ >> feature/5199363708551168 >> -- >> You received this message because you are subscribed to the Google Groups >> "blink-dev" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> To view this discussion on the web visit >> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/1a73276e-a3d4-45d3-b3fb-751f9edd6d09n%40chromium.org >> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/1a73276e-a3d4-45d3-b3fb-751f9edd6d09n%40chromium.org?utm_medium=email&utm_source=footer> >> . >> > -- > You received this message because you are subscribed to the Google Groups > "blink-dev" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY_%3DHGk4vyuTMa72sRCAapQ3mYOknDDSQyB%3DgC6df2wY2A%40mail.gmail.com > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY_%3DHGk4vyuTMa72sRCAapQ3mYOknDDSQyB%3DgC6df2wY2A%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > > Thanks again, -Carlos -- You received this message because you are subscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAABgKfVOkk%2BT%2BBCtRGjejUxYBhKqqvbGC1mPvdUg8DPVGM%3DaXQ%40mail.gmail.com.
