I've attempted to deal with these questions in https://github.com/w3c/webappsec/commit/4a26ce0b4b52962e4813e2347978a0de07be3b3e (which is more readably presented at https://w3c.github.io/webappsec/specs/CSP2/. In particular, note the "Processing Complications" section at https://w3c.github.io/webappsec/specs/CSP2/#complications. WDYT? -mike -- Mike West <mkwst@google.com>, @mikewest Google Germany GmbH, Dienerstrasse 12, 80331 München, Germany, Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: Hamburg, Geschäftsführer: Graham Law, Christine Elizabeth Flores (Sorry; I'm legally required to add this exciting detail to emails. Bleh.) On Tue, Nov 18, 2014 at 10:11 AM, Anne van Kesteren <annevk@annevk.nl> wrote: > On Tue, Nov 18, 2014 at 3:52 AM, Deian Stefan <deian@cs.stanford.edu> > wrote: > > Brian Smith <brian@briansmith.org> writes: > >> Devdatta brought up the point last week that the CSP drafts do not say > >> that the browser MUST NOT issue the HTTP (or whatever) request when > >> they block a fetch due to CSP violation. That is, it is perfectly > >> legal to make the HTTP request (optionally caching it) and then ignore > >> it, according to the current wording in the CSP drafts. However, I > >> think this is a bug that should be fixed. > > > > +1 I think this should be fixed as well. > > This would be fixed by a Fetch-based rewrite, that's planned for > CSP3... Though note that due to service workers CSP will likely not be > able to prevent all fetches going forward (since service workers have > their own policy) and that therefore we're looking into blocking on > certain responses as well. > > > -- > https://annevankesteren.nl/ > >
Received on Friday, 16 January 2015 15:49:58 UTC