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: Cameron Jones <cmhjones@gmail.com>
Date: Thu, 22 Mar 2012 12:50:02 +0000
Message-ID: <CALGrget9jnWp=MHqpvcQC81hyLDEB9F589Mw37EiobR6=i4MOA@mail.gmail.com>
To: Anne van Kesteren <annevk@opera.com>
Cc: Julian Reschke <julian.reschke@gmx.de>, public-html@w3.org, "Edward O'Connor" <eoconnor@apple.com>
On Thu, Mar 22, 2012 at 12:01 PM, Anne van Kesteren <annevk@opera.com> wrote:
> 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.

In the "Risks" section of the proposal i have documented and addressed
the anticipated security concern.

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

While CORS is referenced in HTML it is not a pre-requesite for
implementations. It is feasible for an implementation to provide
security and privacy using alternative methods that those defined
through CORS and its implied insecure environment.

However, this is unrelated to the proposal which leaves these aspects
of differentiation to implementations.

>> Id 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.)

I understand that some of these concerns have been previously raised,
and remain unaddressed, which has essentially amounted to the
specification of UMP.

While i do not expect CORS to be changed based on my feedback, i do
note that there is an open TAG issue regarding the general state of
webapp security and my feedback is provided in support of further
investigation around the issue.

It is related to this thread as you have raised security concerns over
the proposal. I do not believe that HTML is the place to address those
security concerns as that falls under the charter of webapp-sec, hence
the reference and deferment to that group.

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

The concept is that which the proposal recommends.

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

HTTP is the deployment i am referring to and it is interaction with
this protocol which the proposal recommends. You have raised concern
that further information is required for specification however i am
stating that further information is not required - or available  - as
it is already under specification, implementation and deployment on a
global scale and with universal adoption.

Cameron Jones
Received on Thursday, 22 March 2012 12:50:37 UTC

This archive was generated by hypermail 2.4.0 : Saturday, 9 October 2021 18:45:50 UTC