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