- From: Tyler Close <tyler.close@gmail.com>
- Date: Mon, 19 Apr 2010 11:30:34 -0700
- To: Julian Reschke <julian.reschke@gmx.de>
- Cc: Maciej Stachowiak <mjs@apple.com>, Jonas Sicking <jonas@sicking.cc>, Ben Laurie <benl@google.com>, Arthur Barstow <Art.Barstow@nokia.com>, ext Anne van Kesteren <annevk@opera.com>, public-webapps <public-webapps@w3.org>
On Mon, Apr 19, 2010 at 10:55 AM, Julian Reschke <julian.reschke@gmx.de> wrote: > On 19.04.2010 19:37, Tyler Close wrote: >>>> >>>> The default members of the above whitelist include response entity >>>> headers defined by [HTTP], plus the Location and Warning headers. The >>> >>> Why are you ignoring other headers in the permanent registry? Why only >>> allow >>> entity headers? What the problem, for instance, with "Allow" (RFC 2616), >>> "Allow-Patch" (RFC 5749) or "Dav" (RFC 4918)? >> >> The default members of the whitelist define the minimum set of headers >> to allow. If the response entity is delivered, then at a minimum, the >> response entity headers should accompany it, assuming it is safe to do >> so. I manually vetted those headers. To support redirection, we need >> Location. Warning is needed in case the requesting content wants to >> reject stale responses. The server must then explicitly opt into >> anything beyond the minimum header set. > > Again: did you check all the headers in the permanent registry? If you did, > why are the ones (which are just examples) missing? And what's the reason to > default to strip general headers and response headers? Again, the model is to define a minimal whitelist and enable servers to explicitly extend the minimal whitelist. The default members of the whitelist only exist as a convenience, so that servers don't have to explicitly list them on every response. Also, asking a static specification to keep up with a mutable registry is not feasible. >>>> default part of the whitelist does not include: headers used for >>>> credential authentication, such as WWW-Authenticate; nor headers that >>>> might reveal private network configuration information, such as Via; >>> >>> What's the rational for stripping all of the information in Via? >> >> Are you suggesting UMP specify an algorithm for filtering out only >> some Via header values? > > I'm concerned that by simply dropping the header, you profile too much. It is not simply dropped, it can be enabled by any server or proxy in the request path. >>>> nor caching headers, such as Age, which provide explicit information >>>> about requests made on behalf of other requesting content. >>>> """ >>> >>> What's the problem with Age, please clarify? >> >> Content from one origin can tell exactly how long ago content from >> another origin requested the cached content. That's at least a privacy >> issue, and possibly a confidentiality issue. > > That appears to be an issue completely independently of CORS/UMP. It is not at all independent. There was no way to access the Age header cross-origin before CORS/UMP. If Age is allowed by default then any page can ask "What did you know and when did you know it?", which is, of course, a powerful question. > If that's > the case, it should be mentioned in the HTTPbis security considerations, Last I heard, HTTPbis punted on explaining anything to do with the Same Origin Policy security model that has evolved around HTTP. I asked them to and they refused. > but doesn't necessarily require blocking. Again, it's not blocked. It just requires an explicit opt-in. --Tyler -- "Waterken News: Capability security on the Web" http://waterken.sourceforge.net/recent.html
Received on Monday, 19 April 2010 18:31:07 UTC