Re: Content Security Policy

+1 for discussing it further.

The advantages I see:
* The author is authorizing a *specific* script/style and can do so using
static configuration
  - No need for a dynamic backend that changes the nonce for each request.
  - This can simplify deployment, resulting in more people using it
* I'm afraid of authors abusing nonces, sending the same nonce over and
over as means to "bypass" CSP
  - Offering an alternative to nonce can reduce that risk

The complications I can think of:
* Make sure that either hashes don't break with small white-spaces
removals, text encoding changes, etc.
  - An alternative is tools that can give authors the resulting hash for a
specific script/style. (e.g. inside the Web inspector tools). That may be
more fragile, though.

All in all, I think hashes can make it easier for "copy&paste" authors to
integrate CSP. They can also make deployment of third party scripts easier.


On Sat, Jun 15, 2013 at 8:00 AM, Neil Matatall <neilm@twitter.com> wrote:

> This is the script-hash proposal. I would love it if we discussed this
> more as it has numerous benefits over a nonce as well as complications :)
> On Jun 15, 2013 1:11 AM, "Евнгений Яременко" <w3techplayground@gmail.com>
> wrote:
>
>> Is it possible to verify(whitelist) inline script block via checksum of
>> its logic(uniform) as alternative to "Nonce"?  ie send checksum of the
>> allowed script via header and if inlined script checksum is the same it's
>> allowed to execute.
>>
>