Thanks for the explanations, Andrew. Most of this makes sense now. Also, I liked your comments.
We've noticed up to 30% performance slow down by disabling eval through CSP in angular and other popular frameworks. I'm concerned in not adding 'unsafe-eval' as the default. We should add it to the default policy and expect the developers to make the choice consciously to remove it. Thanks, Nikhil -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Andrew Grieve Sent: Thursday, March 12, 2015 10:47 AM To: Andrew Grieve Cc: dev Subject: Re: CSP policy Added comment with these points to the template. On Wed, Mar 11, 2015 at 9:37 PM, Andrew Grieve <[email protected]> wrote: > Great questions! Certainly was hoping to get more eyes on this! > > Not sure where a good spot to document this is, but maybe right in the > template is okay? That way users will also know the rationale :) > > > > On Wed, Mar 11, 2015 at 2:04 PM, Nikhil Khandelwal > <[email protected] > > wrote: > >> Thanks for bringing this to notice. Forking the thread for better >> understanding of the default CSP policy. Can you provide more details >> of the rationale behind this CSP policy? >> <meta http-equiv="Content-Security-Policy" >> content="default-src 'self' data: gap: >> https://ssl.gstatic.com/accessibility/javascript/android/; style-src >> 'self' 'unsafe-inline'; media-src: *"> >> >> Few specific questions: >> - 'gap:' - could not find documentation on this - what does this mean? >> > Needed only on iOS, because it navigates iframes to that URL for it's > exec() bridge. > > >> - Why is https://ssl.gstatic.com/accessibility/javascript/android/ >> URL there for all platforms? Why is it even needed for Android? >> > Needed only on Android and is needed (crazily) to not break TalkBack > (screen reader). Note that CSP right now ignores paths, so that > actually has the effect of whitelisting all of ssl.gstatic.com > > >> - 'unsafe-eval' is not present - does that mean evals do not work. I >> know a number of templating libraries depend on this. >> > Correct. My thinking here is that both FFOS and Chrome Apps both > decided that this is a good policy for packaged apps with access to > "dangerous" > APIs, and so it would make a good default for us as well. > > >> >> Thanks, >> Nikhil >> >> >> -----Original Message----- >> From: [email protected] [mailto:[email protected]] On Behalf Of >> Andrew Grieve >> Sent: Wednesday, March 11, 2015 7:16 AM >> To: dev >> Subject: Re: [Vote] 3.8.0 Cordova App Hello World Release >> >> Note that this pulls in the addition of a content-security-policy >> <meta> tag. >> Please ensure that this doesn't break your platform when voting. >> >> On Tue, Mar 10, 2015 at 7:30 PM, Steven Gill <[email protected]> >> wrote: >> >> > Please review and vote on this 3.8.0 Cordova App Hello World Release. >> > >> > Release issue: https://issues.apache.org/jira/browse/CB-8645 >> > >> > Repos ready to be released have been published to >> > dist/dev:https://dist.apache.org/repos/dist/dev/cordova/CB-8645 >> > >> > The package was published from its corresponding git tag: >> > cordova-app-hello-world: 3.8.0 (0b55140d09) >> > >> > Upon a successful vote I will upload the archive to dist/ and >> > publish it to NPM. >> > >> > Voting guidelines: >> > https://github.com/apache/cordova-coho/blob/master/docs/release-vot >> > ing >> > .md >> > >> > Voting will go on for a minimum of 48 hours. >> > >> > I vote +1: >> > * Ran coho audit-license-headers over the relevant repos >> > * Ran coho check-license to ensure all dependencies and >> > subdependencies have Apache-compatible licenses >> > * Built a hello world app using the CLI >> > >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
