- From: Brad Hill <hillbrad@fb.com>
- Date: Mon, 3 Nov 2014 18:19:43 +0000
- To: "Mike O'Neill" <michael.oneill@baycloud.com>, "'Brad Hill'" <hillbrad@gmail.com>
- CC: "'Anne van Kesteren'" <annevk@annevk.nl>, "'Mike West'" <mkwst@google.com>, "'WebAppSec WG'" <public-webappsec@w3.org>
We have a long established consensus in this group to not normatively surface any kind of user interactivity for CSP, a consensus which is _extremely_ unlikely to change without strong evidence from a practical implementation. Also, DNT and privacy compliance aren't use cases we're chartered to target in this WG. If you think CSP is the best way to accomplish your use cases, you could pursue them in an appropriately chartered group, e.g. The Tracking Protection WG, and reference, from a specification developed there, the Content Security Policy specification as an implementation technology. But you need to start with a clear high-level set of requirements and description of how users will accomplish the task. Just saying that users should be able to modify or set their own Content Security Policy and expecting that anyone will be able to do meaningfully accomplish their goals without much higher-level abstractions is extremely unrealistic. If I were you, I would start by building an extension, even if you don't think it's the correct long-term solution. They're a great way to prototype the experiences you're advocating, prove they are correct, usable and will be used by the community, and build consensus towards chartering work on standardization. And if you donšt succeed in building consensus for standardization, you will still have built something useful to the interested members of the community, even if it's not universally available. -Brad On 11/3/14, 6:25 AM, "Mike O'Neill" <michael.oneill@baycloud.com> wrote: >-----BEGIN PGP SIGNED MESSAGE----- >Hash: SHA1 > >Hi Mike, > >Browser extensions or other intermediaries can break CSP so it is not a >good idea to encourage them to enable improvements. Anyway they are >usually not available for mobile UAs. > >There is a very large use-case for European e-privacy and data protection >compliance, and there could easily eventually also be for DNT IMO. > >Mike > > > > >> -----Original Message----- >> From: Brad Hill [mailto:hillbrad@gmail.com] >> Sent: 03 November 2014 02:17 >> To: Mike O'Neill >> Cc: Anne van Kesteren; Mike West; WebAppSec WG >> Subject: Re: [MIX] 4.5 User Controls >> >> Mike, there are a number of extensions (browser-specific) that allow >> setting (or adding) user specified content security policies. >> Certainly the spec doesn't forbid this, either. >> >> See, e.g. "User CSP" on Firefox and "Caspr: Enforcer" and "Content >> Security Policy Modifier" for Chrome. >> >> I doubt there is much interest in directly providing this as a core >> user-agent feature given the likely size of the audience for this kind >> of feature. >> >> -Brad >> >> On Fri, Oct 31, 2014 at 2:20 AM, Mike O'Neill >> <michael.oneill@baycloud.com> wrote: >> > -----BEGIN PGP SIGNED MESSAGE----- >> > Hash: SHA1 >> > >> > Has there been any consideration for UA settings being able to make >>the CSP >> more restrictive? Like using the presence of a DNT header or an opt-in >>cookie? >> Something like >> > >> > script-src adco.fr[dnt:0] scriptlib.com; >> > >> > adco.fr only gets allowed if DNT:0 is present. >> > >> > Or for an opt-in cookie: >> > >> > script-src adco.fr[cookie:consent=yes] scriptlib.com; >> > >> > Mike O'Neill >> > >> > >> >> -----Original Message----- >> >> From: annevankesteren@gmail.com [mailto:annevankesteren@gmail.com] >> On >> >> Behalf Of Anne van Kesteren >> >> Sent: 31 October 2014 08:35 >> >> To: Brad Hill >> >> Cc: Mike West; WebAppSec WG >> >> Subject: Re: [MIX] 4.5 User Controls >> >> >> >> On Fri, Oct 31, 2014 at 9:29 AM, Brad Hill <hillbrad@gmail.com> >>wrote: >> >> > I don't want users to be socially engineered into attacking >> >> > themselves, either, but we respect the priority of constituencies. >> In >> >> > the end, it is the user's agent, not the resource's. UAs can make >> >> > choices to warn users or make it difficult to do harm to >>themselves, >> >> > and some might not provide any affordances around CSP, but I don't >> >> > think it's appropriate to add normative text forbidding the user to >> >> > modify CSP. >> >> >> >> I guess that's fair. But then I think I stand by my request to make >>it >> >> clear in MIX that not all blocked fetches are equal and that you >> >> probably don't want to use the same UI to cater to e.g. CSP and MIX. >> >> Or MIX could simply not say anything about user control either... >> >> >> >> >> >> -- >> >> https://annevankesteren.nl/ >> > >> > -----BEGIN PGP SIGNATURE----- >> > Version: GnuPG v1.4.13 (MingW32) >> > Comment: Using gpg4o v3.3.26.5094 - http://www.gpg4o.com/ >> > Charset: utf-8 >> > >> > >> iQEcBAEBAgAGBQJUU1RvAAoJEHMxUy4uXm2JiJoH/2SvDAlZ2LOiVXwsxeANxeO >> V >> > PqplSOSp+2vPDx0eGsiZLnMLCLbhLHVaj8b4HTzvQiKL1v31HTVi/ybiEY/DOta9 >> > >> o/r7GX9eqoUT3vH4W4h3b2CFGdVP8KTSTUa0Xd9pHXUs13zfUGElHXcR1G/UQpJ >> C >> > KY3d3ygJ13/Usn1dSeJ6ik+C6SNlTUlCTjst2YgNxEiNJYgREuymbABlp4kQ34yO >> > >> tSWUBWounprP1JSwM6VSb7YTMCkBLs6xgJlc2pl26344iWadBNzEzXhkdN+VdZh2 >> > >> Ff5m0v7GXNfYHNh7RvmOBYv1d7FOF739QKlOFz+X+K+rLUbJcpL+yluNl29MI94= >> > =9uxZ >> > -----END PGP SIGNATURE----- >> > > >-----BEGIN PGP SIGNATURE----- >Version: GnuPG v1.4.13 (MingW32) >Comment: Using gpg4o v3.3.26.5094 - http://www.gpg4o.com/ >Charset: utf-8 > >iQEcBAEBAgAGBQJUV5B0AAoJEHMxUy4uXm2JrswH/A4HMbAkfydtd7x2OGQtzpB+ >Ywo5hAbLGWUEs1KCuGy2mb2+jQyY64o+SC6xq6tpmsPQh9oigGbPa+ueAPrPgXOG >9hfjfJDRrO6/NZY/e8ceNL8aZNX7NM6i3Rn908JyvKKh9B3jWoifh31tYm/tXKoy >5dxCY5odCVAj3BnLrkDFfDNL+vdcIk0UyDJsX+klaVeyLVS6lHA7p9pvEZDs1R8P >MgLfh//W7kh20J4UOEY9Lo6kt2VB8F9dgXdnw9sZyP4gE+uogOHNdZDfWvCq93Hv >azCXU6yu6oO1QUlVjYHt3WaOa224jcfjOXtBZB6XeaPDrT5KhVMtShybtoXrMDc= >=g+KD >-----END PGP SIGNATURE----- > >
Received on Monday, 3 November 2014 18:20:13 UTC