- From: Brad Hill <hillbrad@gmail.com>
- Date: Fri, 31 Oct 2014 01:29:56 -0700
- To: Anne van Kesteren <annevk@annevk.nl>
- Cc: Mike West <mkwst@google.com>, WebAppSec WG <public-webappsec@w3.org>
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. Over in the UI Security spec, for example, we explicitly state that for some directives the user MUST have the ability to disable them if they interfere with accessibility tools. We also don't want CSP to be seen as part of an architecture of control, or DRM-like. That's not what it is intended to be. It provides attack surface reduction against third parties, not first parties. On Fri, Oct 31, 2014 at 12:50 AM, Anne van Kesteren <annevk@annevk.nl> wrote: > On Thu, Oct 30, 2014 at 8:43 PM, Brad Hill <hillbrad@gmail.com> wrote: >> Should the subject of this thread reference CSP rather than MIX? > > Perhaps. I thought it could be called out here since this is > explicitly talking about user controls. > > >> I believe we want to leave it that way. (saying nothing and leaving >> this choice to user agents) > > Really? That sounds super bad. If my security policy blocks something, > I don't want users to have the option to make themselves vulnerable. > > > -- > https://annevankesteren.nl/
Received on Friday, 31 October 2014 08:30:24 UTC