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) > > > > > > > > > > > > > > >
