[whatwg] Clickjacking and CSRF

[Mike Shaver]

On Wed, Jul 15, 2009 at 10:18 PM, Aryeh Gregor<Simetrical+w3c at 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