+1 that having the smallest possible number of standard ways to identify
content as the best choice for a coherent platform.
This does argue that whatever name we use it shouldn't have "nonce" in it,
as there is clearly interest in identifying the entry points for dynamic
trust propagation with more than just nonces.
On Tue, Jun 7, 2016 at 6:14 AM Mike West <mkwst@google.com> wrote:
> While we're on the topic, I'd like to harden that example via externalized
>>> hashes (e.g. `sha256-abc...` would allow `<script integrity="sha256-abc..."
>>> ...>` to load). I'd like to find a mechanism to do so in a backwards
>>> compatible way. We discussed it briefly at our last meeting. Anyone have
>>> any good ideas? :)
>>>
>>
>> To properly discuss it, I'd suggest doing it on another thread, maybe? ;)
>>
>
> Done. :)
>
>
>> FWIW my preference would be to allow hashes to whitelist script URLs
>> rather than contents, and keep SRI as a mechanism to enforce integrity...
>>
>
> What do you mean by "allow hashes to whitelist script URLs"? Adding
> `SHA256("https://example.com")` to a policy to match a resource at "
> https://example.com"? I don't see any advantage to doing so (other than
> policy length, I suppose?).
>
>
>> Otherwise, the "static content" case will be difficult to achieve with
>> hashes because any changes to the external scripts will break the policy,
>> since the digest will no longer match.
>>
>
> I'd like to tie the CSP implementation to the SRI implementation. If/when
> SRI2 supports something other than flat content matches (signatures, etc),
> then CSP would flow right along.
>
> As long as we have SRI that supports the brittle kind of loading behavior
> that you note above (which I do believe is valuable, though I recognize its
> drawbacks), it makes sense for CSP to have the same behavior.
>
> -mike
>
Received on Tuesday, 7 June 2016 16:16:24 UTC