Re: [ac] wildcard rules and subdomains

The P3P folks would disagree with your characterisation of uptake  
(e.g., <http://lorrie.cranor.org/pubs/icec06.pdf>). I'm staying out  
of it :)


On 2007/07/04, at 12:45 PM, Jonas Sicking wrote:

>
> 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
>
>

--
Mark Nottingham       mnot@yahoo-inc.com

Received on Wednesday, 4 July 2007 05:27:17 UTC