W3C home > Mailing lists > Public > public-html@w3.org > March 2012

Re: ISSUE-195: form-http-req - Chairs Solicit Alternate Proposals or Counter-Proposals

From: Anne van Kesteren <annevk@opera.com>
Date: Thu, 22 Mar 2012 13:01:40 +0100
To: "Cameron Jones" <cmhjones@gmail.com>
Cc: "Julian Reschke" <julian.reschke@gmx.de>, public-html@w3.org, "Edward O'Connor" <eoconnor@apple.com>
Message-ID: <op.wbkmc20p64w2qv@annevk-macbookpro.local>
On Thu, 22 Mar 2012 12:38:41 +0100, Cameron Jones <cmhjones@gmail.com>  
wrote:
> The proposal advocating for the additional form methods has been
> produced with due care and attention given to security issues and
> especially in light of the work done over the years  in webapps,
> webapp-sec and through the requirements and specification of CORS.

Well, nothing in the proposal says so.


> I'd first like to highlight that the specification of HTML rightly
> does not impose the necessity of CORS in the same manner that many
> other independent  specifications are not prerequisites for
> implementation or use of HTML.

That's false. Just search for CORS in HTML.


> I’d also like to highlight that through the development of the
> proposal i have gathered a review of web app security which
> specifically addresses the premise of CORS and the wider impact of
> implementation of such technology. This review has been submitted to
> webapp-sec and as the group chartered with responsibility over the
> functional area it would seem to be the forum to discuss those
> security related concerns. As the editor of CORS i am specifically
> interested in discussing the points brought forward through my review
> with you and other members of the group such that they are addressed
> by the group to a degree of resolution for implementation or
> documentation. Here is a link to the archived copy of that review:
>
> http://lists.w3.org/Archives/Public/public-webappsec/2012Mar/0027.html

This seems unrelated to this thread. However, it's unlikely we'll change  
CORS. (The concerns you bring up have been raised before, too.)


> To respond to your concerns raised herein, the proposal as written
> defers all request generation restrictions to the specification of
> XHR. This is specifically first due to the overall concept that the
> same functionality afforded to XHR should be available to declarative
> markup, and further to this that the specification of these features
> follow a path of least resistance within the overall movements of web
> standards and implementations.

I'm not aware of such an overall concept.


> Given that the specification of forms is vis-à-vis the specification
> of XHR, there is no introduced user security or interface interactions
> within the recommended proposal. Further to this, as the means to
> expose the HTTP protocol to declarative markup there is no experience
> to be gained from waiting as the protocol is both stable and
> universally deployed and integrated.

If it's already deployed, we wouldn't need this proposal.


-- 
Anne van Kesteren
http://annevankesteren.nl/
Received on Thursday, 22 March 2012 12:02:16 UTC

This archive was generated by hypermail 2.3.1 : Monday, 29 September 2014 09:39:31 UTC