W3C home > Mailing lists > Public > public-appformats@w3.org > July 2007

Re: [ac] wildcard rules and subdomains

From: Jonas Sicking <jonas@sicking.cc>
Date: Tue, 03 Jul 2007 19:45:32 -0700
Message-ID: <468B09CC.9040906@sicking.cc>
To: Mark Nottingham <mnot@yahoo-inc.com>
CC: "WAF WG (public)" <public-appformats@w3.org>

Ah, that makes sence. Though given the very poor uptake of p3p I don't 
think that parity with it is very important. I'd prefer to do what is 
safest and easiest to use.

/ Jonas

Mark Nottingham wrote:
> 
> IIRC (and I could be remembering wrongly), it was done this way to align 
> with how p3p.xml, etc. work, so there wouldn't be multiple, 
> almost-the-same-but-conflicting standards out there.
> 
> Cheers,
> 
> 
> On 2007/07/04, at 10:35 AM, Jonas Sicking wrote:
> 
>>
>> Hi All,
>>
>> Currently the spec says that a rule like "*.example.com" does not 
>> match a request from example.com. The result is that if you want to 
>> give access to anything coming from example.com, including any 
>> subdomains, you'll have to write a rule like:
>>
>> Content-Access-Control: allow <*.example.com>, <example.com>
>>
>> And similarly, if you want to deny requests from evil.com you have to do:
>>
>> Content-Access-Control: deny <*.evil.com>, <evil.com>
>>
>> I think it would be better if *.example.com also matched example.com.
>>
>> Pros:
>> In many cases you can write simpler rules since I'd imagine it's more 
>> likely that you want to deny or grant access to both a domain and its 
>> subdomains, than that you just want one of the two.
>>
>> There's no longer a risk that someone will think that *.example.com 
>> does match example.com.
>>
>> Cons:
>> There's a risk that someone will think that *.example.com does not 
>> match example.com.
>>
>> I actually think that the consequences of misunderstanding is smaller 
>> in the latter case. Lets example the possible misunderstandings under 
>> the two algorithms:
>>
>>
>> == Current algorithm, *.example.com does not match example.com ==
>> Author uses the rule
>> Content-Access-Control: allow <*.example.com>
>> and thinks this grants access to example.com
>>
>> The consequences aren't very bad, the only thing that will happen is 
>> that when the site example.com is used things will not work. This is 
>> easily detectable and fixed
>>
>> Author uses the rule
>> Content-Access-Control: deny <*.example.com>
>> and thinks this denies access to example.com
>>
>> The consequences are bad. Access is not denied to example.com even 
>> though that was intended.
>>
>> == Proposed algorithm, *.example.com does match example.com ==
>> Author uses the rule
>> Content-Access-Control: allow <*.example.com>
>> and thinks this does not grant access to example.com
>>
>> The consequences are somewhat bad, access is granted to example.com 
>> even though that was not intended. However, it is likely that however 
>> runs example.com could simply set up foo.example.com and use that to 
>> get access. In general I can't think of a real-world example where 
>> you'd trust the subdomains of a site, but not the top domain.
>>
>> Author uses the rule
>> Content-Access-Control: deny <*.example.com>
>> and thinks this does not deny access to example.com
>>
>> The consequences aren't very bad, the only thing that will happen is 
>> that when the site example.com is used things will not work. This is 
>> easily detectable and fixed.
>>
>> / Jonas
>>
> 
> -- 
> Mark Nottingham       mnot@yahoo-inc.com
> 
> 
Received on Wednesday, 4 July 2007 02:46:03 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:50:07 UTC