Re: [cors] Allow-Credentials vs Allow-Origin: * on image elements?

It's not just implementation effort-- as I mentioned, it's potentially a
compatibility question.  If you are proposing not sending cookies on any
cross-origin images (or other potential candidates for CORS), do you have
any data about which sites that might affect?

Personally, I would love to see cross-origin subresource requests change to
not using cookies, but that could break existing web sites that include
subresources from partner sites, etc.  Is there a proposal or discussion
about this somewhere?

In the mean time, the canvas tainting example in the spec seems difficult to
achieve.

Charlie



On Wed, Jul 7, 2010 at 5:05 PM, Devdatta Akhawe <dev.akhawe@gmail.com>wrote:

> hmm, I think I quoted the wrong part of your email. I wanted to ask
> why would it be undesirable to make CORS GET requests cookie-less. It
> seems the argument here is reduction of implementation work. Is this
> the only one? Note that even AnonXmlHttpRequest intends to make GET
> requests cookie-less.
>
> Regards
> devdatta
>
>
> >
> > I meant "undesirable" in that it will require much deeper changes to
> > browsers.
> > I wouldn't mind making it possible to request an image or other
> subresource
> > without cookies, but I don't think there's currently a mechanism for
> that,
> > is there?  And if there's consensus that user agents shouldn't send
> cookies
> > at all on third party subresources, I'm ok with that, but I imagine there
> > would be pushback on that sort of proposal-- it would likely affect
> > compatibility with existing web sites.  I haven't gathered any data on
> it,
> > though.
> > The benefit to allowing * with credentials is that it lets CORS work with
> > the existing browser request logic for images and other subresources,
> where
> > cookies are currently sent with the request.
> > Charlie
> >
> >>
> >> On 7 July 2010 16:11, Charlie Reis <creis@chromium.org> wrote:
> >> >
> >> >
> >> > On Wed, Jul 7, 2010 at 4:04 PM, Mark S. Miller <erights@google.com>
> >> > wrote:
> >> >>
> >> >> On Wed, Jul 7, 2010 at 1:09 PM, Charlie Reis <creis@chromium.org>
> >> >> wrote:
> >> >> [...]
> >> >>>
> >> >>> That's unfortunate-- at least for now, that prevents servers from
> >> >>> echoing
> >> >>> the origin in the Access-Control-Allow-Origin header, so servers
> >> >>> cannot host
> >> >>> "public" images that don't taint canvases.  The same problem likely
> >> >>> exists
> >> >>> for other types of requests that might adopt CORS, like fonts, etc.
> >> >>
> >> >> Why would public images or fonts need credentials?
> >> >
> >> > Because it's undesirable to prevent the browser from sending cookies
> on
> >> > an
> >> > <img> request, and the user might have cookies for the image's site.
> >> >  It's
> >> > typical for the browser to send cookies on such requests, and those
> are
> >> > considered a type of credentials by CORS.
> >> > Charlie
> >> >
> >> >>
> >> >>
> >> >>>>
> >> >>>> I believe the plan is to change HTML5 once CORS is somewhat more
> >> >>>> stable
> >> >>>> and use it for various pieces of infrastructure there. At that
> point
> >> >>>> we can
> >> >>>> change <img> to transmit an Origin header with an origin. We could
> >> >>>> also
> >> >>>> decide to change CORS and allow the combination of * and the
> >> >>>> credentials
> >> >>>> flag being true. I think * is not too different from echoing back
> the
> >> >>>> value
> >> >>>> of a header.
> >> >>>>
> >> >>>
> >> >>> I would second the proposal to allow * with credentials.  It seems
> >> >>> roughly equivalent to echoing back the Origin header, and it would
> >> >>> allow
> >> >>> CORS to work on images and other types of requests without changes
> to
> >> >>> HTML5.
> >> >>> Thanks,
> >> >>> Charlie
> >> >>
> >> >>
> >> >>
> >> >> --
> >> >>     Cheers,
> >> >>     --MarkM
> >> >
> >> >
> >
> >
>