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 > > > > 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-po > > > > > > licy > > > > > > > > > > > > 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) > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org
