On Wed, Jul 15, 2009 at 10:18 PM, Aryeh Gregor<simetrical+...@gmail.com> wrote: > I haven't seen it discussed here, but maybe it has been and I didn't > see or don't remember. Although Ian might not want to consider it for > HTML 5 without vendor agreement, I'd think that a separate working > group could be set up (or an existing one appropriated) to work it out > with input from multiple vendors.
We are *very much* soliciting input from multiple vendors, and the specification will evolve in response to it. That is approximately the whole point of the linked blog post. The source for the implementation will obviously be available (I think it already is, but I can't drop a link off the top of my head) for those who wish to show alternate possibilities, and with which site authors and so forth can experiment. If someone comes up with something that solves this problem better than CSP does, we'll do that better thing instead. (X-Frame-Options is not that better thing, by our analysis and discussions with many who seek to protect their sites and users from such attacks.) > Implement-then-document surely > isn't an ideal procedure for large, complicated things like CSP. There are no ideal procedures available for creating software or standards. One known-not-ideal procedure for standards is to dream them up out of whole cloth, iterate on the whiteboard, and then try to implement. But as I said, we'll happily take something that turns out better, so if getting to a unified cross-vendor specification before you start implementing works better for *you*, I am not going to discourage you from going down that route. (I don't think your reasoning on the basis of the word count of the incomplete draft specification text is interesting, but I haven't studied relationships between spec length and implementation difficulty or other metrics of goodness!) > There would be a lot of wasted effort if other vendors decide they > don't like the approach, and Mozilla might be more reluctant to invest > in other solutions after they've put a lot of work into CSP. There is also a lot of wasted effort if it's discovered after standardization that certain elements are too difficult to implement or have bad interactions with other aspects of supporting the real world web. It is not difficult to find standards that have gone down that path. In my opinion, the best standards are ones that codify based on existing experience with implementation and specification, not invent. Speaking as the person responsible to Mozilla's board for effective use of our (precious and scarce) paid development resources, I am not concerned about a waste of effort here. I think our history on things like offline, canvas APIs, pulling XS-XHR from FF3 so that it didn't poison the well for future direction of that specification, and so forth show that we're willing to adapt even *shipped* things if the standardization process makes changes. Right now, we're talking about and showing our work before we ship it to anyone, because we think that's a better approach than shipping something to users, encouraging developers to build things on it, and then tossing the design over the wall as a specification proposal. People will be able to follow the discussions that lead to the decisions in the design, rather than reverse engineering them from the specification text. I do appreciate your concern for our efficiency, though! :) But for all that, as indicated in the comments on the linked post, we did indeed propose it to the W3C's webapps group more than a year ago, before we had done really any work on it: http://lists.w3.org/Archives/Public/public-webapps/2008AprJun/0416.html . The charter was not expanded to include it, and it is perhaps not surprising to hear that I, at least, wasn't too depressed about it. (It sounds from that thread like some of the group members wanted more a more complete specification in some areas before considering whether it was in scope, so there's some chicken-and-egg with your proposed ordering, I think. For that group, at least.) Mike
