I don't want to get into arguing about uptake either. A more important
point is however that for the p3p spec err on the side of including
fewer sites than expected is ok. The place where I see the syntax we're
using is used is section 2.3.2.6 of the p3p 1.0 spec. If the author
misses to add example.com in addition to *.example.com there will be no
security issues.
This is not the case in our spec, if the author misses adding example.com to
Content-Access-Control: deny <*.evil.com>
very bad things can happen.
An alternative solution is to remove the wildcard syntax entierly, and
say that it's implicitly always there. So
Content-Access-Control: deny <evil.com>, allow <good.com>
denies evil.com together with subdomains, while allowing good.com
together with subdomains.
/ Jonas
Mark Nottingham wrote:
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 [EMAIL PROTECTED]
--
Mark Nottingham [EMAIL PROTECTED]
