Re: Android's new Whitelist Plugins
yes... yes I did... :) Pushed now. On Wed, Mar 11, 2015 at 5:49 PM, Steven Gill 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 > 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 wrote: > > > > > +1 > > > better late than never > > > > > > @purplecabbage > > > risingj.com > > > > > > On Thu, Mar 5, 2015 at 12:39 PM, Andrew Grieve > > > wrote: > > > > > > > Going with it: https://issues.apache.org/jira/browse/INFRA-9238 > > > > > > > > On Wed, Mar 4, 2015 at 11:22 PM, Michal Mocny > > > 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 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 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 > > > >
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 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 wrote: > > > +1 > > better late than never > > > > @purplecabbage > > risingj.com > > > > On Thu, Mar 5, 2015 at 12:39 PM, Andrew Grieve > > wrote: > > > > > Going with it: https://issues.apache.org/jira/browse/INFRA-9238 > > > > > > On Wed, Mar 4, 2015 at 11:22 PM, Michal Mocny > > wrote: > > > > > > > +1 to names. > > > > > > > > On Wed, Mar 4, 2015 at 9:03 PM, Andrew Grieve > > > > 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 > > > > >> wrote: > > > >> > > > >> > I think how Cordova works right now was the best way. Have access > > > >> blocked > > > >> > by default, but have a 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 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? > > > >> >> > > > >> >> > > > >>
Re: Android's new Whitelist Plugins
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 wrote: > +1 > better late than never > > @purplecabbage > risingj.com > > On Thu, Mar 5, 2015 at 12:39 PM, Andrew Grieve > wrote: > > > Going with it: https://issues.apache.org/jira/browse/INFRA-9238 > > > > On Wed, Mar 4, 2015 at 11:22 PM, Michal Mocny > wrote: > > > > > +1 to names. > > > > > > On Wed, Mar 4, 2015 at 9:03 PM, Andrew Grieve > > > 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 > > >> wrote: > > >> > > >> > I think how Cordova works right now was the best way. Have access > > >> blocked > > >> > by default, but have a 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 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 > > >> wrote: > > >> >> > > >> >> > I've been working on adding support to just install the whitelist > > >> >> > plugin by default, and to add the to the > > default > > >> >> app. > > >> >> > > > >> >&
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 wrote: > Going with it: https://issues.apache.org/jira/browse/INFRA-9238 > > On Wed, Mar 4, 2015 at 11:22 PM, Michal Mocny wrote: > > > +1 to names. > > > > On Wed, Mar 4, 2015 at 9:03 PM, Andrew Grieve > > 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 > >> wrote: > >> > >> > I think how Cordova works right now was the best way. Have access > >> blocked > >> > by default, but have a 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 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 > >> wrote: > >> >> > >> >> > I've been working on adding support to just install the whitelist > >> >> > plugin by default, and to add the 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.co
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 wrote: > +1 to names. > > On Wed, Mar 4, 2015 at 9:03 PM, Andrew Grieve > 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 >> wrote: >> >> > I think how Cordova works right now was the best way. Have access >> blocked >> > by default, but have a 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 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 >> wrote: >> >> >> >> > I've been working on adding support to just install the whitelist >> >> > plugin by default, and to add the 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 >>
Re: Android's new Whitelist Plugins
+1 to names. On Wed, Mar 4, 2015 at 9:03 PM, Andrew Grieve 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 > wrote: > > > I think how Cordova works right now was the best way. Have access blocked > > by default, but have a 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 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 > wrote: > >> > >> > I've been working on adding support to just install the whitelist > >> > plugin by default, and to add the 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 > > >> > 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 defaul
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 wrote: > I think how Cordova works right now was the best way. Have access blocked > by default, but have a 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 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 > 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 wrote: >> >> > I've been working on adding support to just install the whitelist >> > plugin by default, and to add the 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 >> > 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
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 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 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 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 wrote: > > > I've been working on adding support to just install the whitelist > > plugin by default, and to add the 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 > > 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 > > 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
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 wrote: > I've been working on adding support to just install the whitelist > plugin by default, and to add the 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 > 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 > 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 > > > > > > wrote: > > > > > > > Like your ideas a lot. Updating the project template makes a lot > > > > of > > > sense. > > > > > > > > Tried to make it clear in the README,
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 wrote: > I've been working on adding support to just install the whitelist plugin by > default, and to add the 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 > 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 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 > > > 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 > > > > can't actually block all requests. The only reason to even > > > > leave 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 > > > wrote: > > > > > > > > > My thoughts: > > > > > > > > > > - The split between , , and &
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 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
wrote:
> On Tue, Mar 3, 2015 at 8:20 PM, Nikhil Khandelwal
> 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 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
> > 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
> > > can't actually block all requests. The only reason to even
> > > leave 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
> > wrote:
> > >
> > > > My thoughts:
> > > >
> > > > - The split between , , and :
> > > 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* 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
> > > > 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
On Tue, Mar 3, 2015 at 8:20 PM, Nikhil Khandelwal
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 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
> 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
> > can't actually block all requests. The only reason to even
> > leave 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
> wrote:
> >
> > > My thoughts:
> > >
> > > - The split between , , and :
> > 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* 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
> > > 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 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
> can't actually block all requests. The only reason to even
> leave 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 wrote:
>
> > My thoughts:
> >
> > - The split between , , and :
> 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* 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
> > 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 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 can't
> actually block all requests. The only reason to even leave 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 wrote:
>
> > My thoughts:
> >
> > - The split between , , and :
> 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* 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
> > 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 wrote:
> Ah, the bit about 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
> 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 can't
>> actually block all requests. The only reason to even leave 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
>> wrote:
>>
>> > My thoughts:
>> >
>> > - The split between , , and :
>> 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* 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
>> > 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 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 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 can't
> actually block all requests. The only reason to even leave 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 wrote:
>
> > My thoughts:
> >
> > - The split between , , and :
> 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* 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
> > 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 can't
actually block all requests. The only reason to even leave 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 wrote:
> My thoughts:
>
> - The split between , , and : 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* 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
> 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
..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 wrote:
> My thoughts:
>
> - The split between , , and : 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* 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
> 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 , , and : 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* 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 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)
>
