On Mon, Jun 6, 2016 at 4:45 PM, Devdatta Akhawe <dev.akhawe@gmail.com> wrote: > > 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. >> > > hmm .. the use case I am interested in is script-src > https://www.dropbox.com/script/require.js 'allow-dynamic' > > Right now, this would force me to use a nonce. The nonce then is a > leakable token present in the HTML of the page. Not a huge risk, but still. > I see. That makes sense to me: you want the loader functionality, but you don't want the added surface area of the capability token. I think I agree that there are two orthogonal concerns here (loading an initial script via a nonce, hash, or URL on the one hand, and allowing that initial script to load other things on the other), and splitting them up makes sense. I worry a bit that folks would simply slap the dynamic keyword onto an already weak policy and call it done, but I suppose that doesn't make things any worse than they are today. 'allow-dynamic' (or just 'dynamic', maybe?) and 'nonce-only'? 'drop-whitelist' is a little too broad, since nonces are part of the whitelist, and we're not dropping those. 'ignore-hosts'? Concretely, would Dropbox use one (or both?) of these keywords if we >> implemented them? >> > > Not really sure yet. But, I am inclined towards the script-src example > above. > Cool, good to hear, thanks! 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? :) -mike
Received on Monday, 6 June 2016 15:49:14 UTC