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

On Wed, Jul 7, 2010 at 5:53 PM, Charlie Reis <creis@chromium.org> wrote:
> 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?

I believe we have discussed this in the past and been uncertain as to
whether or not this would break things on the web; we have very little
real-world data as to how CORS is currently being used (if at all). I
think I mentioned the possibility of instrumenting Chrome to look into
this, but haven't yet done so.

-- Dirk

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

Received on Thursday, 8 July 2010 01:55:24 UTC