LGTM2 - this doesn't feel like it has any compat risk, so we shouldn't
block on usecounter data.

On Wed, Feb 15, 2023 at 5:37 PM Chris Harrelson <[email protected]>
wrote:

> LGTM1
>
> On Fri, Feb 10, 2023 at 5:56 PM Carlos IL <[email protected]> wrote:
>
>> 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
>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAABgKfVOkk%2BT%2BBCtRGjejUxYBhKqqvbGC1mPvdUg8DPVGM%3DaXQ%40mail.gmail.com?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/CAL5BFfXdaRP%2B%3DSydTAqjiyN_%3DSVD-2u9dn3w8b7HsrUyrmdwSQ%40mail.gmail.com.

Reply via email to