- 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>
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