Re: A modest content security proposal.

Not to distract from the meat of the conversation, but 'nonce' as as term is and had been used ubiquitously in cryptograpy and cryptographic literature for decades - if not more now.As as word it has an etymology going back to the 13th century, with its established meaning of 'used for one occasion' remaining consistent.Yes, languages evolve, but just because we in the UK have some who use it to refer to child molesters does not mean the term should be replaced. In recent vernacular I've hardly ever heard 'nonce' used outside of cryptographic literature. These days we tend to call child molesters and paedophiles well, exactly that, child molesters and paedophiles. Please let us not taint the conversation with such unpleasantness in future. 'Nonce' had a clear, specific, and well understood meaning and is the appropriate term in this context.  ('Hash' and 'cryptogrpahic digest' are important terms but they are semanticly different and, simply put, do not mean the same thing.)As to ..."The tools have changed since that research paper, but I *suspect* there's still a "friction" against subdomains"... I totally agree on a conceptual level - indeed, given the stateless nature of HTTP I see no reason why any response should not have the ability to restrict scripts (via headers - through .htaccess files or other controls such as meta/pramga tags in HTML), as long as the most strict intersection of all defined restrictions is enforced.As to  ..."sincerely complicate writing a parser".... I will defer to the expertise of the list here and those with development experience, but my initial response is surprise. As far as I can see this is simple left to right parsing (i.e. LR(1) grammar processing) task, hence should be both fast and relatively simple?As to the concerns regarding adoption, from my perspective this is not a technical challenge and will be driven in future more by it simply being best practice. Best practice tends to filter into inclusion for standards and eventually through enforcement via regulators and through good developers system administrators.As of today I see a a lot of pressure (often mandated requirements) for Strict-Transport-Security headers, cookies being flagged Secure and HttpOnly and if not covered by CSP and other controls, additional headers such as X-Frame-Options, X-Content-Type-Options and Referrer-Policy. There is even pressure (and often implementation of) SRI and non-standardised options like Feature-Policy from vendors I have worked with.Just as I don't subscribe to 'build it and users will come' mantra (i.e. I don't think people will use something that's crap), the same applies to security in my view:  limit it too much and trade off too much in the name of simplicity / ease of implementation and you risk undermining the entire benefit and rendering it marginal to pointless to implement. The TLS teams have managed to achieve both - robust cryptograpy for the time, clear implementation guidance and good adoption, with transition happening to later versions as needed (sometimes through regulatory pressure). There is no reason the same cannot be true for CSP3.More crudely put: if the implementation is reasonable and the need is there, developers who don't get it and want to ignore it will be forced to learn and adapt over time. This who won't will be replaced in the market by ones who can/will as time goes on.Regards,Alexander Forbesaxeforbes@uk.ibm.com+447917158798Sent from IBM Verse



   Oda, Terri --- Re: A modest content security proposal. --- 
    From:"Oda, Terri" <terri.oda@intel.com>To:"Craig Francis" <craig.francis@gmail.com>Cc:"Mike West" <mkwst@google.com>, "Devdatta Akhawe" <dev@dropbox.com>, "Web Application Security Working Group" <public-webappsec@w3.org>Date:Tue, 23 Jul 2019 23:44Subject:Re: A modest content security proposal.
  
      
         On Tue, Jul 23, 2019 at 12:45 PM Craig Francis <craig.francis@gmail.com> wrote:
    
               On Tue, 23 Jul 2019 at 08:51, Mike West <mkwst@google.com> wrote:
                   A more typical (smaller) website probably doesn't need that many paths, and if they only contain static files, then you're unlikely to find a redirect in there.
                
                                      I don't have fundamental objections to including some sort of path restrictions in whatever we do next. I don't think they're terribly useful as-defined in CSP3: they sincerely complicate writing a parser, and they're more or less neutered so as to not leak data about redirects. 
                                
          These two paragraphs reminded me... back before CSP, I worked on a system to do resource confinement, and our research at the time found that many sysadmins were totally ok with everything being based on domains, but many web design folk preferred paths, because they didn't always have sufficient control over their hosting (or their customers didn't, or it had the potential for a whole lot of open tickets and communication hassles even when it was doable). 
          
          ... Of course, since the projects where we asked these questions was a research project, we made a note of it and then only wrote the demo code to support domains because paths would have been more work and weren't really more likely to get us a publication. ;)  (Ah, academia!)
          
          The tools have changed since that research paper, but I *suspect* there's still a "friction" against subdomains.  Hosted services like github pages or wordpress may not have that type of flexibility, and contract designers may have the same problems now as they did a decade ago.  These seem like issues that may affect folk who would be especially interested in a sleek new CSP.  Not sure how we'd test the hypothesis, but I'm thinking that Craig is onto something here so I guess I'm +1 for supporting paths too.
          
           Terri
          
       
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU