W3C home > Mailing lists > Public > public-webappsec@w3.org > July 2019

Re: A modest content security proposal - use of "unsafe"

From: Craig Francis <craig.francis@gmail.com>
Date: Tue, 23 Jul 2019 20:43:41 +0100
Message-ID: <CALytEkPE26jZaRbfUBvidVcp2EQseg7iWKc1+hS1+GAeM_x0BA@mail.gmail.com>
To: Mike West <mkwst@google.com>
Cc: Web Application Security Working Group <public-webappsec@w3.org>
I'm not familiar with 'unsafe-eval' being ok - I've always been under the
impression "eval() is evil", and we should be discouraging its use.

A bit like the use of goto:


It's why I'd rather your proposal use `allow-unsafe` so it simply pushes
developers towards `allow-trusted`.

And I would like `block` be the default when a `Scripting-Policy` has been
set (although I could be convinced that a more relaxed default might help
with adoption, as developers would have less issues to begin with).

In contrast, I can see how 'unsafe-inline' was helpful in the world of
CSP-1 (i.e. it's bad)... but when introducing the concept of a nonce/hash,
while providing backwards compatibility, the "unsafe-" prefix did become a
small problem.

As an aside, is there a better word for "nonce"? in the UK it's slang for
paedophile, and I have a horrible feeling someone chose that word because
they thought it was funny (it's a very odd abbreviation for "number used


On Tue, 23 Jul 2019 at 08:33, Mike West <mkwst@google.com> wrote:

> I'm thinking mostly of the conversation around `unsafe-eval`, which some
> developers took as a much more damning critique of their chosen programming
> methods than I think we'd intended. I don't think that label, in
> particular, was helpful.
> I don't think I'd object to `unsafe-whatever` labels in whatever we do
> next, but I would like to make sure that we generally think it's going to
> be helpful to developer education on balance.
> -mike
> On Thu, Jul 18, 2019 at 3:03 PM Craig Francis <craig.francis@gmail.com>
> wrote:
>> In regards to the first bit, about the "unsafe" prefixes...
>> When discussing best coding practices with other programmers, it has
>> helped me confirm/show inline JavaScript is unsafe ("see, even the browsers
>> are telling you it's unsafe").
>> And it makes it easy to write about in a pen-test report, where it hardly
>> needs an explanation (admittedly it's complicated by the nonce based
>> approach, which needs it for backwards compatibility).
>> I also believe it's being introduced/used in some programming languages
>> (Rust and Haskell?) and some frameworks (unfortunately I don't have
>> direct examples of these, just overhearing programmers talking about it in
>> a positive way).
>> On 16 Jul 2019, at 11:54, Mike West <mkwst@google.com> wrote:
>> Thanks for your feedback! I'll concentrate on the resource confinement
>> feedback, as it's the part I've thought least about, and I'd like to
>> understand your perspective!
>> On Mon, Jul 15, 2019 at 2:15 PM Craig Francis <craig.francis@gmail.com>
>> wrote:
>>> Initial thoughts from a web developer, one that really likes CSP...
>>> I like the idea of the browser providing the nonce, and that being used
>>> to white-list scripting - it feels like a good way to prove the website did
>>> intend to include that script. It also means the browser knows the nonce is
>>> random/unique (where developers should still be careful, you're reflecting
>>> a value back in your HTML).
>>> And simplifying the process by locking down <base>, <object>,
>>> "javascript:" URLs, etc; that should set a good/simplier baseline (where I
>>> think "allow" should be re-named "allow-unsafe", and I would prefer eval to
>>> be "block" by default).
>> In hindsight, I don't think the `unsafe-` prefixes made us any friends in
>> the development community. Nor do I think they stopped anyone from doing
>> unsafe things. It just made them irate while they were doing so. :)
Received on Tuesday, 23 July 2019 19:44:16 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:55:07 UTC