Re: corscheck

I'm still not so sure it's safe in the simplest case. The javascript
(attacker) can choose to send user credentials including cookies. This
seems risky in general, and I would think that encouraging even
minimal use of CORS could lead to trouble, perhaps not directly
related to the problem you thought you were solving. Maybe it is
sometimes safe in this particular situation (promise there are no
credentials set or used at the site!), but a few WG members think it's
dangerous and as I say it hasn't gotten proper review. You're playing
with fire.

Related: http://codebutler.com/firesheep

Jonathan

On Tue, Nov 9, 2010 at 4:19 PM, Nathan <nathan@webr3.org> wrote:
> Michael Hausenblas wrote:
>>
>> Hmmmm. I guess what we want to communicate and advocate for (and I agree
>> we
>> could make this even more explicit) is: IF you have open (==publically
>> available) data, use CORS and *not* use CORS for everything no matter
>> what.
>
> Perhaps we just need to focus on Access-Control-Allow-Origin then, because
> that is in CORS and UMP, and XMLHttpRequest and XDomainRequest, and thus -
> everywhere, and indeed it's the only one stable bit of all of this which is
> in all specs and supported at web-scale.
>
> That's all we require for "read", and all that's required for linked data,
> so perhaps some nice wording around Access-Control-Allow-Origin together
> with a disclaimer that "cors" is referenced because it's the most well known
> spec.
>
> The message remains the same, while being pre-cr compatible.
>
> Sound Okay?
>
> ps: would that be enough of a reason to warrant adding support on w3.org
> vocabs?
>
> pps: don't think I can post to awwsw, hence you may have to fwd as
> appropriate.
>
> Best,
>
> Nathan
>

Received on Tuesday, 9 November 2010 22:19:17 UTC