On 12/08/09 00:11, Ian Hickson wrote:
> I think in almost all cases, multiple headers will be a sign of an attack
> or error, not the sign of cooperation.
OK. I think that's a fair challenge. Can someone come up with a
plausible and specific scenario where multiple headers would be useful?
The ones that come immediately to my mind are where the ISP would want a
strict general policy but might allow customers to loosen it on a
site-by-site basis (e.g. allowing media from a particular site). But
that can't be achieved by multiple headers anyway, because you get the
permissions intersection, not the union.
>> How do you expect them to do it?
>
> Copy-and-paste from sites that didn't understand the spec, for example
> copying from w3schools.com, and then modifying it more or less at random.
> Or copy-and-paste from some other site, without understanding what they're
> doing.
The fix for that seems to me to be good error reporting, both to the
server and in the browser. If their site doesn't work, we want them to
know why. If it does work, but it's because their policy is far too lax,
then they've gained little benefit - but if you try and deploy
technologies you don't understand, the best you can hope for is not to
shoot yourself in the foot.
> Making the spec shorter is a pretty important part of simplifying the
> language. The simpler the spec, the more people will be able to understand
> it, the fewer mistakes will occur.
I don't think people should be writing policies based on reading the
spec. People don't write HTML based on reading the HTML 4.01 spec - do
they? A spec has to give as much space to error conditions and corner
cases as it does the important, mainstream stuff. Whereas, a "How to
write a CSP policy" document can just talk about best practice and
common situations.
Gerv