Re: Android's new Whitelist Plugins
Hey Andrew, I don't see the new plugins in coho yet. Did you forget to push them? On Wed, Mar 11, 2015 at 7:35 AM, Andrew Grieve agri...@chromium.org wrote: Done! They are now alive at their now spots and added to coho's plugins list. On Thu, Mar 5, 2015 at 3:49 PM, Jesse purplecabb...@gmail.com wrote: +1 better late than never @purplecabbage risingj.com On Thu, Mar 5, 2015 at 12:39 PM, Andrew Grieve agri...@chromium.org wrote: Going with it: https://issues.apache.org/jira/browse/INFRA-9238 On Wed, Mar 4, 2015 at 11:22 PM, Michal Mocny mmo...@chromium.org wrote: +1 to names. On Wed, Mar 4, 2015 at 9:03 PM, Andrew Grieve agri...@chromium.org wrote: No comments about the names yet, but I'm now leaning towards: cordova-plugin-legacy-whitelist and cordova-plugin-whitelist as the two new git repos to create (rather than url-policy) On Wed, Mar 4, 2015 at 8:49 PM, Andrew Grieve agri...@chromium.org wrote: I think how Cordova works right now was the best way. Have access blocked by default, but have a access origin=*/ in the default template. It makes the setting visible, while still working out-of-the-box. If we turned on requests when no whitelist plugin is installed, then existing apps that have access tags will have their whitelist removed with 4.0.0 and not know it. If someone updates and their app can't hit the network anymore, then I think Stack Overflow will tell them why pretty quickly. We should also be very clear in the release notes and upgrade guide. On Wed, Mar 4, 2015 at 7:54 PM, Nikhil Khandelwal nikhi...@microsoft.com wrote: I like Ian's proposal of blocking network access only when a whitelist plugin is added to do so and is choosing to override the default behavior. Scanning config.xml on upgrade might be a good way to warn devs to refer them to use this plugin. These changes should also be documented in the migration guide from Android 3.x to 4.0. Thanks, Nikhil -Original Message- From: Jesse [mailto:purplecabb...@gmail.com] Sent: Wednesday, March 4, 2015 11:05 AM To: dev@cordova.apache.org Subject: Re: Android's new Whitelist Plugins I like the defaults as discussed, regardless of how they are achieved. ie. network yes, intents no This is similar to how a plain webview works if you add it to a native app on ios or android, at least the network part, not sure what the default intent handling is. Are there portions of this functionality that make more sense as part of the platform native code? To me a plugin that is installed by default is just modular platform code. Is there ever a reason to NOT want this plugin, versus just opening up access? @purplecabbage risingj.com On Wed, Mar 4, 2015 at 9:37 AM, Michal Mocny mmo...@chromium.org wrote: I've been working on adding support to just install the whitelist plugin by default, and to add the access origin=* to the default app. Is that sufficient? I think we may still need to do what Ian suggests and prompt on upgrade (or prepare)? For downstreams, especially IDE based ones, they will need to make sure the plugin is added by default however they do that. On Wed, Mar 4, 2015 at 12:06 PM, Ian Clelland iclell...@chromium.org wrote: On Tue, Mar 3, 2015 at 8:20 PM, Nikhil Khandelwal nikhi...@microsoft.com wrote: Here are my thoughts on the default behavior: - navigation should be disabled. - XHR network request should be enabled. And application launch through intent URLs should also be disabled. (IMO) That's not a bad default -- it enables CSP usage by default, which I think is good. It also (I think) means we're giving up on suggesting that network requests can be completely blocked by default, because that's definitely not the case on Android. We can implement this within the new framework: there is the idea of a 'default policy' that only comes into effect when no plugins take responsibility for the whitelist. As soon as any plugin, though, handles the shouldAllowRequest() call, for instance, the default policy is no longer in effect, and it is a true whitelist (block-by-default) My biggest concern with this is that developers are going to blindly update to Cordova 4.0.0, and when their app *just works*, they are not going to realize
Re: Android's new Whitelist Plugins
yes... yes I did... :) Pushed now. On Wed, Mar 11, 2015 at 5:49 PM, Steven Gill stevengil...@gmail.com wrote: Hey Andrew, I don't see the new plugins in coho yet. Did you forget to push them? On Wed, Mar 11, 2015 at 7:35 AM, Andrew Grieve agri...@chromium.org wrote: Done! They are now alive at their now spots and added to coho's plugins list. On Thu, Mar 5, 2015 at 3:49 PM, Jesse purplecabb...@gmail.com wrote: +1 better late than never @purplecabbage risingj.com On Thu, Mar 5, 2015 at 12:39 PM, Andrew Grieve agri...@chromium.org wrote: Going with it: https://issues.apache.org/jira/browse/INFRA-9238 On Wed, Mar 4, 2015 at 11:22 PM, Michal Mocny mmo...@chromium.org wrote: +1 to names. On Wed, Mar 4, 2015 at 9:03 PM, Andrew Grieve agri...@chromium.org wrote: No comments about the names yet, but I'm now leaning towards: cordova-plugin-legacy-whitelist and cordova-plugin-whitelist as the two new git repos to create (rather than url-policy) On Wed, Mar 4, 2015 at 8:49 PM, Andrew Grieve agri...@chromium.org wrote: I think how Cordova works right now was the best way. Have access blocked by default, but have a access origin=*/ in the default template. It makes the setting visible, while still working out-of-the-box. If we turned on requests when no whitelist plugin is installed, then existing apps that have access tags will have their whitelist removed with 4.0.0 and not know it. If someone updates and their app can't hit the network anymore, then I think Stack Overflow will tell them why pretty quickly. We should also be very clear in the release notes and upgrade guide. On Wed, Mar 4, 2015 at 7:54 PM, Nikhil Khandelwal nikhi...@microsoft.com wrote: I like Ian's proposal of blocking network access only when a whitelist plugin is added to do so and is choosing to override the default behavior. Scanning config.xml on upgrade might be a good way to warn devs to refer them to use this plugin. These changes should also be documented in the migration guide from Android 3.x to 4.0. Thanks, Nikhil -Original Message- From: Jesse [mailto:purplecabb...@gmail.com] Sent: Wednesday, March 4, 2015 11:05 AM To: dev@cordova.apache.org Subject: Re: Android's new Whitelist Plugins I like the defaults as discussed, regardless of how they are achieved. ie. network yes, intents no This is similar to how a plain webview works if you add it to a native app on ios or android, at least the network part, not sure what the default intent handling is. Are there portions of this functionality that make more sense as part of the platform native code? To me a plugin that is installed by default is just modular platform code. Is there ever a reason to NOT want this plugin, versus just opening up access? @purplecabbage risingj.com On Wed, Mar 4, 2015 at 9:37 AM, Michal Mocny mmo...@chromium.org wrote: I've been working on adding support to just install the whitelist plugin by default, and to add the access origin=* to the default app. Is that sufficient? I think we may still need to do what Ian suggests and prompt on upgrade (or prepare)? For downstreams, especially IDE based ones, they will need to make sure the plugin is added by default however they do that. On Wed, Mar 4, 2015 at 12:06 PM, Ian Clelland iclell...@chromium.org wrote: On Tue, Mar 3, 2015 at 8:20 PM, Nikhil Khandelwal nikhi...@microsoft.com wrote: Here are my thoughts on the default behavior: - navigation should be disabled. - XHR network request should be enabled. And application launch through intent URLs should also be disabled. (IMO) That's not a bad default -- it enables CSP usage by default, which I think is good. It also (I think) means we're giving up on suggesting that network requests can be completely blocked by default, because that's definitely not the case on Android. We can implement this within the new framework: there is the idea of a 'default policy' that only comes into effect when no plugins take responsibility for the whitelist. As soon as any plugin, though, handles the shouldAllowRequest() call, for instance
Re: Android's new Whitelist Plugins
+1 better late than never @purplecabbage risingj.com On Thu, Mar 5, 2015 at 12:39 PM, Andrew Grieve agri...@chromium.org wrote: Going with it: https://issues.apache.org/jira/browse/INFRA-9238 On Wed, Mar 4, 2015 at 11:22 PM, Michal Mocny mmo...@chromium.org wrote: +1 to names. On Wed, Mar 4, 2015 at 9:03 PM, Andrew Grieve agri...@chromium.org wrote: No comments about the names yet, but I'm now leaning towards: cordova-plugin-legacy-whitelist and cordova-plugin-whitelist as the two new git repos to create (rather than url-policy) On Wed, Mar 4, 2015 at 8:49 PM, Andrew Grieve agri...@chromium.org wrote: I think how Cordova works right now was the best way. Have access blocked by default, but have a access origin=*/ in the default template. It makes the setting visible, while still working out-of-the-box. If we turned on requests when no whitelist plugin is installed, then existing apps that have access tags will have their whitelist removed with 4.0.0 and not know it. If someone updates and their app can't hit the network anymore, then I think Stack Overflow will tell them why pretty quickly. We should also be very clear in the release notes and upgrade guide. On Wed, Mar 4, 2015 at 7:54 PM, Nikhil Khandelwal nikhi...@microsoft.com wrote: I like Ian's proposal of blocking network access only when a whitelist plugin is added to do so and is choosing to override the default behavior. Scanning config.xml on upgrade might be a good way to warn devs to refer them to use this plugin. These changes should also be documented in the migration guide from Android 3.x to 4.0. Thanks, Nikhil -Original Message- From: Jesse [mailto:purplecabb...@gmail.com] Sent: Wednesday, March 4, 2015 11:05 AM To: dev@cordova.apache.org Subject: Re: Android's new Whitelist Plugins I like the defaults as discussed, regardless of how they are achieved. ie. network yes, intents no This is similar to how a plain webview works if you add it to a native app on ios or android, at least the network part, not sure what the default intent handling is. Are there portions of this functionality that make more sense as part of the platform native code? To me a plugin that is installed by default is just modular platform code. Is there ever a reason to NOT want this plugin, versus just opening up access? @purplecabbage risingj.com On Wed, Mar 4, 2015 at 9:37 AM, Michal Mocny mmo...@chromium.org wrote: I've been working on adding support to just install the whitelist plugin by default, and to add the access origin=* to the default app. Is that sufficient? I think we may still need to do what Ian suggests and prompt on upgrade (or prepare)? For downstreams, especially IDE based ones, they will need to make sure the plugin is added by default however they do that. On Wed, Mar 4, 2015 at 12:06 PM, Ian Clelland iclell...@chromium.org wrote: On Tue, Mar 3, 2015 at 8:20 PM, Nikhil Khandelwal nikhi...@microsoft.com wrote: Here are my thoughts on the default behavior: - navigation should be disabled. - XHR network request should be enabled. And application launch through intent URLs should also be disabled. (IMO) That's not a bad default -- it enables CSP usage by default, which I think is good. It also (I think) means we're giving up on suggesting that network requests can be completely blocked by default, because that's definitely not the case on Android. We can implement this within the new framework: there is the idea of a 'default policy' that only comes into effect when no plugins take responsibility for the whitelist. As soon as any plugin, though, handles the shouldAllowRequest() call, for instance, the default policy is no longer in effect, and it is a true whitelist (block-by-default) My biggest concern with this is that developers are going to blindly update to Cordova 4.0.0, and when their app *just works*, they are not going to realize that they are actually less secure than before. (Without a plugin, we've opened up all network access) Idea -- maybe we can scan config.xml -- at run time, or on prepare, or on upgrade -- and if we see any access tag other than access origin=* we can display a loud message, suggesting strongly that they install an appropriate plugin. Ian The plugin name is fine. I'm not convinced about a user having to add this plugin to enable network requests for Android/iOS. This default behavior should work with the platform and should not require a plugin
Re: Android's new Whitelist Plugins
Going with it: https://issues.apache.org/jira/browse/INFRA-9238 On Wed, Mar 4, 2015 at 11:22 PM, Michal Mocny mmo...@chromium.org wrote: +1 to names. On Wed, Mar 4, 2015 at 9:03 PM, Andrew Grieve agri...@chromium.org wrote: No comments about the names yet, but I'm now leaning towards: cordova-plugin-legacy-whitelist and cordova-plugin-whitelist as the two new git repos to create (rather than url-policy) On Wed, Mar 4, 2015 at 8:49 PM, Andrew Grieve agri...@chromium.org wrote: I think how Cordova works right now was the best way. Have access blocked by default, but have a access origin=*/ in the default template. It makes the setting visible, while still working out-of-the-box. If we turned on requests when no whitelist plugin is installed, then existing apps that have access tags will have their whitelist removed with 4.0.0 and not know it. If someone updates and their app can't hit the network anymore, then I think Stack Overflow will tell them why pretty quickly. We should also be very clear in the release notes and upgrade guide. On Wed, Mar 4, 2015 at 7:54 PM, Nikhil Khandelwal nikhi...@microsoft.com wrote: I like Ian's proposal of blocking network access only when a whitelist plugin is added to do so and is choosing to override the default behavior. Scanning config.xml on upgrade might be a good way to warn devs to refer them to use this plugin. These changes should also be documented in the migration guide from Android 3.x to 4.0. Thanks, Nikhil -Original Message- From: Jesse [mailto:purplecabb...@gmail.com] Sent: Wednesday, March 4, 2015 11:05 AM To: dev@cordova.apache.org Subject: Re: Android's new Whitelist Plugins I like the defaults as discussed, regardless of how they are achieved. ie. network yes, intents no This is similar to how a plain webview works if you add it to a native app on ios or android, at least the network part, not sure what the default intent handling is. Are there portions of this functionality that make more sense as part of the platform native code? To me a plugin that is installed by default is just modular platform code. Is there ever a reason to NOT want this plugin, versus just opening up access? @purplecabbage risingj.com On Wed, Mar 4, 2015 at 9:37 AM, Michal Mocny mmo...@chromium.org wrote: I've been working on adding support to just install the whitelist plugin by default, and to add the access origin=* to the default app. Is that sufficient? I think we may still need to do what Ian suggests and prompt on upgrade (or prepare)? For downstreams, especially IDE based ones, they will need to make sure the plugin is added by default however they do that. On Wed, Mar 4, 2015 at 12:06 PM, Ian Clelland iclell...@chromium.org wrote: On Tue, Mar 3, 2015 at 8:20 PM, Nikhil Khandelwal nikhi...@microsoft.com wrote: Here are my thoughts on the default behavior: - navigation should be disabled. - XHR network request should be enabled. And application launch through intent URLs should also be disabled. (IMO) That's not a bad default -- it enables CSP usage by default, which I think is good. It also (I think) means we're giving up on suggesting that network requests can be completely blocked by default, because that's definitely not the case on Android. We can implement this within the new framework: there is the idea of a 'default policy' that only comes into effect when no plugins take responsibility for the whitelist. As soon as any plugin, though, handles the shouldAllowRequest() call, for instance, the default policy is no longer in effect, and it is a true whitelist (block-by-default) My biggest concern with this is that developers are going to blindly update to Cordova 4.0.0, and when their app *just works*, they are not going to realize that they are actually less secure than before. (Without a plugin, we've opened up all network access) Idea -- maybe we can scan config.xml -- at run time, or on prepare, or on upgrade -- and if we see any access tag other than access origin=* we can display a loud message, suggesting strongly that they install an appropriate plugin. Ian The plugin name is fine. I'm not convinced about a user having to add this plugin to enable network requests for Android/iOS. This default behavior should work with the platform and should not require a plugin. This inhibits users from getting the ground running on a Cordova app. It breaks existing templates in IDEs and other downstream CLIs as well - as all of them need to include this plugin to have any network access work. Thanks, Nikhil
Re: Android's new Whitelist Plugins
On Tue, Mar 3, 2015 at 8:20 PM, Nikhil Khandelwal nikhi...@microsoft.com wrote: Here are my thoughts on the default behavior: - navigation should be disabled. - XHR network request should be enabled. And application launch through intent URLs should also be disabled. (IMO) That's not a bad default -- it enables CSP usage by default, which I think is good. It also (I think) means we're giving up on suggesting that network requests can be completely blocked by default, because that's definitely not the case on Android. We can implement this within the new framework: there is the idea of a 'default policy' that only comes into effect when no plugins take responsibility for the whitelist. As soon as any plugin, though, handles the shouldAllowRequest() call, for instance, the default policy is no longer in effect, and it is a true whitelist (block-by-default) My biggest concern with this is that developers are going to blindly update to Cordova 4.0.0, and when their app *just works*, they are not going to realize that they are actually less secure than before. (Without a plugin, we've opened up all network access) Idea -- maybe we can scan config.xml -- at run time, or on prepare, or on upgrade -- and if we see any access tag other than access origin=* we can display a loud message, suggesting strongly that they install an appropriate plugin. Ian The plugin name is fine. I'm not convinced about a user having to add this plugin to enable network requests for Android/iOS. This default behavior should work with the platform and should not require a plugin. This inhibits users from getting the ground running on a Cordova app. It breaks existing templates in IDEs and other downstream CLIs as well - as all of them need to include this plugin to have any network access work. Thanks, Nikhil -Original Message- From: mmo...@google.com [mailto:mmo...@google.com] On Behalf Of Michal Mocny Sent: Tuesday, March 3, 2015 11:22 AM To: dev Subject: Re: Android's new Whitelist Plugins I've filed a JIRA issue with my thoughts on how to approach this: https://issues.apache.org/jira/browse/CB-8597 On Tue, Mar 3, 2015 at 1:02 PM, Andrew Grieve agri...@chromium.org wrote: Like your ideas a lot. Updating the project template makes a lot of sense. Tried to make it clear in the README, so if any part was not clear please fix it. But, the CSP tag is the more important bit, since access can't actually block all requests. The only reason to even leave access in there is to support pre-kitkat webviews, where no CSP support exists. CSP is also used to set a navigation whitelist for subframes, which the native side is not able to do. On Tue, Mar 3, 2015 at 11:22 AM, Michal Mocny mmo...@chromium.org wrote: My thoughts: - The split between allow-navigation, allow-intent, and access: Like it a lot. - I think the defaults *for the plugin* are very reasonable. However, we may want to provide a default set of tags for the hello world app. A year or so ago we added a default access * whitelist and I think maybe we should continue that. (on the other hand, I've gotten used to explicitly whitelisting every url as part of chrome packaged app development and its not so bad). - Additionally, that means this plugin should be installed by default. As we discussed this morning, with the new plugin --save functionality we could just add this to the helloworld config.xml, I think! - Do you really need a CSP meta tag *and* access declarations? Thats what the README.md implies, but I would assume CSP trumps? -Michal On Mon, Mar 2, 2015 at 9:38 PM, Andrew Grieve agri...@chromium.org wrote: I've tried to explain it in the plugin's readme: https://github.com/apache/cordova-plugins/tree/master/url-policy Some points for discussion: - What should the default behaviour be for the three whitelists (what should happen if not whitelist plugin is installed). - right now it can't open external URLs - and can't do XHRs to http(s) - Is the plugin name decent (url-policy). We should make a dedicated git repo for it (as well as for legacy-whitelist plugin)
Re: Android's new Whitelist Plugins
I've been working on adding support to just install the whitelist plugin by default, and to add the access origin=* to the default app. Is that sufficient? I think we may still need to do what Ian suggests and prompt on upgrade (or prepare)? For downstreams, especially IDE based ones, they will need to make sure the plugin is added by default however they do that. On Wed, Mar 4, 2015 at 12:06 PM, Ian Clelland iclell...@chromium.org wrote: On Tue, Mar 3, 2015 at 8:20 PM, Nikhil Khandelwal nikhi...@microsoft.com wrote: Here are my thoughts on the default behavior: - navigation should be disabled. - XHR network request should be enabled. And application launch through intent URLs should also be disabled. (IMO) That's not a bad default -- it enables CSP usage by default, which I think is good. It also (I think) means we're giving up on suggesting that network requests can be completely blocked by default, because that's definitely not the case on Android. We can implement this within the new framework: there is the idea of a 'default policy' that only comes into effect when no plugins take responsibility for the whitelist. As soon as any plugin, though, handles the shouldAllowRequest() call, for instance, the default policy is no longer in effect, and it is a true whitelist (block-by-default) My biggest concern with this is that developers are going to blindly update to Cordova 4.0.0, and when their app *just works*, they are not going to realize that they are actually less secure than before. (Without a plugin, we've opened up all network access) Idea -- maybe we can scan config.xml -- at run time, or on prepare, or on upgrade -- and if we see any access tag other than access origin=* we can display a loud message, suggesting strongly that they install an appropriate plugin. Ian The plugin name is fine. I'm not convinced about a user having to add this plugin to enable network requests for Android/iOS. This default behavior should work with the platform and should not require a plugin. This inhibits users from getting the ground running on a Cordova app. It breaks existing templates in IDEs and other downstream CLIs as well - as all of them need to include this plugin to have any network access work. Thanks, Nikhil -Original Message- From: mmo...@google.com [mailto:mmo...@google.com] On Behalf Of Michal Mocny Sent: Tuesday, March 3, 2015 11:22 AM To: dev Subject: Re: Android's new Whitelist Plugins I've filed a JIRA issue with my thoughts on how to approach this: https://issues.apache.org/jira/browse/CB-8597 On Tue, Mar 3, 2015 at 1:02 PM, Andrew Grieve agri...@chromium.org wrote: Like your ideas a lot. Updating the project template makes a lot of sense. Tried to make it clear in the README, so if any part was not clear please fix it. But, the CSP tag is the more important bit, since access can't actually block all requests. The only reason to even leave access in there is to support pre-kitkat webviews, where no CSP support exists. CSP is also used to set a navigation whitelist for subframes, which the native side is not able to do. On Tue, Mar 3, 2015 at 11:22 AM, Michal Mocny mmo...@chromium.org wrote: My thoughts: - The split between allow-navigation, allow-intent, and access: Like it a lot. - I think the defaults *for the plugin* are very reasonable. However, we may want to provide a default set of tags for the hello world app. A year or so ago we added a default access * whitelist and I think maybe we should continue that. (on the other hand, I've gotten used to explicitly whitelisting every url as part of chrome packaged app development and its not so bad). - Additionally, that means this plugin should be installed by default. As we discussed this morning, with the new plugin --save functionality we could just add this to the helloworld config.xml, I think! - Do you really need a CSP meta tag *and* access declarations? Thats what the README.md implies, but I would assume CSP trumps? -Michal On Mon, Mar 2, 2015 at 9:38 PM, Andrew Grieve agri...@chromium.org wrote: I've tried to explain it in the plugin's readme: https://github.com/apache/cordova-plugins/tree/master/url-policy Some points for discussion: - What should the default behaviour be for the three whitelists (what should happen if not whitelist plugin is installed). - right now it can't open external URLs - and can't do XHRs to http(s) - Is the plugin name decent (url-policy). We should make a dedicated git repo for it (as well as for legacy-whitelist plugin)
RE: Android's new Whitelist Plugins
I like Ian's proposal of blocking network access only when a whitelist plugin is added to do so and is choosing to override the default behavior. Scanning config.xml on upgrade might be a good way to warn devs to refer them to use this plugin. These changes should also be documented in the migration guide from Android 3.x to 4.0. Thanks, Nikhil -Original Message- From: Jesse [mailto:purplecabb...@gmail.com] Sent: Wednesday, March 4, 2015 11:05 AM To: dev@cordova.apache.org Subject: Re: Android's new Whitelist Plugins I like the defaults as discussed, regardless of how they are achieved. ie. network yes, intents no This is similar to how a plain webview works if you add it to a native app on ios or android, at least the network part, not sure what the default intent handling is. Are there portions of this functionality that make more sense as part of the platform native code? To me a plugin that is installed by default is just modular platform code. Is there ever a reason to NOT want this plugin, versus just opening up access? @purplecabbage risingj.com On Wed, Mar 4, 2015 at 9:37 AM, Michal Mocny mmo...@chromium.org wrote: I've been working on adding support to just install the whitelist plugin by default, and to add the access origin=* to the default app. Is that sufficient? I think we may still need to do what Ian suggests and prompt on upgrade (or prepare)? For downstreams, especially IDE based ones, they will need to make sure the plugin is added by default however they do that. On Wed, Mar 4, 2015 at 12:06 PM, Ian Clelland iclell...@chromium.org wrote: On Tue, Mar 3, 2015 at 8:20 PM, Nikhil Khandelwal nikhi...@microsoft.com wrote: Here are my thoughts on the default behavior: - navigation should be disabled. - XHR network request should be enabled. And application launch through intent URLs should also be disabled. (IMO) That's not a bad default -- it enables CSP usage by default, which I think is good. It also (I think) means we're giving up on suggesting that network requests can be completely blocked by default, because that's definitely not the case on Android. We can implement this within the new framework: there is the idea of a 'default policy' that only comes into effect when no plugins take responsibility for the whitelist. As soon as any plugin, though, handles the shouldAllowRequest() call, for instance, the default policy is no longer in effect, and it is a true whitelist (block-by-default) My biggest concern with this is that developers are going to blindly update to Cordova 4.0.0, and when their app *just works*, they are not going to realize that they are actually less secure than before. (Without a plugin, we've opened up all network access) Idea -- maybe we can scan config.xml -- at run time, or on prepare, or on upgrade -- and if we see any access tag other than access origin=* we can display a loud message, suggesting strongly that they install an appropriate plugin. Ian The plugin name is fine. I'm not convinced about a user having to add this plugin to enable network requests for Android/iOS. This default behavior should work with the platform and should not require a plugin. This inhibits users from getting the ground running on a Cordova app. It breaks existing templates in IDEs and other downstream CLIs as well - as all of them need to include this plugin to have any network access work. Thanks, Nikhil -Original Message- From: mmo...@google.com [mailto:mmo...@google.com] On Behalf Of Michal Mocny Sent: Tuesday, March 3, 2015 11:22 AM To: dev Subject: Re: Android's new Whitelist Plugins I've filed a JIRA issue with my thoughts on how to approach this: https://issues.apache.org/jira/browse/CB-8597 On Tue, Mar 3, 2015 at 1:02 PM, Andrew Grieve agri...@chromium.org wrote: Like your ideas a lot. Updating the project template makes a lot of sense. Tried to make it clear in the README, so if any part was not clear please fix it. But, the CSP tag is the more important bit, since access can't actually block all requests. The only reason to even leave access in there is to support pre-kitkat webviews, where no CSP support exists. CSP is also used to set a navigation whitelist for subframes, which the native side is not able to do. On Tue, Mar 3, 2015 at 11:22 AM, Michal Mocny mmo...@chromium.org wrote: My thoughts: - The split between allow-navigation, allow-intent, and access: Like it a lot. - I think the defaults *for the plugin* are very reasonable. However, we may want to provide a default set of tags for the hello world app. A year or so ago we added a default access * whitelist and I think maybe we
Re: Android's new Whitelist Plugins
I think how Cordova works right now was the best way. Have access blocked by default, but have a access origin=*/ in the default template. It makes the setting visible, while still working out-of-the-box. If we turned on requests when no whitelist plugin is installed, then existing apps that have access tags will have their whitelist removed with 4.0.0 and not know it. If someone updates and their app can't hit the network anymore, then I think Stack Overflow will tell them why pretty quickly. We should also be very clear in the release notes and upgrade guide. On Wed, Mar 4, 2015 at 7:54 PM, Nikhil Khandelwal nikhi...@microsoft.com wrote: I like Ian's proposal of blocking network access only when a whitelist plugin is added to do so and is choosing to override the default behavior. Scanning config.xml on upgrade might be a good way to warn devs to refer them to use this plugin. These changes should also be documented in the migration guide from Android 3.x to 4.0. Thanks, Nikhil -Original Message- From: Jesse [mailto:purplecabb...@gmail.com] Sent: Wednesday, March 4, 2015 11:05 AM To: dev@cordova.apache.org Subject: Re: Android's new Whitelist Plugins I like the defaults as discussed, regardless of how they are achieved. ie. network yes, intents no This is similar to how a plain webview works if you add it to a native app on ios or android, at least the network part, not sure what the default intent handling is. Are there portions of this functionality that make more sense as part of the platform native code? To me a plugin that is installed by default is just modular platform code. Is there ever a reason to NOT want this plugin, versus just opening up access? @purplecabbage risingj.com On Wed, Mar 4, 2015 at 9:37 AM, Michal Mocny mmo...@chromium.org wrote: I've been working on adding support to just install the whitelist plugin by default, and to add the access origin=* to the default app. Is that sufficient? I think we may still need to do what Ian suggests and prompt on upgrade (or prepare)? For downstreams, especially IDE based ones, they will need to make sure the plugin is added by default however they do that. On Wed, Mar 4, 2015 at 12:06 PM, Ian Clelland iclell...@chromium.org wrote: On Tue, Mar 3, 2015 at 8:20 PM, Nikhil Khandelwal nikhi...@microsoft.com wrote: Here are my thoughts on the default behavior: - navigation should be disabled. - XHR network request should be enabled. And application launch through intent URLs should also be disabled. (IMO) That's not a bad default -- it enables CSP usage by default, which I think is good. It also (I think) means we're giving up on suggesting that network requests can be completely blocked by default, because that's definitely not the case on Android. We can implement this within the new framework: there is the idea of a 'default policy' that only comes into effect when no plugins take responsibility for the whitelist. As soon as any plugin, though, handles the shouldAllowRequest() call, for instance, the default policy is no longer in effect, and it is a true whitelist (block-by-default) My biggest concern with this is that developers are going to blindly update to Cordova 4.0.0, and when their app *just works*, they are not going to realize that they are actually less secure than before. (Without a plugin, we've opened up all network access) Idea -- maybe we can scan config.xml -- at run time, or on prepare, or on upgrade -- and if we see any access tag other than access origin=* we can display a loud message, suggesting strongly that they install an appropriate plugin. Ian The plugin name is fine. I'm not convinced about a user having to add this plugin to enable network requests for Android/iOS. This default behavior should work with the platform and should not require a plugin. This inhibits users from getting the ground running on a Cordova app. It breaks existing templates in IDEs and other downstream CLIs as well - as all of them need to include this plugin to have any network access work. Thanks, Nikhil -Original Message- From: mmo...@google.com [mailto:mmo...@google.com] On Behalf Of Michal Mocny Sent: Tuesday, March 3, 2015 11:22 AM To: dev Subject: Re: Android's new Whitelist Plugins I've filed a JIRA issue with my thoughts on how to approach this: https://issues.apache.org/jira/browse/CB-8597 On Tue, Mar 3, 2015 at 1:02 PM, Andrew Grieve agri...@chromium.org wrote: Like your ideas a lot. Updating the project template makes a lot of sense. Tried to make it clear in the README, so if any part was not clear please fix it. But, the CSP tag is the more important bit, since
Re: Android's new Whitelist Plugins
No comments about the names yet, but I'm now leaning towards: cordova-plugin-legacy-whitelist and cordova-plugin-whitelist as the two new git repos to create (rather than url-policy) On Wed, Mar 4, 2015 at 8:49 PM, Andrew Grieve agri...@chromium.org wrote: I think how Cordova works right now was the best way. Have access blocked by default, but have a access origin=*/ in the default template. It makes the setting visible, while still working out-of-the-box. If we turned on requests when no whitelist plugin is installed, then existing apps that have access tags will have their whitelist removed with 4.0.0 and not know it. If someone updates and their app can't hit the network anymore, then I think Stack Overflow will tell them why pretty quickly. We should also be very clear in the release notes and upgrade guide. On Wed, Mar 4, 2015 at 7:54 PM, Nikhil Khandelwal nikhi...@microsoft.com wrote: I like Ian's proposal of blocking network access only when a whitelist plugin is added to do so and is choosing to override the default behavior. Scanning config.xml on upgrade might be a good way to warn devs to refer them to use this plugin. These changes should also be documented in the migration guide from Android 3.x to 4.0. Thanks, Nikhil -Original Message- From: Jesse [mailto:purplecabb...@gmail.com] Sent: Wednesday, March 4, 2015 11:05 AM To: dev@cordova.apache.org Subject: Re: Android's new Whitelist Plugins I like the defaults as discussed, regardless of how they are achieved. ie. network yes, intents no This is similar to how a plain webview works if you add it to a native app on ios or android, at least the network part, not sure what the default intent handling is. Are there portions of this functionality that make more sense as part of the platform native code? To me a plugin that is installed by default is just modular platform code. Is there ever a reason to NOT want this plugin, versus just opening up access? @purplecabbage risingj.com On Wed, Mar 4, 2015 at 9:37 AM, Michal Mocny mmo...@chromium.org wrote: I've been working on adding support to just install the whitelist plugin by default, and to add the access origin=* to the default app. Is that sufficient? I think we may still need to do what Ian suggests and prompt on upgrade (or prepare)? For downstreams, especially IDE based ones, they will need to make sure the plugin is added by default however they do that. On Wed, Mar 4, 2015 at 12:06 PM, Ian Clelland iclell...@chromium.org wrote: On Tue, Mar 3, 2015 at 8:20 PM, Nikhil Khandelwal nikhi...@microsoft.com wrote: Here are my thoughts on the default behavior: - navigation should be disabled. - XHR network request should be enabled. And application launch through intent URLs should also be disabled. (IMO) That's not a bad default -- it enables CSP usage by default, which I think is good. It also (I think) means we're giving up on suggesting that network requests can be completely blocked by default, because that's definitely not the case on Android. We can implement this within the new framework: there is the idea of a 'default policy' that only comes into effect when no plugins take responsibility for the whitelist. As soon as any plugin, though, handles the shouldAllowRequest() call, for instance, the default policy is no longer in effect, and it is a true whitelist (block-by-default) My biggest concern with this is that developers are going to blindly update to Cordova 4.0.0, and when their app *just works*, they are not going to realize that they are actually less secure than before. (Without a plugin, we've opened up all network access) Idea -- maybe we can scan config.xml -- at run time, or on prepare, or on upgrade -- and if we see any access tag other than access origin=* we can display a loud message, suggesting strongly that they install an appropriate plugin. Ian The plugin name is fine. I'm not convinced about a user having to add this plugin to enable network requests for Android/iOS. This default behavior should work with the platform and should not require a plugin. This inhibits users from getting the ground running on a Cordova app. It breaks existing templates in IDEs and other downstream CLIs as well - as all of them need to include this plugin to have any network access work. Thanks, Nikhil -Original Message- From: mmo...@google.com [mailto:mmo...@google.com] On Behalf Of Michal Mocny Sent: Tuesday, March 3, 2015 11:22 AM To: dev Subject: Re: Android's new Whitelist Plugins I've filed a JIRA issue with my thoughts on how to approach this: https://issues.apache.org/jira/browse/CB-8597 On Tue, Mar 3, 2015 at 1:02 PM, Andrew Grieve
Re: Android's new Whitelist Plugins
+1 to names. On Wed, Mar 4, 2015 at 9:03 PM, Andrew Grieve agri...@chromium.org wrote: No comments about the names yet, but I'm now leaning towards: cordova-plugin-legacy-whitelist and cordova-plugin-whitelist as the two new git repos to create (rather than url-policy) On Wed, Mar 4, 2015 at 8:49 PM, Andrew Grieve agri...@chromium.org wrote: I think how Cordova works right now was the best way. Have access blocked by default, but have a access origin=*/ in the default template. It makes the setting visible, while still working out-of-the-box. If we turned on requests when no whitelist plugin is installed, then existing apps that have access tags will have their whitelist removed with 4.0.0 and not know it. If someone updates and their app can't hit the network anymore, then I think Stack Overflow will tell them why pretty quickly. We should also be very clear in the release notes and upgrade guide. On Wed, Mar 4, 2015 at 7:54 PM, Nikhil Khandelwal nikhi...@microsoft.com wrote: I like Ian's proposal of blocking network access only when a whitelist plugin is added to do so and is choosing to override the default behavior. Scanning config.xml on upgrade might be a good way to warn devs to refer them to use this plugin. These changes should also be documented in the migration guide from Android 3.x to 4.0. Thanks, Nikhil -Original Message- From: Jesse [mailto:purplecabb...@gmail.com] Sent: Wednesday, March 4, 2015 11:05 AM To: dev@cordova.apache.org Subject: Re: Android's new Whitelist Plugins I like the defaults as discussed, regardless of how they are achieved. ie. network yes, intents no This is similar to how a plain webview works if you add it to a native app on ios or android, at least the network part, not sure what the default intent handling is. Are there portions of this functionality that make more sense as part of the platform native code? To me a plugin that is installed by default is just modular platform code. Is there ever a reason to NOT want this plugin, versus just opening up access? @purplecabbage risingj.com On Wed, Mar 4, 2015 at 9:37 AM, Michal Mocny mmo...@chromium.org wrote: I've been working on adding support to just install the whitelist plugin by default, and to add the access origin=* to the default app. Is that sufficient? I think we may still need to do what Ian suggests and prompt on upgrade (or prepare)? For downstreams, especially IDE based ones, they will need to make sure the plugin is added by default however they do that. On Wed, Mar 4, 2015 at 12:06 PM, Ian Clelland iclell...@chromium.org wrote: On Tue, Mar 3, 2015 at 8:20 PM, Nikhil Khandelwal nikhi...@microsoft.com wrote: Here are my thoughts on the default behavior: - navigation should be disabled. - XHR network request should be enabled. And application launch through intent URLs should also be disabled. (IMO) That's not a bad default -- it enables CSP usage by default, which I think is good. It also (I think) means we're giving up on suggesting that network requests can be completely blocked by default, because that's definitely not the case on Android. We can implement this within the new framework: there is the idea of a 'default policy' that only comes into effect when no plugins take responsibility for the whitelist. As soon as any plugin, though, handles the shouldAllowRequest() call, for instance, the default policy is no longer in effect, and it is a true whitelist (block-by-default) My biggest concern with this is that developers are going to blindly update to Cordova 4.0.0, and when their app *just works*, they are not going to realize that they are actually less secure than before. (Without a plugin, we've opened up all network access) Idea -- maybe we can scan config.xml -- at run time, or on prepare, or on upgrade -- and if we see any access tag other than access origin=* we can display a loud message, suggesting strongly that they install an appropriate plugin. Ian The plugin name is fine. I'm not convinced about a user having to add this plugin to enable network requests for Android/iOS. This default behavior should work with the platform and should not require a plugin. This inhibits users from getting the ground running on a Cordova app. It breaks existing templates in IDEs and other downstream CLIs as well - as all of them need to include this plugin to have any network access work. Thanks, Nikhil -Original Message- From: mmo...@google.com [mailto:mmo...@google.com] On Behalf Of Michal Mocny Sent: Tuesday, March 3, 2015 11:22 AM
Re: Android's new Whitelist Plugins
..taking a look at the cli create.js script, we would need to update it a bit to actually have it import a hello-world config.xml. The lib actually ships the template config.xml right now instead of the hello-world project, which seems unnecessary given our --copy-from/--link-to import logic. Seems we could simplify the whole thing. -Michal On Tue, Mar 3, 2015 at 11:22 AM, Michal Mocny mmo...@chromium.org wrote: My thoughts: - The split between allow-navigation, allow-intent, and access: Like it a lot. - I think the defaults *for the plugin* are very reasonable. However, we may want to provide a default set of tags for the hello world app. A year or so ago we added a default access * whitelist and I think maybe we should continue that. (on the other hand, I've gotten used to explicitly whitelisting every url as part of chrome packaged app development and its not so bad). - Additionally, that means this plugin should be installed by default. As we discussed this morning, with the new plugin --save functionality we could just add this to the helloworld config.xml, I think! - Do you really need a CSP meta tag *and* access declarations? Thats what the README.md implies, but I would assume CSP trumps? -Michal On Mon, Mar 2, 2015 at 9:38 PM, Andrew Grieve agri...@chromium.org wrote: I've tried to explain it in the plugin's readme: https://github.com/apache/cordova-plugins/tree/master/url-policy Some points for discussion: - What should the default behaviour be for the three whitelists (what should happen if not whitelist plugin is installed). - right now it can't open external URLs - and can't do XHRs to http(s) - Is the plugin name decent (url-policy). We should make a dedicated git repo for it (as well as for legacy-whitelist plugin)
Re: Android's new Whitelist Plugins
My thoughts: - The split between allow-navigation, allow-intent, and access: Like it a lot. - I think the defaults *for the plugin* are very reasonable. However, we may want to provide a default set of tags for the hello world app. A year or so ago we added a default access * whitelist and I think maybe we should continue that. (on the other hand, I've gotten used to explicitly whitelisting every url as part of chrome packaged app development and its not so bad). - Additionally, that means this plugin should be installed by default. As we discussed this morning, with the new plugin --save functionality we could just add this to the helloworld config.xml, I think! - Do you really need a CSP meta tag *and* access declarations? Thats what the README.md implies, but I would assume CSP trumps? -Michal On Mon, Mar 2, 2015 at 9:38 PM, Andrew Grieve agri...@chromium.org wrote: I've tried to explain it in the plugin's readme: https://github.com/apache/cordova-plugins/tree/master/url-policy Some points for discussion: - What should the default behaviour be for the three whitelists (what should happen if not whitelist plugin is installed). - right now it can't open external URLs - and can't do XHRs to http(s) - Is the plugin name decent (url-policy). We should make a dedicated git repo for it (as well as for legacy-whitelist plugin)
Re: Android's new Whitelist Plugins
Ah, the bit about access being mostly useful for pre-kitkat was context I was missing. Seems important to note at the start of the section. I'll update the README. On Tue, Mar 3, 2015 at 1:02 PM, Andrew Grieve agri...@chromium.org wrote: Like your ideas a lot. Updating the project template makes a lot of sense. Tried to make it clear in the README, so if any part was not clear please fix it. But, the CSP tag is the more important bit, since access can't actually block all requests. The only reason to even leave access in there is to support pre-kitkat webviews, where no CSP support exists. CSP is also used to set a navigation whitelist for subframes, which the native side is not able to do. On Tue, Mar 3, 2015 at 11:22 AM, Michal Mocny mmo...@chromium.org wrote: My thoughts: - The split between allow-navigation, allow-intent, and access: Like it a lot. - I think the defaults *for the plugin* are very reasonable. However, we may want to provide a default set of tags for the hello world app. A year or so ago we added a default access * whitelist and I think maybe we should continue that. (on the other hand, I've gotten used to explicitly whitelisting every url as part of chrome packaged app development and its not so bad). - Additionally, that means this plugin should be installed by default. As we discussed this morning, with the new plugin --save functionality we could just add this to the helloworld config.xml, I think! - Do you really need a CSP meta tag *and* access declarations? Thats what the README.md implies, but I would assume CSP trumps? -Michal On Mon, Mar 2, 2015 at 9:38 PM, Andrew Grieve agri...@chromium.org wrote: I've tried to explain it in the plugin's readme: https://github.com/apache/cordova-plugins/tree/master/url-policy Some points for discussion: - What should the default behaviour be for the three whitelists (what should happen if not whitelist plugin is installed). - right now it can't open external URLs - and can't do XHRs to http(s) - Is the plugin name decent (url-policy). We should make a dedicated git repo for it (as well as for legacy-whitelist plugin)
Re: Android's new Whitelist Plugins
(Added this note: https://github.com/apache/cordova-plugins/commit/3ed17046ea7efaeccda4c4ffe82bb351e8b966f1, let me know if its inacurate). -Michal On Tue, Mar 3, 2015 at 1:06 PM, Michal Mocny mmo...@chromium.org wrote: Ah, the bit about access being mostly useful for pre-kitkat was context I was missing. Seems important to note at the start of the section. I'll update the README. On Tue, Mar 3, 2015 at 1:02 PM, Andrew Grieve agri...@chromium.org wrote: Like your ideas a lot. Updating the project template makes a lot of sense. Tried to make it clear in the README, so if any part was not clear please fix it. But, the CSP tag is the more important bit, since access can't actually block all requests. The only reason to even leave access in there is to support pre-kitkat webviews, where no CSP support exists. CSP is also used to set a navigation whitelist for subframes, which the native side is not able to do. On Tue, Mar 3, 2015 at 11:22 AM, Michal Mocny mmo...@chromium.org wrote: My thoughts: - The split between allow-navigation, allow-intent, and access: Like it a lot. - I think the defaults *for the plugin* are very reasonable. However, we may want to provide a default set of tags for the hello world app. A year or so ago we added a default access * whitelist and I think maybe we should continue that. (on the other hand, I've gotten used to explicitly whitelisting every url as part of chrome packaged app development and its not so bad). - Additionally, that means this plugin should be installed by default. As we discussed this morning, with the new plugin --save functionality we could just add this to the helloworld config.xml, I think! - Do you really need a CSP meta tag *and* access declarations? Thats what the README.md implies, but I would assume CSP trumps? -Michal On Mon, Mar 2, 2015 at 9:38 PM, Andrew Grieve agri...@chromium.org wrote: I've tried to explain it in the plugin's readme: https://github.com/apache/cordova-plugins/tree/master/url-policy Some points for discussion: - What should the default behaviour be for the three whitelists (what should happen if not whitelist plugin is installed). - right now it can't open external URLs - and can't do XHRs to http(s) - Is the plugin name decent (url-policy). We should make a dedicated git repo for it (as well as for legacy-whitelist plugin)
Re: Android's new Whitelist Plugins
I've filed a JIRA issue with my thoughts on how to approach this: https://issues.apache.org/jira/browse/CB-8597 On Tue, Mar 3, 2015 at 1:02 PM, Andrew Grieve agri...@chromium.org wrote: Like your ideas a lot. Updating the project template makes a lot of sense. Tried to make it clear in the README, so if any part was not clear please fix it. But, the CSP tag is the more important bit, since access can't actually block all requests. The only reason to even leave access in there is to support pre-kitkat webviews, where no CSP support exists. CSP is also used to set a navigation whitelist for subframes, which the native side is not able to do. On Tue, Mar 3, 2015 at 11:22 AM, Michal Mocny mmo...@chromium.org wrote: My thoughts: - The split between allow-navigation, allow-intent, and access: Like it a lot. - I think the defaults *for the plugin* are very reasonable. However, we may want to provide a default set of tags for the hello world app. A year or so ago we added a default access * whitelist and I think maybe we should continue that. (on the other hand, I've gotten used to explicitly whitelisting every url as part of chrome packaged app development and its not so bad). - Additionally, that means this plugin should be installed by default. As we discussed this morning, with the new plugin --save functionality we could just add this to the helloworld config.xml, I think! - Do you really need a CSP meta tag *and* access declarations? Thats what the README.md implies, but I would assume CSP trumps? -Michal On Mon, Mar 2, 2015 at 9:38 PM, Andrew Grieve agri...@chromium.org wrote: I've tried to explain it in the plugin's readme: https://github.com/apache/cordova-plugins/tree/master/url-policy Some points for discussion: - What should the default behaviour be for the three whitelists (what should happen if not whitelist plugin is installed). - right now it can't open external URLs - and can't do XHRs to http(s) - Is the plugin name decent (url-policy). We should make a dedicated git repo for it (as well as for legacy-whitelist plugin)
Re: Android's new Whitelist Plugins
Like your ideas a lot. Updating the project template makes a lot of sense. Tried to make it clear in the README, so if any part was not clear please fix it. But, the CSP tag is the more important bit, since access can't actually block all requests. The only reason to even leave access in there is to support pre-kitkat webviews, where no CSP support exists. CSP is also used to set a navigation whitelist for subframes, which the native side is not able to do. On Tue, Mar 3, 2015 at 11:22 AM, Michal Mocny mmo...@chromium.org wrote: My thoughts: - The split between allow-navigation, allow-intent, and access: Like it a lot. - I think the defaults *for the plugin* are very reasonable. However, we may want to provide a default set of tags for the hello world app. A year or so ago we added a default access * whitelist and I think maybe we should continue that. (on the other hand, I've gotten used to explicitly whitelisting every url as part of chrome packaged app development and its not so bad). - Additionally, that means this plugin should be installed by default. As we discussed this morning, with the new plugin --save functionality we could just add this to the helloworld config.xml, I think! - Do you really need a CSP meta tag *and* access declarations? Thats what the README.md implies, but I would assume CSP trumps? -Michal On Mon, Mar 2, 2015 at 9:38 PM, Andrew Grieve agri...@chromium.org wrote: I've tried to explain it in the plugin's readme: https://github.com/apache/cordova-plugins/tree/master/url-policy Some points for discussion: - What should the default behaviour be for the three whitelists (what should happen if not whitelist plugin is installed). - right now it can't open external URLs - and can't do XHRs to http(s) - Is the plugin name decent (url-policy). We should make a dedicated git repo for it (as well as for legacy-whitelist plugin)
RE: Android's new Whitelist Plugins
Here are my thoughts on the default behavior: - navigation should be disabled. - XHR network request should be enabled. The plugin name is fine. I'm not convinced about a user having to add this plugin to enable network requests for Android/iOS. This default behavior should work with the platform and should not require a plugin. This inhibits users from getting the ground running on a Cordova app. It breaks existing templates in IDEs and other downstream CLIs as well - as all of them need to include this plugin to have any network access work. Thanks, Nikhil -Original Message- From: mmo...@google.com [mailto:mmo...@google.com] On Behalf Of Michal Mocny Sent: Tuesday, March 3, 2015 11:22 AM To: dev Subject: Re: Android's new Whitelist Plugins I've filed a JIRA issue with my thoughts on how to approach this: https://issues.apache.org/jira/browse/CB-8597 On Tue, Mar 3, 2015 at 1:02 PM, Andrew Grieve agri...@chromium.org wrote: Like your ideas a lot. Updating the project template makes a lot of sense. Tried to make it clear in the README, so if any part was not clear please fix it. But, the CSP tag is the more important bit, since access can't actually block all requests. The only reason to even leave access in there is to support pre-kitkat webviews, where no CSP support exists. CSP is also used to set a navigation whitelist for subframes, which the native side is not able to do. On Tue, Mar 3, 2015 at 11:22 AM, Michal Mocny mmo...@chromium.org wrote: My thoughts: - The split between allow-navigation, allow-intent, and access: Like it a lot. - I think the defaults *for the plugin* are very reasonable. However, we may want to provide a default set of tags for the hello world app. A year or so ago we added a default access * whitelist and I think maybe we should continue that. (on the other hand, I've gotten used to explicitly whitelisting every url as part of chrome packaged app development and its not so bad). - Additionally, that means this plugin should be installed by default. As we discussed this morning, with the new plugin --save functionality we could just add this to the helloworld config.xml, I think! - Do you really need a CSP meta tag *and* access declarations? Thats what the README.md implies, but I would assume CSP trumps? -Michal On Mon, Mar 2, 2015 at 9:38 PM, Andrew Grieve agri...@chromium.org wrote: I've tried to explain it in the plugin's readme: https://github.com/apache/cordova-plugins/tree/master/url-policy Some points for discussion: - What should the default behaviour be for the three whitelists (what should happen if not whitelist plugin is installed). - right now it can't open external URLs - and can't do XHRs to http(s) - Is the plugin name decent (url-policy). We should make a dedicated git repo for it (as well as for legacy-whitelist plugin)
Android's new Whitelist Plugins
I've tried to explain it in the plugin's readme: https://github.com/apache/cordova-plugins/tree/master/url-policy Some points for discussion: - What should the default behaviour be for the three whitelists (what should happen if not whitelist plugin is installed). - right now it can't open external URLs - and can't do XHRs to http(s) - Is the plugin name decent (url-policy). We should make a dedicated git repo for it (as well as for legacy-whitelist plugin)
