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

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 <mailto: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. :)