W3C home > Mailing lists > Public > public-webappsec@w3.org > November 2014

Re: [MIX] 4.5 User Controls

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>
Message-ID: <D07D01D3.A3E%hillbrad@fb.com>
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

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:54:07 UTC