On Sun, Jun 5, 2016 at 1:27 AM, Devdatta Akhawe <dev.akhawe@gmail.com> wrote: > 2. Change the name, but otherwise leave the behavior as specified. Some >>>>>>> possibly better names that have been thrown around were ‘allow-dynamic’, >>>>>>> ‘trust-dynamic’, ‘dynamic-nonce’ and my favorite ‘safe-dynamic’ ;-) (okay, >>>>>>> maybe the last one won’t fly) >>>>>>> 3. Change the behavior to make the feature more understandable to >>>>>>> developers. Ideas for this included introducing another directive (rather >>>>>>> than using script-src), or splitting ‘unsafe-dynamic’ into two keywords >>>>>>> (e.g. ‘drop-whitelist’ and ‘propagate-nonces’) -- each of those comes with >>>>>>> its own set of challenges, but they are probably solvable if it seems like >>>>>>> this is the way to go. >>>>>>> >>>>>>> > I am a fan of #3 over #2. CSP is already pretty confusing and I value > anything that tries to make it simpler. > What part of #3 are you a fan of? :) > I can also see some value of whitelisting one particular JS file via uri > or hash and then allow-dynamic. 'drop-uri-src' and 'allow-dynamic' seem > good keywords to start with. > Are there use-cases for these separately? I'm all for adding things to the platform if they're useful, but I'm not convinced from this thread that these keywords add anything other than complexity. That is, Brad can accomplish the things he's interested in with two policies, which I think actually turns out to be a more powerful primitive than splitting the keywords. Concretely, would Dropbox use one (or both?) of these keywords if we implemented them? Based on the experience Artur is sharing, the current behavior seems to meet most needs. I agree that it's complicated, but I think that's a fundamental critique of the whole project at this point. :) -mike
Received on Monday, 6 June 2016 11:04:37 UTC