- From: Sigbjørn Vik <sigbjorn@opera.com>
- Date: Wed, 21 May 2014 17:25:24 +0200
- To: Daniel Veditz <dveditz@mozilla.com>, Mike West <mkwst@google.com>
- CC: Joel Weinberger <jww@chromium.org>, "Oda, Terri" <terri.oda@intel.com>, Michal Zalewski <lcamtuf@coredump.cx>, Egor Homakov <homakov@gmail.com>, "public-webappsec@w3.org" <public-webappsec@w3.org>, Eduardo' Vela <evn@google.com>
On 21-May-14 17:02, Daniel Veditz wrote: > On 5/20/2014 7:18 AM, Sigbjørn Vik wrote: >> However, I do not think I will be able to convince you to support the >> alternative proposal of dropping error reporting instead, even if that >> from a security point of view is better. > > I'm not convinced error reporting is the problem, though--the fact that > it's blocked is. Can't you detect whether something got blocked through > onload/onerror entirely within the attack page? Correct. So the browser would have to pretend the page loaded (in the same way it would have done without CSP), regardless of whether it was blocked or not. This is not trivial to implement, it is essentially what the same origin policy does; avoid leaking information between unrelated origins. > That said, I'd almost be happy to consider dropping reporting because I > think the flood of false-positive reports people get when they use it > prevents people from deploying CSP. :) Error reporting does have its uses, and given that it already has implementations, it should be possible to make it available for users who are so inclined. For instance through an extension API. -- Sigbjørn Vik Opera Software
Received on Wednesday, 21 May 2014 15:25:55 UTC