- From: Maciej Stachowiak <mjs@apple.com>
- Date: Mon, 19 Apr 2010 01:03:14 -0700
- To: Julian Reschke <julian.reschke@gmx.de>
- 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>
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 UTC