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: Tyler Close <tyler.close@gmail.com>
Date: Mon, 19 Apr 2010 11:30:34 -0700
Message-ID: <m2m5691356f1004191130qbf9e2f35pbdb9dc10a90d1ab4@mail.gmail.com>
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.


"Waterken News: Capability security on the Web"
Received on Monday, 19 April 2010 18:31:07 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:24 UTC