W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2010

Re: CORS Last Call status/plans? [Was: Re: [UMP] Request for Last Call]

From: Maciej Stachowiak <mjs@apple.com>
Date: Mon, 19 Apr 2010 01:03:14 -0700
Cc: Ben Laurie <benl@google.com>, Tyler Close <tyler.close@gmail.com>, Arthur Barstow <Art.Barstow@nokia.com>, ext Anne van Kesteren <annevk@opera.com>, public-webapps <public-webapps@w3.org>
Message-id: <A3E7F60A-B12C-40E1-A0D7-4CCB86DFF219@apple.com>
To: Julian Reschke <julian.reschke@gmx.de>

On Apr 19, 2010, at 12:49 AM, Julian Reschke wrote:

> On 19.04.2010 09:41, Maciej Stachowiak wrote:
>> ...
>>> This obviously would be impossible if another layer (say proxies)
>>> would already block that.
>>
>> It wouldn't be impossible, it just wouldn't have the desired end-to- 
>> end
>> effect. But proxies are already not allowed to remove random response
>> headers.
>> ...
>
> Whatever the rule is for proxies should be the rule for a software  
> layer as well. What's relevant is the impact on the application.

Proxies have different security considerations than API exposed to  
client-side JavaScript. So it would not make sense for the rules to be  
the same.

>
>>> Don't do to others what you don't want to be done to yourself.
>>>
>>> Blacklist things when there is a problem.
>>
>> I think a whitelist with opt-in exceptions strikes the right balance
>> between security and extensibility. You haven't provided any  
>> reasons why
>> that's not good enough.
>
> I already did. If multiple layers blocked unknown response headers,  
> and each needed a separate way to opt them back in, we'd be in  
> trouble.

But that's not the case here. The blocking is solely at the API  
surface. No one is suggesting that proxies should block unknown  
response headers.

Regards,
Maciej
Received on Monday, 19 April 2010 08:03:50 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:38 GMT