Re: [SRI] Escaping mixed-content blocking for video distribution

Hi Brad,

Thanks. I am not so much concerned with standardization status right now as
with getting feedback on and discussion of the idea. If it's a good idea
(or becomes one with discussion) people will want to implement it and
_then_ people will want to standardize it. So, I agree that a Last Call
comment aimed at modification of the current spec is not the best way
forward.

Anne also posted a variation / alternative and we should also discuss that.
In that idea MSE is made to work like @src on audio/video with respect to
mixed content, by direct use of fetch() with mode "No CORS" instead of XHR.
I'd be interested what everyone thinks of that approach ?

If I understand your comments (2), (3) correctly, you mean that since SRI
only handles the integrity component, allowing SRI-protected resources to
escape mixed content blocking would be considered to be putting the whole
browsing session into a different, less secure, state ("security context")
than if no such mixed-content was present and the issue is then how to
message this new to the user ? I wonder whether people think that the
request integrity idea has any impact on this i.e. could that or a
variation avoid the need for a new state ?

...Mark





On Mon, Nov 17, 2014 at 3:08 PM, Brad Hill <hillbrad@fb.com> wrote:

> Mark,
>
>  We discussed this on our call today and consensus was that there are a
> couple issues here to tease apart.
>
>  1) SRI can provide an assertion of the integrity of a resource load.  We
> should investigate enhancements to the algorithm to allow making these
> assertions for streaming or otherwise incrementally or randomly accessing
> content.  I have created ISSUE-72 to track this.
> https://www.w3.org/2011/webappsec/track/issues/72
>
>  2) The assertion about integrity SRI enables is a component of the
> overall input to the algorithms for Mixed Content, which has just entered
> Last Call. The group would welcome additional comments here.  Sections 5.2
> http://www.w3.org/TR/mixed-content/#should-block-fetch and 5.3
> http://www.w3.org/TR/mixed-content/#should-block-response may have
> relevant inputs from the results of an SRI check.  However, this would
> likely result in a new state for the security context.
>
>  3) Whether to handle such a new state and what UI treatment to give it is
> today at the discretion of the browsers.  I think the group would consider
> specifying it but:
>         (a) There is a poor history of such attempts at the W3C and
> elsewhere.
> UAs are reluctant to commit to such things.
>         (b) Especially given this history I would be hesitant to add it as
> a new
> feature at Last Call unless we have a commitment from at least one
> implementor. Our charter requires two independent interoperable
> implementations to advance beyond CR, so any addition would need to be
> marked as AT RISK.
>
>
> If you do wish to make a Last Call comment the group will be obligated to
> formally address it. My sense of the consensus is that there is no
> objection to at least further exploring it as a Level 2 feature.   I don't
> want to just churn the current spec and burn editor's time if there's no
> practical chance of it advancing, so I think getting expressions of intent
> from implementers would be the major factor to get something in before
> that.
>
> Thanks,
>
> Brad Hill
>
>
>