- From: Erlend Oftedal <eoftedal@gmail.com>
- Date: Thu, 13 Sep 2012 22:12:44 -0700
- To: Fred Andrews <fredandw@live.com>, Adam Barth <w3c@adambarth.com>
- Cc: "public-webappsec@w3.org" <public-webappsec@w3.org>
probing and to avoid content being written to depend on CSP.
MIME-Version: 1.0
Content-Type: multipart/alternative;
boundary="_6c3e02be-998b-456a-b7ce-c921f78c42e9_"
--_6c3e02be-998b-456a-b7ce-c921f78c42e9_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
But is there really a way of removing the possibility of detecting if
CSP is implemented? The website could always just have the browser
visit some pages with CSP enabled and see which requests come through.
Erlend
From: Fred Andrews
Sent: 14.09.2012 02:47
To: Adam Barth
Cc: public-webappsec@w3.org
Subject: RE: CSP 1.0: relaxing mandated enforcing and monitoring to
avoid probing and to avoid content being written to depend on CSP.
> From: w3c@adambarth.com
> Date: Thu, 13 Sep 2012 08:46:30 -0700
> Subject: Re: CSP 1.0: relaxing mandated enforcing and monitoring to avoid probing and to avoid content being written to depend on CSP.
> To: fredandw@live.com
> CC: public-webappsec@w3.org
>
> It's not a security or privacy problem to make UA features detectable.
Browser fingerprinting exploits information about the UA to identify
users, see: https://en.wikipedia.org/wiki/Device_fingerprint
Fingerprinting is a privacy issue because it identifies users and this
can be used for
tracking etc. Privacy is a concern for many users, so fingerprinting
is a concern for
many users.
> In fact, that's commonly a goal of new features. In CSP 1.1, we plan
> to add an explicit mechanism for the server to detect which CSP
> features the UA supports.
Is there a compelling need for the server to be able to detect CSP?
I suggest removing this mechanism for detecting CSP features.
> If you follow your line of reason, then all UA requirements in all
> specs would be downgraded from MUST to SHOULD. That's not how we
> write specs in the W3C. The important thing to realize is that UAs
> are not required to implement CSP at all. The requirements in the
> spec apply only if the UA chooses to implement CSP. If a UA does
> implement CSP, the UA MUST do various things, including actually
> enforcing the policies.
Specs have different purposes. Some specs are written for interoperability
and may really need MUST specified. However the CSP is a protection
mechanism implemented by the UA, and it need not impact the server
which features, if any, the UA decides to implement.
Perhaps the spec could be reworded as "for the UA to take full advantage
of the content restrictions declared by the server it MUST ..." This gives
the UA room to not implement all checks with the knowledge that it would
not be taking advantage of all restrictions. Such wording may help ensure
that compatible servers and content is not written to depend on the UA
checking and reporting all declared restrictions.
Consider the reporting. We want the UA to send a report in the correct
format so 'MUST' is appropriate for the report format. However, users may
have a privacy concern about the reporting and wish to disable it and this
need have no impact on the server so this could be SHOULD or MAY.
cheers
Fred
--_6c3e02be-998b-456a-b7ce-c921f78c42e9_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
<html><head><meta content=3D"text/html; charset=3Dutf-8" http-equiv=3D"Cont=
ent-Type"></head><body><div><div style=3D"font-family: Calibri,sans-serif; =
font-size: 11pt;">But is there really a way of removing the possibility of =
detecting if CSP is implemented? The website could always just have the bro=
wser visit some pages with CSP enabled and see which requests come through.=
<br><br>Erlend<br></div></div><hr><span style=3D"font-family: Tahoma,sans-s=
erif; font-size: 10pt; font-weight: bold;">From: </span><span style=3D"font=
-family: Tahoma,sans-serif; font-size: 10pt;">Fred Andrews</span><br><span =
style=3D"font-family: Tahoma,sans-serif; font-size: 10pt; font-weight: bold=
;">Sent: </span><span style=3D"font-family: Tahoma,sans-serif; font-size: 1=
0pt;">14.09.2012 02:47</span><br><span style=3D"font-family: Tahoma,sans-se=
rif; font-size: 10pt; font-weight: bold;">To: </span><span style=3D"font-fa=
mily: Tahoma,sans-serif; font-size: 10pt;">Adam Barth</span><br><span style=
=3D"font-family: Tahoma,sans-serif; font-size: 10pt; font-weight: bold;">Cc=
: </span><span style=3D"font-family: Tahoma,sans-serif; font-size: 10pt;">p=
ublic-webappsec@w3.org</span><br><span style=3D"font-family: Tahoma,sans-se=
rif; font-size: 10pt; font-weight: bold;">Subject: </span><span style=3D"fo=
nt-family: Tahoma,sans-serif; font-size: 10pt;">RE: CSP 1.0: relaxing manda=
ted enforcing and monitoring to avoid probing and to avoid content be=
ing written to depend on CSP.</span><br><br></body></html><html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 12pt;
font-family:Calibri
}
--></style></head>
<body class=3D'hmmessage'><div dir=3D'ltr'><br><div><div id=3D"SkyDrivePlac=
eholder"></div>> From: w3c@adambarth.com<br>> Date: Thu, 13 Sep 2012 =
08:46:30 -0700<br>> Subject: Re: CSP 1.0: relaxing mandated enforcing an=
d monitoring to avoid probing and to avoid content being written to depend =
on CSP.<br>> To: fredandw@live.com<br>> CC: public-webappsec@w3.org<b=
r>> <br>> It's not a security or privacy problem to make UA features =
detectable.<br><br>Browser fingerprinting exploits information about the UA=
to identify users, see: https://en.wikipedia.org/wiki/Device_fingerprint<b=
r>
<br>Fingerprinting is a privacy issue because it identifies users and this =
can be used for<br>tracking etc. Privacy is a concern for many users,=
so fingerprinting is a concern for<br>many users.<br><br>> In fact, th=
at's commonly a goal of new features. In CSP 1.1, we plan<br>> to add a=
n explicit mechanism for the server to detect which CSP<br>> features th=
e UA supports.<br><br>Is there a compelling need for the server to be able =
to detect CSP?<br><br>I suggest removing this mechanism for detecting CSP f=
eatures.<br> <br>> If you follow your line of reason, then all UA r=
equirements in all<br>> specs would be downgraded from MUST to SHOULD. =
That's not how we<br>> write specs in the W3C. The important thing to r=
ealize is that UAs<br>> are not required to implement CSP at all. The r=
equirements in the<br>> spec apply only if the UA chooses to implement C=
SP. If a UA does<br>> implement CSP, the UA MUST do various things, inc=
luding actually<br>> enforcing the policies.<br><br>Specs have different=
purposes. Some specs are written for interoperability<br>and may rea=
lly need MUST specified. However the CSP is a protection<br>mechanism=
implemented by the UA, and it need not impact the server<br>which fe=
atures, if any, the UA decides to implement.<br><br>Perhaps the spec could =
be reworded as "for the UA to take full advantage<br>of the content restric=
tions declared by the server it MUST ..." This gives<br>the UA room t=
o not implement all checks with the knowledge that it would<br>not be takin=
g advantage of all restrictions. Such wording may help ensure<br>that=
compatible servers and content is not written to depend on the UA<br>check=
ing and reporting all declared restrictions.<br><br>Consider the reporting.=
We want the UA to send a report in the correct<br>format so 'MUST' i=
s appropriate for the report format. However, users may<br>have a pri=
vacy concern about the reporting and wish to disable it and this<br>need ha=
ve no impact on the server so this could be SHOULD or MAY.<br><br>cheers<br=
>Fred<br><br></div> =09=09 =09 =09=09 </div></body>
</html>
--_6c3e02be-998b-456a-b7ce-c921f78c42e9_--
Received on Friday, 14 September 2012 05:13:15 UTC