Re: [AC] URI canonicalization problem with Access-Control-Policy-Path

public-appformats-request@w3.org wrote on 05/15/2008 08:22:23 AM:

>
> * Jon Ferraiolo wrote:
> >[...]
>
> It seems your confusion and your misplaced comments are the result of
> your overly narrow focus on a small subset of the problem space "AC"
> is supposed to address, and on making sites and services available to
> third parties, rather than inadvertently exposing them. You regularily
> reinforce your own confusion by using misleading terminology. E.g.:

I apologize for past, present and future sins around confusion, misplaced
comments, overly narrow focus, and misleading terminology.

>
> >XDR has a similar approach where the server must opt-in by checking for
> >XDomainRequest: 1 header in the request and returning
> >XDomainRequestAllowed: 1 in the response.
>
> Here you use "opt-in" without further qualification. Consider you re-
> ceive a spam mail offering you the choice to receive additional spam
> mail. The spammer might then also say people must opt-in by clicking
> some link or whatever, but he would only tell half the story, since
> you never opted into receiving any mail from him in the first place.
>
> If you would escape the narrow little subset of features offered by
> XDR and JSONRequest for a little while, it would be much easier for
> you to see that the spammer, or in our case, the browser, can't just
> send out the initial message hoping the server welcomes it, an opt-
> in is required.

Narrow little subset? The primary use case illustrated in the AC spec is
using XMLHttpRequest for cross-site requests for GET and POST requests.

I didn't understand your logic with the spammer metaphor where the browser
is the spammer sending unwanted initial requests to the server. A request
goes to the server no matter whether we are talking about AC/XHR,
JSONRequest or XDR. With AC/XHR, the browser sends a request (the spam) and
the response comes back with either Access-Control header or (for XML) an
Access-Control PI. With JSONRequest, the response is either an error or
comes back with a Content-Type:application/jsonrequest header. With XDR,
similar, except with a XDomainRequestAllowed:1. What am I missing?

>
> To put it this way: some people are trying to design a vehicle that
> takes them from Iceland to Australia, and you tell them people should
> only ride bicycles out of environmental considerations. There won't be
> any agreement between you and those people until you stop talking about
> bicycles, and start talking about whether to make the trip at all.

Huh?

>
> >I'm not sure what you are asking. Are you saying that we can't require
> >existing servers to make changes in order to support cross-site
requests?
>
> Consider you reached a compromise and built a bicycle-powered ship.
> Jonas' perspective is this: "Oh my god, an iceberg! We must change
> course or we will all perish!" Your perspective is this: "Hey look,
> an iceberg with cute little penguins! We must change course to
> observe them more closely!" Superficially eiher problem requires a
> course correction, but hidden under the surface is a big difference.

Huh?

>
> It may well be that for architectural or practical reasons you think
> that the wrong problem is being solved here, that there should never
> be cross site requests with non-trivial methods, with automatic state
> management, standard authentication facilities and broad control over
> headers and data formats, but running around screaming how the server
> should have more pep and how you don't understand what everyone else
> is talking about is not a good way to convey that.

I am most definitely for making the web more powerful and providing
convenience to web developers, but web security is already a tenuous thing
that has somehow moved into a reasonable state right now where things
generally sort of work OK from a security perspective. One of the key
reasons things work OK is an implicit covenant between users, web
developers, and browser vendors regarding the same-origin policy. Adding
new flexibility to browsers that loosen the same-origin policy have to done
carefully.

For example, my opinion is that cookies should not be transmitted with a
new cross-site request feature unless there is some sort of minimal opt-in
mechanism for servers in order to prevent legacy web sites from being
harmed by a new vulnerability. (There have been differences of opinion on
this list regarding what to do with cookies, but my opinion is shared by
Doug Crockford of JSONRequest fame, MS with XDR, and Mozilla has said they
are too timid to be the first browser to enable cross-site transmission of
cookies, so I am not alone.)

But cookies are just one small part of a bigger picture. My opinion is that
it would be better to start off with an approach that is based on something
like JSONRequest or XDR where policy management (i.e., allow/deny logic)
happens on the server rather than the client, and where the starting point
for discussion is a proposal that has been designed with security in mind
from the beginning. ***THEN*** make adjustments to improve from this secure
foundation to offer more flexibility and possibly even better security
characteristics. For example, start with JSONRequest and transform it into
something that include XML support, or start with XDR and transform it into
something that offers an option to go beyond just GET and POST and allows
for secure transmission of user credentials.

Jon


> --
> Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de
> Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de
> 68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/
>