Mailing-List: contact dev-help@cordova.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cordova.apache.org
Received-SPF: pass (nike.apache.org: domain of agrieve@google.com designates
 209.85.223.170 as permitted sender)
MIME-Version: 1.0
Sender: agrieve@google.com
In-Reply-To: 
 <CABiQX1UQv36XHkiLGbpUXbW5n6DqABH=11CCixwAtQSNaVD52A@mail.gmail.com>
References: 
 <CABiQX1WEhoOyXngbHmyhqLHK_yfbMv3RKH=g8ms-KLy8ZKs6QA@mail.gmail.com>
 <CAEeF2TdXe8=UCsomQyBMBOpnQ+RbXpi=0WGk79Zn8T+1oi4aOg@mail.gmail.com>
 <CABiQX1U=srqaf65atCq+DcE7MTFD+xkK7PDjH06ZcTcCALMu=g@mail.gmail.com>
 <CAEeF2Tcqk2mHk0cL9ABph7E36CN1gSQVjG2kWYrBY=LGMTXTpQ@mail.gmail.com>
 <BLUPR03MB1346CD4C5721784B72BC7DCC31E0@BLUPR03MB134.namprd03.prod.outlook.com>
 <CAK_TSXJAWT4MUMH16Tvf7BtU5X0S-vsf0Z+Saa4x_zSA9Q=vVQ@mail.gmail.com>
 <CAEeF2TdPN+j8ase-u0vNtSFsBPfzZG+NHvYgXRwQQ8yqaOnnpQ@mail.gmail.com>
 <CAKP6k2tvXHGSAaScWdNpy1jSxueLfTydU7=1dQZeQNvp9nbmFA@mail.gmail.com>
 <BLUPR03MB134FBCD51B55D2C0F002DB8C31F0@BLUPR03MB134.namprd03.prod.outlook.com>
 <CABiQX1UQv36XHkiLGbpUXbW5n6DqABH=11CCixwAtQSNaVD52A@mail.gmail.com>
From: Andrew Grieve <agrieve@chromium.org>
Date: Wed, 4 Mar 2015 21:03:07 -0500
Message-ID: 
 <CABiQX1U+_u7JZ07VacETU_z5gs=AL+-iqK8zUPjsy2MXoKQHoA@mail.gmail.com>
Subject: Re: Android's new Whitelist Plugins
To: Andrew Grieve <agrieve@chromium.org>
Cc: dev <dev@cordova.apache.org>
Content-Type: multipart/alternative; boundary=047d7bdc11d64ceb68051080f9cd

--047d7bdc11d64ceb68051080f9cd
Content-Type: text/plain; charset=UTF-8

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 <agrieve@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 <nikhilkh@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:purplecabbage@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 <mmocny@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 <iclelland@chromium.org>
>> > wrote:
>> >
>> > > On Tue, Mar 3, 2015 at 8:20 PM, Nikhil Khandelwal <
>> > nikhilkh@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: mmocny@google.com [mailto:mmocny@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
>> > > > <agrieve@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
>> > > > > <mmocny@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 <
>> > agrieve@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-unsubscribe@cordova.apache.org
>> For additional commands, e-mail: dev-help@cordova.apache.org
>>
>
>

--047d7bdc11d64ceb68051080f9cd--