- From: Hill, Brad <bhill@paypal-inc.com>
- Date: Tue, 12 Feb 2013 20:20:45 +0000
- To: Ian Melven <imelven@mozilla.com>, Bryan McQuade <bmcquade@google.com>
- CC: Jacob Hoffman-Andrews <jsha@twitter.com>, Eric Chen <eric.chen@sv.cmu.edu>, Nicholas Green <ngreen@twitter.com>, "public-webappsec@w3.org" <public-webappsec@w3.org>, Yoav Weiss <yoav@yoav.ws>
> what is the rationale for preventing this beyond difficulty of implementation? [Hill, Brad] I'm always the first one to invoke the priority of constituencies, but I think there's a real sense in which difficulty of implementation is the only interesting problem here, and directly related to the use-case goals of the feature. How do we create a canonical set of bytes to represent script content inline in an HTML document that is unambiguous and yet not brittle across multiple implementations and (importantly) future implementations? We're taking dependencies on a core and complex part of HTML here. We should expect HTML to continue to evolve, and for the pressures on it to be stronger than any back-pressure we can put it on behalf of script-hash. If we design something that is brittle, constrictive or otherwise problematic in the face of the evolution of core document parsing, we should expect script-nonce will fail and get left behind.
Received on Tuesday, 12 February 2013 20:21:18 UTC