For a time being, it won't - unless you intend to only provide CSRF protection for the browsers that support this extension (and can server even detect whenever the UA is capable or not?). I think for at least a few years, Cookie+POST data is the only reliable option.
> I think for at least a few years, Cookie+POST data is the only reliable option.
Not entirely. If you're willing to set headers you can do so as a trivial anti-CSRF measure. Just setting a header like "X-Totes-Not-CSRF" would suffice as CORS will prevent arbitrary sites from setting such a header. Its value does not matter.
A similar anti-CSRF measure is implemented in some application frameworks by default. For example, When performing XHR requests in AngularJS, "the $http service reads a token from a cookie (by default, XSRF-TOKEN) and sets it as an HTTP header (X-XSRF-TOKEN). Since only JavaScript that runs on your domain could read the cookie, your server can be assured that the XHR came from JavaScript running on your domain. The header will not be set for cross-domain requests."
This is an effective approach because unless an attacker has already compromised the relevant cookie, they will be unable to spoof the X-XSRF-TOKEN header in a cross-origin request. On the server-side, you just need to validate that (a) the X-XSRF-TOKEN header was sent and (b) it contains the expected value for each HTTP request received.
However that does cause an extra round trip for the OPTIONS message (slowing down your site). The options can be avoided if you do not set any optional headers (plus a couple of other restrictions).
However, I'm not sure I see any security improvements for applications that already prevent CSRF.