- From: Brad Hill <hillbrad@gmail.com>
- Date: Tue, 4 Nov 2014 15:11:04 -0800
- To: Anne van Kesteren <annevk@annevk.nl>
- Cc: Hatter Jiang <jht5945@gmail.com>, WebAppSec WG <public-webappsec@w3.org>
We discussed this issue at TPAC and decided to postpone any resolution to CSP Level 3. Minutes of the discussion are available at http://www.w3.org/2014/10/27-webappsec-minutes.html#item11 And it is tracked by ISSUE-68: https://www.w3.org/2011/webappsec/track/issues/68 -Brad Hill On Sat, Aug 9, 2014 at 3:42 AM, Anne van Kesteren <annevk@annevk.nl> wrote: > On Fri, Aug 8, 2014 at 3:04 PM, Hatter Jiang <jht5945@gmail.com> wrote: >> <img src="http://www.example.com/cookie-mapping-pixel.jpg?cookie-id=123456"> >> >> But when `www.example.com` was hacked, the server return `401` HTTP header, >> then the browser will popup a window let the user input username and >> password, and the user may not know the username and password is needed by >> `www.example.com` not from your website.In our website, we never use 401 >> auth. >> >> So can we add the CSP like: >> >> http-auth: block; >> >> Then the browser see this policy, when the resource require 401 auth, this >> request can be blocked. >> >> I think many sites need feature like this. > > Control over whether an authentication response causes a dialog is > something we want to offer (perhaps also through CSP, makes sense). > I'm not sure if we want to an authentication response to cause a > network error. That seems like an orthogonal feature. > > > -- > http://annevankesteren.nl/ >
Received on Tuesday, 4 November 2014 23:11:31 UTC