Re: [VOTE] Cordova-Plugin-Whitelist and Cordova-Plugin-Legacy-Whitelist Plugins Release (attempt 2)

[Steven Gill]

The vote has now closed. The results are:

Positive Binding Votes: 4

Steve Gill
Andrew Grieve
Ian Clelland
Mark Koudritsky

The vote has passed. I will publish these to dist and npm.


On Tue, Mar 31, 2015 at 2:42 PM, Steven Gill stevengil...@gmail.com wrote:

 That is good rationale for that use case. Not sure how much our users
 would run into it. Do we have any plugins currently that we would want to
 install different files for older versions. Managing all of that code in a
 plugin will get ugly.

 In NPM land, I think the answer would be to install an older version of
 the package (plugin in our case). I prefer this way.

 I personally think it should be up to the user to install older versions
 of plugins if the newer one doesn't support their platforms. As long as we
 use semver properly, this shouldn't be a big deal. We could add logic for
 us to auto grab older versions but I think it might be too much magic from
 the users perspective.

 Sidenote: Read a post about nativescript plugins today. (
 https://github.com/NativeScript/NativeScript/issues/25). They are
 planning on using package.json to install plugins (no plugin.xml). Some
 neat ideas in there that we might want to adopt ourselves in the future.







 On Tue, Mar 31, 2015 at 10:26 AM, Ian Clelland iclell...@chromium.org
 wrote:

 My thinking was that some plugins are going to need to have two very
 different designs, say for cordova-android 3.7.0 vs 4.0.0, or cordova-ios
 3.8.0 vs 4.0.0. In that case, you could do something like this;

 platform name=ios
   version match==4.0.0
 !-- tags for the new version --
   /version
   version match=4.0.0
 !-- tags for the backwards-compatiblity version --
   /version
 /platform

 which i don't think you could do with the engine tags -- with engine
 either all of the platform files are installed, or none of them are.

 Another way to do this would be to allow multiple versions to be available
 on the CPR or on npm, and have logic to decide the best version of the
 plugin to install. (with the ability to successfully install nothing if
 that's the right choice)

 On Tue, Mar 31, 2015 at 1:17 PM, Steven Gill stevengil...@gmail.com
 wrote:

  Ian, instead of adding a version tag in plugin.xml, why don't we use the
  engine tag in plugins package.json?
 
  Something like:
 
  {
engines : {
  cordova-android : 4.0.0,
  cordova-ios : =3.0.0 4.0
}
  }
 
 
  If the user doesn't have the specified platform versions installed, user
  gets a warning and plugin doesn't install. If no engine is specified,
  install away.
 
  Thoughts?
 
  On Mon, Mar 30, 2015 at 12:49 PM, Ian Clelland iclell...@chromium.org
  wrote:
 
   So this isn't a -1, unless we can't fix the problem in cordova-lib.
 And
   it's okay, I think, to fix it in cordova-lib/master and release that
 as
   well. Nothing is actually broken by publishing either app-hello-world
 or
   plugin-whitelist until we release a version of tools that is pinned to
  the
   new hello-world.
  
  
   On Mon, Mar 30, 2015 at 3:40 PM, Mark Koudritsky kam...@google.com
   wrote:
  
Looks like this breaks on cordova-android 3.7.1 (currently latest
   released)
   
cordova-app-hello-world requires the whitelist plugin
whitelist plugin depends on cordova-android 4.0 via the engine tag
engine name=cordova-android version==4.0.0-dev /
The resulting error message is
Plugin doesn't support this project's cordova-android version.
cordova-android: 3.7.1, failed version requirement: =4.0.0-dev
   
Simply removing the engine tag results in compile errors. (change
in CustomConfigXmlParser.parse() signature).
   
Any ideas on how to solve this would be appreciated. Ideas we came
 up
   with
in a quick discussion:
   
1. Add ignore attribute to the engine tag that would result in
  plugin
being silently ignored for incompatible engines rather than going
 down
  in
flames.
2. Add either version child or version attribute to the
 platform
   tag
in plugin.xml
   
  
   This is my favorite idea so far -- I think we could do something like
  this:
   plugin ... 
 platform name=android
   version match==4.0.0
 !-- tags --
   /version
 /platform
   /plugin
  
   I think this is overdue, and we'll find it useful as we move from 3.x
 to
   4.x on other platforms as well. We would allow multiple version tags
   inside of each platform, and any tags outside of the version tags
 are
   the default if nothing matches.
  
   In this case, there won't be any tags outside of the version tag, so
  the
   fallback for 3.x is to install nothing, but succeed.
  
   Ian
  
  
   
On Fri, Mar 27, 2015 at 4:31 PM, Andrew Grieve 
 agri...@chromium.org
wrote:
   
 +1

 * Tested that both plugins compile on Android
 * Tested that the non-legacy plugin does what its supposed to on
   Android

 On Thu, Mar 26, 2015 at 7:46 PM, Steven Gill 
 stevengil

Re: [VOTE] Cordova-Plugin-Whitelist and Cordova-Plugin-Legacy-Whitelist Plugins Release (attempt 2)

[Ian Clelland]

+1

* Verified package contents against public repo at the correct tags
* Verified checksums and signatures
* Built and verified functionality on android (4.0.0-dev/0669edd) and ios
(no functionality, no issues either)

On Tue, Mar 31, 2015 at 1:10 AM, Steven Gill stevengil...@gmail.com wrote:

 I like the sound of both ideas.

 Marks idea to make the default hello world app not install whitelist until
 android 4.0 (use 3.8.0 for app hello world)

 Ian, that looks like a good proposal. We are definitely overdo for
 something to properly track versions. Users should get a warning when a
 plugin doesn't get installed due to version issues.

 -Steve
 On Mar 30, 2015 6:18 PM, Andrew Grieve agri...@chromium.org wrote:

  Mark - I like that idea as well.
 
  On Mon, Mar 30, 2015 at 6:33 PM, Ian Clelland iclell...@chromium.org
  wrote:
 
   On 30 Mar 2015 4:52 pm, Mark Koudritsky kam...@google.com wrote:
   
Another quick option for now: we can pin hello-world version in
cordova-lib's package.json to 3.8.0 which doesn't use the whitelist
plugin.  Later, when we release the tools pinned to cordova-android
 4.0
   we
will have to change the hello-world dep to ^3.9.0.
  
   That's a good idea.
  
   I'll validate the plug-ins and vote later tonight.
  
   Ian
This way it's a minimal change to cordova-lib and we can go ahead
 with
   this
vote.
   
On Mon, Mar 30, 2015 at 3:49 PM, Ian Clelland 
 iclell...@chromium.org
wrote:
   
 So this isn't a -1, unless we can't fix the problem in cordova-lib.
  And
 it's okay, I think, to fix it in cordova-lib/master and release
 that
  as
 well. Nothing is actually broken by publishing either
 app-hello-world
   or
 plugin-whitelist until we release a version of tools that is pinned
  to
   the
 new hello-world.


 On Mon, Mar 30, 2015 at 3:40 PM, Mark Koudritsky 
 kam...@google.com
 wrote:

  Looks like this breaks on cordova-android 3.7.1 (currently latest
 released)
 
  cordova-app-hello-world requires the whitelist plugin
  whitelist plugin depends on cordova-android 4.0 via the engine
 tag
  engine name=cordova-android version==4.0.0-dev /
  The resulting error message is
  Plugin doesn't support this project's cordova-android version.
  cordova-android: 3.7.1, failed version requirement: =4.0.0-dev
 
  Simply removing the engine tag results in compile errors.
 (change
  in CustomConfigXmlParser.parse() signature).
 
  Any ideas on how to solve this would be appreciated. Ideas we
 came
  up
 with
  in a quick discussion:
 
  1. Add ignore attribute to the engine tag that would result
 in
   plugin
  being silently ignored for incompatible engines rather than going
   down in
  flames.
  2. Add either version child or version attribute to the
   platform
 tag
  in plugin.xml
 

 This is my favorite idea so far -- I think we could do something
 like
   this:
 plugin ... 
   platform name=android
 version match==4.0.0
   !-- tags --
 /version
   /platform
 /plugin

 I think this is overdue, and we'll find it useful as we move from
 3.x
   to
 4.x on other platforms as well. We would allow multiple version
  tags
 inside of each platform, and any tags outside of the version
 tags
   are
 the default if nothing matches.

 In this case, there won't be any tags outside of the version tag,
  so
   the
 fallback for 3.x is to install nothing, but succeed.

 Ian


 
  On Fri, Mar 27, 2015 at 4:31 PM, Andrew Grieve 
  agri...@chromium.org
   
  wrote:
 
   +1
  
   * Tested that both plugins compile on Android
   * Tested that the non-legacy plugin does what its supposed to
 on
 Android
  
   On Thu, Mar 26, 2015 at 7:46 PM, Steven Gill 
   stevengil...@gmail.com
   
   wrote:
  
Please review and vote on the releases of
   cordova-plugin-whitelist
 and
cordova-plugin-legacy-whitelist plugins.
   
Release issue: https://issues.apache.org/jira/browse/CB-8739
   
The plugins have been published to
dist/dev:
  https://dist.apache.org/repos/dist/dev/cordova/CB-8739/
   
The packages were published from their corresponding git
 tags:
cordova-plugin-whitelist: 1.0.0
(38f5a9fa2c)cordova-plugin-legacy-whitelist: 1.0.0
 (1ce26eba64)
   
Upon a successful vote I will upload the archives to dist/
 and
   upload
them to npm.
   
Voting guidelines:
   
  
 

  
 
 https://github.com/apache/cordova-coho/blob/master/docs/release-voting.md
   
Voting will go on for a minimum of 48 hours.
   
I vote +1:
* Ran coho audit-license-headers over the relevant repos
* Ran coho check-license to ensure all dependencies

Re: [VOTE] Cordova-Plugin-Whitelist and Cordova-Plugin-Legacy-Whitelist Plugins Release (attempt 2)

[Mark Koudritsky]

+1
* built and ran a hello world app on Nexus 7 and iOS simulator

Also pinned app-hello-world version to 3.8.0 in cordova-lib:
https://github.com/apache/cordova-lib/commit/c154d527a5b52a5b1fd139f437c83f455cf92e10
This should be changed back once we pin cordova-android version to 4.0.

On Tue, Mar 31, 2015 at 9:02 AM, Ian Clelland iclell...@chromium.org
wrote:

 +1

 * Verified package contents against public repo at the correct tags
 * Verified checksums and signatures
 * Built and verified functionality on android (4.0.0-dev/0669edd) and ios
 (no functionality, no issues either)

 On Tue, Mar 31, 2015 at 1:10 AM, Steven Gill stevengil...@gmail.com
 wrote:

  I like the sound of both ideas.
 
  Marks idea to make the default hello world app not install whitelist
 until
  android 4.0 (use 3.8.0 for app hello world)
 
  Ian, that looks like a good proposal. We are definitely overdo for
  something to properly track versions. Users should get a warning when a
  plugin doesn't get installed due to version issues.
 
  -Steve
  On Mar 30, 2015 6:18 PM, Andrew Grieve agri...@chromium.org wrote:
 
   Mark - I like that idea as well.
  
   On Mon, Mar 30, 2015 at 6:33 PM, Ian Clelland iclell...@chromium.org
   wrote:
  
On 30 Mar 2015 4:52 pm, Mark Koudritsky kam...@google.com wrote:

 Another quick option for now: we can pin hello-world version in
 cordova-lib's package.json to 3.8.0 which doesn't use the whitelist
 plugin.  Later, when we release the tools pinned to cordova-android
  4.0
we
 will have to change the hello-world dep to ^3.9.0.
   
That's a good idea.
   
I'll validate the plug-ins and vote later tonight.
   
Ian
 This way it's a minimal change to cordova-lib and we can go ahead
  with
this
 vote.

 On Mon, Mar 30, 2015 at 3:49 PM, Ian Clelland 
  iclell...@chromium.org
 wrote:

  So this isn't a -1, unless we can't fix the problem in
 cordova-lib.
   And
  it's okay, I think, to fix it in cordova-lib/master and release
  that
   as
  well. Nothing is actually broken by publishing either
  app-hello-world
or
  plugin-whitelist until we release a version of tools that is
 pinned
   to
the
  new hello-world.
 
 
  On Mon, Mar 30, 2015 at 3:40 PM, Mark Koudritsky 
  kam...@google.com
  wrote:
 
   Looks like this breaks on cordova-android 3.7.1 (currently
 latest
  released)
  
   cordova-app-hello-world requires the whitelist plugin
   whitelist plugin depends on cordova-android 4.0 via the engine
  tag
   engine name=cordova-android version==4.0.0-dev /
   The resulting error message is
   Plugin doesn't support this project's cordova-android version.
   cordova-android: 3.7.1, failed version requirement: =4.0.0-dev
  
   Simply removing the engine tag results in compile errors.
  (change
   in CustomConfigXmlParser.parse() signature).
  
   Any ideas on how to solve this would be appreciated. Ideas we
  came
   up
  with
   in a quick discussion:
  
   1. Add ignore attribute to the engine tag that would result
  in
plugin
   being silently ignored for incompatible engines rather than
 going
down in
   flames.
   2. Add either version child or version attribute to the
platform
  tag
   in plugin.xml
  
 
  This is my favorite idea so far -- I think we could do something
  like
this:
  plugin ... 
platform name=android
  version match==4.0.0
!-- tags --
  /version
/platform
  /plugin
 
  I think this is overdue, and we'll find it useful as we move from
  3.x
to
  4.x on other platforms as well. We would allow multiple version
   tags
  inside of each platform, and any tags outside of the version
  tags
are
  the default if nothing matches.
 
  In this case, there won't be any tags outside of the version
 tag,
   so
the
  fallback for 3.x is to install nothing, but succeed.
 
  Ian
 
 
  
   On Fri, Mar 27, 2015 at 4:31 PM, Andrew Grieve 
   agri...@chromium.org

   wrote:
  
+1
   
* Tested that both plugins compile on Android
* Tested that the non-legacy plugin does what its supposed to
  on
  Android
   
On Thu, Mar 26, 2015 at 7:46 PM, Steven Gill 
stevengil...@gmail.com

wrote:
   
 Please review and vote on the releases of
cordova-plugin-whitelist
  and
 cordova-plugin-legacy-whitelist plugins.

 Release issue:
 https://issues.apache.org/jira/browse/CB-8739

 The plugins have been published to
 dist/dev:
   https://dist.apache.org/repos/dist/dev/cordova/CB-8739/

 The packages were published from their corresponding git
  tags:
 cordova-plugin-whitelist: 1.0.0
 (38f5a9fa2c

Re: [VOTE] Cordova-Plugin-Whitelist and Cordova-Plugin-Legacy-Whitelist Plugins Release (attempt 2)

[Steven Gill]

Ian, instead of adding a version tag in plugin.xml, why don't we use the
engine tag in plugins package.json?

Something like:

{
  engines : {
cordova-android : 4.0.0,
cordova-ios : =3.0.0 4.0
  }
}


If the user doesn't have the specified platform versions installed, user
gets a warning and plugin doesn't install. If no engine is specified,
install away.

Thoughts?

On Mon, Mar 30, 2015 at 12:49 PM, Ian Clelland iclell...@chromium.org
wrote:

 So this isn't a -1, unless we can't fix the problem in cordova-lib. And
 it's okay, I think, to fix it in cordova-lib/master and release that as
 well. Nothing is actually broken by publishing either app-hello-world or
 plugin-whitelist until we release a version of tools that is pinned to the
 new hello-world.


 On Mon, Mar 30, 2015 at 3:40 PM, Mark Koudritsky kam...@google.com
 wrote:

  Looks like this breaks on cordova-android 3.7.1 (currently latest
 released)
 
  cordova-app-hello-world requires the whitelist plugin
  whitelist plugin depends on cordova-android 4.0 via the engine tag
  engine name=cordova-android version==4.0.0-dev /
  The resulting error message is
  Plugin doesn't support this project's cordova-android version.
  cordova-android: 3.7.1, failed version requirement: =4.0.0-dev
 
  Simply removing the engine tag results in compile errors. (change
  in CustomConfigXmlParser.parse() signature).
 
  Any ideas on how to solve this would be appreciated. Ideas we came up
 with
  in a quick discussion:
 
  1. Add ignore attribute to the engine tag that would result in plugin
  being silently ignored for incompatible engines rather than going down in
  flames.
  2. Add either version child or version attribute to the platform
 tag
  in plugin.xml
 

 This is my favorite idea so far -- I think we could do something like this:
 plugin ... 
   platform name=android
 version match==4.0.0
   !-- tags --
 /version
   /platform
 /plugin

 I think this is overdue, and we'll find it useful as we move from 3.x to
 4.x on other platforms as well. We would allow multiple version tags
 inside of each platform, and any tags outside of the version tags are
 the default if nothing matches.

 In this case, there won't be any tags outside of the version tag, so the
 fallback for 3.x is to install nothing, but succeed.

 Ian


 
  On Fri, Mar 27, 2015 at 4:31 PM, Andrew Grieve agri...@chromium.org
  wrote:
 
   +1
  
   * Tested that both plugins compile on Android
   * Tested that the non-legacy plugin does what its supposed to on
 Android
  
   On Thu, Mar 26, 2015 at 7:46 PM, Steven Gill stevengil...@gmail.com
   wrote:
  
Please review and vote on the releases of cordova-plugin-whitelist
 and
cordova-plugin-legacy-whitelist plugins.
   
Release issue: https://issues.apache.org/jira/browse/CB-8739
   
The plugins have been published to
dist/dev:https://dist.apache.org/repos/dist/dev/cordova/CB-8739/
   
The packages were published from their corresponding git tags:
cordova-plugin-whitelist: 1.0.0
(38f5a9fa2c)cordova-plugin-legacy-whitelist: 1.0.0 (1ce26eba64)
   
Upon a successful vote I will upload the archives to dist/ and upload
them to npm.
   
Voting guidelines:
   
  
 
 https://github.com/apache/cordova-coho/blob/master/docs/release-voting.md
   
Voting will go on for a minimum of 48 hours.
   
I vote +1:
* Ran coho audit-license-headers over the relevant repos
* Ran coho check-license to ensure all dependencies and
subdependencies have Apache-compatible licenses
   
  
 

Re: [VOTE] Cordova-Plugin-Whitelist and Cordova-Plugin-Legacy-Whitelist Plugins Release (attempt 2)

[Ian Clelland]

My thinking was that some plugins are going to need to have two very
different designs, say for cordova-android 3.7.0 vs 4.0.0, or cordova-ios
3.8.0 vs 4.0.0. In that case, you could do something like this;

platform name=ios
  version match==4.0.0
!-- tags for the new version --
  /version
  version match=4.0.0
!-- tags for the backwards-compatiblity version --
  /version
/platform

which i don't think you could do with the engine tags -- with engine
either all of the platform files are installed, or none of them are.

Another way to do this would be to allow multiple versions to be available
on the CPR or on npm, and have logic to decide the best version of the
plugin to install. (with the ability to successfully install nothing if
that's the right choice)

On Tue, Mar 31, 2015 at 1:17 PM, Steven Gill stevengil...@gmail.com wrote:

 Ian, instead of adding a version tag in plugin.xml, why don't we use the
 engine tag in plugins package.json?

 Something like:

 {
   engines : {
 cordova-android : 4.0.0,
 cordova-ios : =3.0.0 4.0
   }
 }


 If the user doesn't have the specified platform versions installed, user
 gets a warning and plugin doesn't install. If no engine is specified,
 install away.

 Thoughts?

 On Mon, Mar 30, 2015 at 12:49 PM, Ian Clelland iclell...@chromium.org
 wrote:

  So this isn't a -1, unless we can't fix the problem in cordova-lib. And
  it's okay, I think, to fix it in cordova-lib/master and release that as
  well. Nothing is actually broken by publishing either app-hello-world or
  plugin-whitelist until we release a version of tools that is pinned to
 the
  new hello-world.
 
 
  On Mon, Mar 30, 2015 at 3:40 PM, Mark Koudritsky kam...@google.com
  wrote:
 
   Looks like this breaks on cordova-android 3.7.1 (currently latest
  released)
  
   cordova-app-hello-world requires the whitelist plugin
   whitelist plugin depends on cordova-android 4.0 via the engine tag
   engine name=cordova-android version==4.0.0-dev /
   The resulting error message is
   Plugin doesn't support this project's cordova-android version.
   cordova-android: 3.7.1, failed version requirement: =4.0.0-dev
  
   Simply removing the engine tag results in compile errors. (change
   in CustomConfigXmlParser.parse() signature).
  
   Any ideas on how to solve this would be appreciated. Ideas we came up
  with
   in a quick discussion:
  
   1. Add ignore attribute to the engine tag that would result in
 plugin
   being silently ignored for incompatible engines rather than going down
 in
   flames.
   2. Add either version child or version attribute to the platform
  tag
   in plugin.xml
  
 
  This is my favorite idea so far -- I think we could do something like
 this:
  plugin ... 
platform name=android
  version match==4.0.0
!-- tags --
  /version
/platform
  /plugin
 
  I think this is overdue, and we'll find it useful as we move from 3.x to
  4.x on other platforms as well. We would allow multiple version tags
  inside of each platform, and any tags outside of the version tags are
  the default if nothing matches.
 
  In this case, there won't be any tags outside of the version tag, so
 the
  fallback for 3.x is to install nothing, but succeed.
 
  Ian
 
 
  
   On Fri, Mar 27, 2015 at 4:31 PM, Andrew Grieve agri...@chromium.org
   wrote:
  
+1
   
* Tested that both plugins compile on Android
* Tested that the non-legacy plugin does what its supposed to on
  Android
   
On Thu, Mar 26, 2015 at 7:46 PM, Steven Gill stevengil...@gmail.com
 
wrote:
   
 Please review and vote on the releases of cordova-plugin-whitelist
  and
 cordova-plugin-legacy-whitelist plugins.

 Release issue: https://issues.apache.org/jira/browse/CB-8739

 The plugins have been published to
 dist/dev:https://dist.apache.org/repos/dist/dev/cordova/CB-8739/

 The packages were published from their corresponding git tags:
 cordova-plugin-whitelist: 1.0.0
 (38f5a9fa2c)cordova-plugin-legacy-whitelist: 1.0.0 (1ce26eba64)

 Upon a successful vote I will upload the archives to dist/ and
 upload
 them to npm.

 Voting guidelines:

   
  
 
 https://github.com/apache/cordova-coho/blob/master/docs/release-voting.md

 Voting will go on for a minimum of 48 hours.

 I vote +1:
 * Ran coho audit-license-headers over the relevant repos
 * Ran coho check-license to ensure all dependencies and
 subdependencies have Apache-compatible licenses

   
  
 

Re: [VOTE] Cordova-Plugin-Whitelist and Cordova-Plugin-Legacy-Whitelist Plugins Release (attempt 2)

[Steven Gill]

That is good rationale for that use case. Not sure how much our users would
run into it. Do we have any plugins currently that we would want to install
different files for older versions. Managing all of that code in a plugin
will get ugly.

In NPM land, I think the answer would be to install an older version of the
package (plugin in our case). I prefer this way.

I personally think it should be up to the user to install older versions of
plugins if the newer one doesn't support their platforms. As long as we use
semver properly, this shouldn't be a big deal. We could add logic for us to
auto grab older versions but I think it might be too much magic from the
users perspective.

Sidenote: Read a post about nativescript plugins today. (
https://github.com/NativeScript/NativeScript/issues/25). They are planning
on using package.json to install plugins (no plugin.xml). Some neat ideas
in there that we might want to adopt ourselves in the future.







On Tue, Mar 31, 2015 at 10:26 AM, Ian Clelland iclell...@chromium.org
wrote:

 My thinking was that some plugins are going to need to have two very
 different designs, say for cordova-android 3.7.0 vs 4.0.0, or cordova-ios
 3.8.0 vs 4.0.0. In that case, you could do something like this;

 platform name=ios
   version match==4.0.0
 !-- tags for the new version --
   /version
   version match=4.0.0
 !-- tags for the backwards-compatiblity version --
   /version
 /platform

 which i don't think you could do with the engine tags -- with engine
 either all of the platform files are installed, or none of them are.

 Another way to do this would be to allow multiple versions to be available
 on the CPR or on npm, and have logic to decide the best version of the
 plugin to install. (with the ability to successfully install nothing if
 that's the right choice)

 On Tue, Mar 31, 2015 at 1:17 PM, Steven Gill stevengil...@gmail.com
 wrote:

  Ian, instead of adding a version tag in plugin.xml, why don't we use the
  engine tag in plugins package.json?
 
  Something like:
 
  {
engines : {
  cordova-android : 4.0.0,
  cordova-ios : =3.0.0 4.0
}
  }
 
 
  If the user doesn't have the specified platform versions installed, user
  gets a warning and plugin doesn't install. If no engine is specified,
  install away.
 
  Thoughts?
 
  On Mon, Mar 30, 2015 at 12:49 PM, Ian Clelland iclell...@chromium.org
  wrote:
 
   So this isn't a -1, unless we can't fix the problem in cordova-lib. And
   it's okay, I think, to fix it in cordova-lib/master and release that as
   well. Nothing is actually broken by publishing either app-hello-world
 or
   plugin-whitelist until we release a version of tools that is pinned to
  the
   new hello-world.
  
  
   On Mon, Mar 30, 2015 at 3:40 PM, Mark Koudritsky kam...@google.com
   wrote:
  
Looks like this breaks on cordova-android 3.7.1 (currently latest
   released)
   
cordova-app-hello-world requires the whitelist plugin
whitelist plugin depends on cordova-android 4.0 via the engine tag
engine name=cordova-android version==4.0.0-dev /
The resulting error message is
Plugin doesn't support this project's cordova-android version.
cordova-android: 3.7.1, failed version requirement: =4.0.0-dev
   
Simply removing the engine tag results in compile errors. (change
in CustomConfigXmlParser.parse() signature).
   
Any ideas on how to solve this would be appreciated. Ideas we came up
   with
in a quick discussion:
   
1. Add ignore attribute to the engine tag that would result in
  plugin
being silently ignored for incompatible engines rather than going
 down
  in
flames.
2. Add either version child or version attribute to the
 platform
   tag
in plugin.xml
   
  
   This is my favorite idea so far -- I think we could do something like
  this:
   plugin ... 
 platform name=android
   version match==4.0.0
 !-- tags --
   /version
 /platform
   /plugin
  
   I think this is overdue, and we'll find it useful as we move from 3.x
 to
   4.x on other platforms as well. We would allow multiple version tags
   inside of each platform, and any tags outside of the version tags
 are
   the default if nothing matches.
  
   In this case, there won't be any tags outside of the version tag, so
  the
   fallback for 3.x is to install nothing, but succeed.
  
   Ian
  
  
   
On Fri, Mar 27, 2015 at 4:31 PM, Andrew Grieve agri...@chromium.org
 
wrote:
   
 +1

 * Tested that both plugins compile on Android
 * Tested that the non-legacy plugin does what its supposed to on
   Android

 On Thu, Mar 26, 2015 at 7:46 PM, Steven Gill 
 stevengil...@gmail.com
  
 wrote:

  Please review and vote on the releases of
 cordova-plugin-whitelist
   and
  cordova-plugin-legacy-whitelist plugins.
 
  Release issue: https://issues.apache.org/jira/browse/CB-8739
 
  The plugins have been published to
  dist

Re: [VOTE] Cordova-Plugin-Whitelist and Cordova-Plugin-Legacy-Whitelist Plugins Release (attempt 2)

[Mark Koudritsky]

Looks like this breaks on cordova-android 3.7.1 (currently latest released)

cordova-app-hello-world requires the whitelist plugin
whitelist plugin depends on cordova-android 4.0 via the engine tag
engine name=cordova-android version==4.0.0-dev /
The resulting error message is
Plugin doesn't support this project's cordova-android version.
cordova-android: 3.7.1, failed version requirement: =4.0.0-dev

Simply removing the engine tag results in compile errors. (change
in CustomConfigXmlParser.parse() signature).

Any ideas on how to solve this would be appreciated. Ideas we came up with
in a quick discussion:

1. Add ignore attribute to the engine tag that would result in plugin
being silently ignored for incompatible engines rather than going down in
flames.
2. Add either version child or version attribute to the platform tag
in plugin.xml


On Fri, Mar 27, 2015 at 4:31 PM, Andrew Grieve agri...@chromium.org wrote:

 +1

 * Tested that both plugins compile on Android
 * Tested that the non-legacy plugin does what its supposed to on Android

 On Thu, Mar 26, 2015 at 7:46 PM, Steven Gill stevengil...@gmail.com
 wrote:

  Please review and vote on the releases of cordova-plugin-whitelist and
  cordova-plugin-legacy-whitelist plugins.
 
  Release issue: https://issues.apache.org/jira/browse/CB-8739
 
  The plugins have been published to
  dist/dev:https://dist.apache.org/repos/dist/dev/cordova/CB-8739/
 
  The packages were published from their corresponding git tags:
  cordova-plugin-whitelist: 1.0.0
  (38f5a9fa2c)cordova-plugin-legacy-whitelist: 1.0.0 (1ce26eba64)
 
  Upon a successful vote I will upload the archives to dist/ and upload
  them to npm.
 
  Voting guidelines:
 
 https://github.com/apache/cordova-coho/blob/master/docs/release-voting.md
 
  Voting will go on for a minimum of 48 hours.
 
  I vote +1:
  * Ran coho audit-license-headers over the relevant repos
  * Ran coho check-license to ensure all dependencies and
  subdependencies have Apache-compatible licenses
 

Re: [VOTE] Cordova-Plugin-Whitelist and Cordova-Plugin-Legacy-Whitelist Plugins Release (attempt 2)

[Ian Clelland]

So this isn't a -1, unless we can't fix the problem in cordova-lib. And
it's okay, I think, to fix it in cordova-lib/master and release that as
well. Nothing is actually broken by publishing either app-hello-world or
plugin-whitelist until we release a version of tools that is pinned to the
new hello-world.


On Mon, Mar 30, 2015 at 3:40 PM, Mark Koudritsky kam...@google.com wrote:

 Looks like this breaks on cordova-android 3.7.1 (currently latest released)

 cordova-app-hello-world requires the whitelist plugin
 whitelist plugin depends on cordova-android 4.0 via the engine tag
 engine name=cordova-android version==4.0.0-dev /
 The resulting error message is
 Plugin doesn't support this project's cordova-android version.
 cordova-android: 3.7.1, failed version requirement: =4.0.0-dev

 Simply removing the engine tag results in compile errors. (change
 in CustomConfigXmlParser.parse() signature).

 Any ideas on how to solve this would be appreciated. Ideas we came up with
 in a quick discussion:

 1. Add ignore attribute to the engine tag that would result in plugin
 being silently ignored for incompatible engines rather than going down in
 flames.
 2. Add either version child or version attribute to the platform tag
 in plugin.xml


This is my favorite idea so far -- I think we could do something like this:
plugin ... 
  platform name=android
version match==4.0.0
  !-- tags --
/version
  /platform
/plugin

I think this is overdue, and we'll find it useful as we move from 3.x to
4.x on other platforms as well. We would allow multiple version tags
inside of each platform, and any tags outside of the version tags are
the default if nothing matches.

In this case, there won't be any tags outside of the version tag, so the
fallback for 3.x is to install nothing, but succeed.

Ian



 On Fri, Mar 27, 2015 at 4:31 PM, Andrew Grieve agri...@chromium.org
 wrote:

  +1
 
  * Tested that both plugins compile on Android
  * Tested that the non-legacy plugin does what its supposed to on Android
 
  On Thu, Mar 26, 2015 at 7:46 PM, Steven Gill stevengil...@gmail.com
  wrote:
 
   Please review and vote on the releases of cordova-plugin-whitelist and
   cordova-plugin-legacy-whitelist plugins.
  
   Release issue: https://issues.apache.org/jira/browse/CB-8739
  
   The plugins have been published to
   dist/dev:https://dist.apache.org/repos/dist/dev/cordova/CB-8739/
  
   The packages were published from their corresponding git tags:
   cordova-plugin-whitelist: 1.0.0
   (38f5a9fa2c)cordova-plugin-legacy-whitelist: 1.0.0 (1ce26eba64)
  
   Upon a successful vote I will upload the archives to dist/ and upload
   them to npm.
  
   Voting guidelines:
  
 
 https://github.com/apache/cordova-coho/blob/master/docs/release-voting.md
  
   Voting will go on for a minimum of 48 hours.
  
   I vote +1:
   * Ran coho audit-license-headers over the relevant repos
   * Ran coho check-license to ensure all dependencies and
   subdependencies have Apache-compatible licenses
  
 

Re: [VOTE] Cordova-Plugin-Whitelist and Cordova-Plugin-Legacy-Whitelist Plugins Release (attempt 2)

[Mark Koudritsky]

Another quick option for now: we can pin hello-world version in
cordova-lib's package.json to 3.8.0 which doesn't use the whitelist
plugin.  Later, when we release the tools pinned to cordova-android 4.0 we
will have to change the hello-world dep to ^3.9.0.
This way it's a minimal change to cordova-lib and we can go ahead with this
vote.

On Mon, Mar 30, 2015 at 3:49 PM, Ian Clelland iclell...@chromium.org
wrote:

 So this isn't a -1, unless we can't fix the problem in cordova-lib. And
 it's okay, I think, to fix it in cordova-lib/master and release that as
 well. Nothing is actually broken by publishing either app-hello-world or
 plugin-whitelist until we release a version of tools that is pinned to the
 new hello-world.


 On Mon, Mar 30, 2015 at 3:40 PM, Mark Koudritsky kam...@google.com
 wrote:

  Looks like this breaks on cordova-android 3.7.1 (currently latest
 released)
 
  cordova-app-hello-world requires the whitelist plugin
  whitelist plugin depends on cordova-android 4.0 via the engine tag
  engine name=cordova-android version==4.0.0-dev /
  The resulting error message is
  Plugin doesn't support this project's cordova-android version.
  cordova-android: 3.7.1, failed version requirement: =4.0.0-dev
 
  Simply removing the engine tag results in compile errors. (change
  in CustomConfigXmlParser.parse() signature).
 
  Any ideas on how to solve this would be appreciated. Ideas we came up
 with
  in a quick discussion:
 
  1. Add ignore attribute to the engine tag that would result in plugin
  being silently ignored for incompatible engines rather than going down in
  flames.
  2. Add either version child or version attribute to the platform
 tag
  in plugin.xml
 

 This is my favorite idea so far -- I think we could do something like this:
 plugin ... 
   platform name=android
 version match==4.0.0
   !-- tags --
 /version
   /platform
 /plugin

 I think this is overdue, and we'll find it useful as we move from 3.x to
 4.x on other platforms as well. We would allow multiple version tags
 inside of each platform, and any tags outside of the version tags are
 the default if nothing matches.

 In this case, there won't be any tags outside of the version tag, so the
 fallback for 3.x is to install nothing, but succeed.

 Ian


 
  On Fri, Mar 27, 2015 at 4:31 PM, Andrew Grieve agri...@chromium.org
  wrote:
 
   +1
  
   * Tested that both plugins compile on Android
   * Tested that the non-legacy plugin does what its supposed to on
 Android
  
   On Thu, Mar 26, 2015 at 7:46 PM, Steven Gill stevengil...@gmail.com
   wrote:
  
Please review and vote on the releases of cordova-plugin-whitelist
 and
cordova-plugin-legacy-whitelist plugins.
   
Release issue: https://issues.apache.org/jira/browse/CB-8739
   
The plugins have been published to
dist/dev:https://dist.apache.org/repos/dist/dev/cordova/CB-8739/
   
The packages were published from their corresponding git tags:
cordova-plugin-whitelist: 1.0.0
(38f5a9fa2c)cordova-plugin-legacy-whitelist: 1.0.0 (1ce26eba64)
   
Upon a successful vote I will upload the archives to dist/ and upload
them to npm.
   
Voting guidelines:
   
  
 
 https://github.com/apache/cordova-coho/blob/master/docs/release-voting.md
   
Voting will go on for a minimum of 48 hours.
   
I vote +1:
* Ran coho audit-license-headers over the relevant repos
* Ran coho check-license to ensure all dependencies and
subdependencies have Apache-compatible licenses
   
  
 

Re: [VOTE] Cordova-Plugin-Whitelist and Cordova-Plugin-Legacy-Whitelist Plugins Release (attempt 2)

[Andrew Grieve]

Mark - I like that idea as well.

On Mon, Mar 30, 2015 at 6:33 PM, Ian Clelland iclell...@chromium.org
wrote:

 On 30 Mar 2015 4:52 pm, Mark Koudritsky kam...@google.com wrote:
 
  Another quick option for now: we can pin hello-world version in
  cordova-lib's package.json to 3.8.0 which doesn't use the whitelist
  plugin.  Later, when we release the tools pinned to cordova-android 4.0
 we
  will have to change the hello-world dep to ^3.9.0.

 That's a good idea.

 I'll validate the plug-ins and vote later tonight.

 Ian
  This way it's a minimal change to cordova-lib and we can go ahead with
 this
  vote.
 
  On Mon, Mar 30, 2015 at 3:49 PM, Ian Clelland iclell...@chromium.org
  wrote:
 
   So this isn't a -1, unless we can't fix the problem in cordova-lib. And
   it's okay, I think, to fix it in cordova-lib/master and release that as
   well. Nothing is actually broken by publishing either app-hello-world
 or
   plugin-whitelist until we release a version of tools that is pinned to
 the
   new hello-world.
  
  
   On Mon, Mar 30, 2015 at 3:40 PM, Mark Koudritsky kam...@google.com
   wrote:
  
Looks like this breaks on cordova-android 3.7.1 (currently latest
   released)
   
cordova-app-hello-world requires the whitelist plugin
whitelist plugin depends on cordova-android 4.0 via the engine tag
engine name=cordova-android version==4.0.0-dev /
The resulting error message is
Plugin doesn't support this project's cordova-android version.
cordova-android: 3.7.1, failed version requirement: =4.0.0-dev
   
Simply removing the engine tag results in compile errors. (change
in CustomConfigXmlParser.parse() signature).
   
Any ideas on how to solve this would be appreciated. Ideas we came up
   with
in a quick discussion:
   
1. Add ignore attribute to the engine tag that would result in
 plugin
being silently ignored for incompatible engines rather than going
 down in
flames.
2. Add either version child or version attribute to the
 platform
   tag
in plugin.xml
   
  
   This is my favorite idea so far -- I think we could do something like
 this:
   plugin ... 
 platform name=android
   version match==4.0.0
 !-- tags --
   /version
 /platform
   /plugin
  
   I think this is overdue, and we'll find it useful as we move from 3.x
 to
   4.x on other platforms as well. We would allow multiple version tags
   inside of each platform, and any tags outside of the version tags
 are
   the default if nothing matches.
  
   In this case, there won't be any tags outside of the version tag, so
 the
   fallback for 3.x is to install nothing, but succeed.
  
   Ian
  
  
   
On Fri, Mar 27, 2015 at 4:31 PM, Andrew Grieve agri...@chromium.org
 
wrote:
   
 +1

 * Tested that both plugins compile on Android
 * Tested that the non-legacy plugin does what its supposed to on
   Android

 On Thu, Mar 26, 2015 at 7:46 PM, Steven Gill 
 stevengil...@gmail.com
 
 wrote:

  Please review and vote on the releases of
 cordova-plugin-whitelist
   and
  cordova-plugin-legacy-whitelist plugins.
 
  Release issue: https://issues.apache.org/jira/browse/CB-8739
 
  The plugins have been published to
  dist/dev:https://dist.apache.org/repos/dist/dev/cordova/CB-8739/
 
  The packages were published from their corresponding git tags:
  cordova-plugin-whitelist: 1.0.0
  (38f5a9fa2c)cordova-plugin-legacy-whitelist: 1.0.0 (1ce26eba64)
 
  Upon a successful vote I will upload the archives to dist/ and
 upload
  them to npm.
 
  Voting guidelines:
 

   
  
 https://github.com/apache/cordova-coho/blob/master/docs/release-voting.md
 
  Voting will go on for a minimum of 48 hours.
 
  I vote +1:
  * Ran coho audit-license-headers over the relevant repos
  * Ran coho check-license to ensure all dependencies and
  subdependencies have Apache-compatible licenses
 

   
  

Re: [VOTE] Cordova-Plugin-Whitelist and Cordova-Plugin-Legacy-Whitelist Plugins Release (attempt 2)

[Steven Gill]

I like the sound of both ideas.

Marks idea to make the default hello world app not install whitelist until
android 4.0 (use 3.8.0 for app hello world)

Ian, that looks like a good proposal. We are definitely overdo for
something to properly track versions. Users should get a warning when a
plugin doesn't get installed due to version issues.

-Steve
On Mar 30, 2015 6:18 PM, Andrew Grieve agri...@chromium.org wrote:

 Mark - I like that idea as well.

 On Mon, Mar 30, 2015 at 6:33 PM, Ian Clelland iclell...@chromium.org
 wrote:

  On 30 Mar 2015 4:52 pm, Mark Koudritsky kam...@google.com wrote:
  
   Another quick option for now: we can pin hello-world version in
   cordova-lib's package.json to 3.8.0 which doesn't use the whitelist
   plugin.  Later, when we release the tools pinned to cordova-android 4.0
  we
   will have to change the hello-world dep to ^3.9.0.
 
  That's a good idea.
 
  I'll validate the plug-ins and vote later tonight.
 
  Ian
   This way it's a minimal change to cordova-lib and we can go ahead with
  this
   vote.
  
   On Mon, Mar 30, 2015 at 3:49 PM, Ian Clelland iclell...@chromium.org
   wrote:
  
So this isn't a -1, unless we can't fix the problem in cordova-lib.
 And
it's okay, I think, to fix it in cordova-lib/master and release that
 as
well. Nothing is actually broken by publishing either app-hello-world
  or
plugin-whitelist until we release a version of tools that is pinned
 to
  the
new hello-world.
   
   
On Mon, Mar 30, 2015 at 3:40 PM, Mark Koudritsky kam...@google.com
wrote:
   
 Looks like this breaks on cordova-android 3.7.1 (currently latest
released)

 cordova-app-hello-world requires the whitelist plugin
 whitelist plugin depends on cordova-android 4.0 via the engine tag
 engine name=cordova-android version==4.0.0-dev /
 The resulting error message is
 Plugin doesn't support this project's cordova-android version.
 cordova-android: 3.7.1, failed version requirement: =4.0.0-dev

 Simply removing the engine tag results in compile errors. (change
 in CustomConfigXmlParser.parse() signature).

 Any ideas on how to solve this would be appreciated. Ideas we came
 up
with
 in a quick discussion:

 1. Add ignore attribute to the engine tag that would result in
  plugin
 being silently ignored for incompatible engines rather than going
  down in
 flames.
 2. Add either version child or version attribute to the
  platform
tag
 in plugin.xml

   
This is my favorite idea so far -- I think we could do something like
  this:
plugin ... 
  platform name=android
version match==4.0.0
  !-- tags --
/version
  /platform
/plugin
   
I think this is overdue, and we'll find it useful as we move from 3.x
  to
4.x on other platforms as well. We would allow multiple version
 tags
inside of each platform, and any tags outside of the version tags
  are
the default if nothing matches.
   
In this case, there won't be any tags outside of the version tag,
 so
  the
fallback for 3.x is to install nothing, but succeed.
   
Ian
   
   

 On Fri, Mar 27, 2015 at 4:31 PM, Andrew Grieve 
 agri...@chromium.org
  
 wrote:

  +1
 
  * Tested that both plugins compile on Android
  * Tested that the non-legacy plugin does what its supposed to on
Android
 
  On Thu, Mar 26, 2015 at 7:46 PM, Steven Gill 
  stevengil...@gmail.com
  
  wrote:
 
   Please review and vote on the releases of
  cordova-plugin-whitelist
and
   cordova-plugin-legacy-whitelist plugins.
  
   Release issue: https://issues.apache.org/jira/browse/CB-8739
  
   The plugins have been published to
   dist/dev:
 https://dist.apache.org/repos/dist/dev/cordova/CB-8739/
  
   The packages were published from their corresponding git tags:
   cordova-plugin-whitelist: 1.0.0
   (38f5a9fa2c)cordova-plugin-legacy-whitelist: 1.0.0 (1ce26eba64)
  
   Upon a successful vote I will upload the archives to dist/ and
  upload
   them to npm.
  
   Voting guidelines:
  
 

   
 
 https://github.com/apache/cordova-coho/blob/master/docs/release-voting.md
  
   Voting will go on for a minimum of 48 hours.
  
   I vote +1:
   * Ran coho audit-license-headers over the relevant repos
   * Ran coho check-license to ensure all dependencies and
   subdependencies have Apache-compatible licenses
  
 

   
 

Re: [VOTE] Cordova-Plugin-Whitelist and Cordova-Plugin-Legacy-Whitelist Plugins Release (attempt 2)

[Andrew Grieve]

+1

* Tested that both plugins compile on Android
* Tested that the non-legacy plugin does what its supposed to on Android

On Thu, Mar 26, 2015 at 7:46 PM, Steven Gill stevengil...@gmail.com wrote:

 Please review and vote on the releases of cordova-plugin-whitelist and
 cordova-plugin-legacy-whitelist plugins.

 Release issue: https://issues.apache.org/jira/browse/CB-8739

 The plugins have been published to
 dist/dev:https://dist.apache.org/repos/dist/dev/cordova/CB-8739/

 The packages were published from their corresponding git tags:
 cordova-plugin-whitelist: 1.0.0
 (38f5a9fa2c)cordova-plugin-legacy-whitelist: 1.0.0 (1ce26eba64)

 Upon a successful vote I will upload the archives to dist/ and upload
 them to npm.

 Voting guidelines:
 https://github.com/apache/cordova-coho/blob/master/docs/release-voting.md

 Voting will go on for a minimum of 48 hours.

 I vote +1:
 * Ran coho audit-license-headers over the relevant repos
 * Ran coho check-license to ensure all dependencies and
 subdependencies have Apache-compatible licenses

RE: [VOTE] Cordova-Plugin-Whitelist and Cordova-Plugin-Legacy-Whitelist Plugins Release

[Parashuram N (MS OPEN TECH)]

Should we have to restart the vote thread, now that the tag will change ? 

-Original Message-
From: agri...@google.com [mailto:agri...@google.com] On Behalf Of Andrew Grieve
Sent: Thursday, March 26, 2015 7:41 AM
To: dev
Subject: Re: [VOTE] Cordova-Plugin-Whitelist and 
Cordova-Plugin-Legacy-Whitelist Plugins Release

That'd be pretty sad if it were expected :P.

Totally my bad on this one. I've committed a fix.

On Thu, Mar 26, 2015 at 9:40 AM, Alexander Sorokin (Akvelon)  
v-als...@microsoft.com wrote:

 Hi guys,

 I am getting the following error when trying to build a project with 
 legacy-whitelist plugin installed for android@4.0.0-dev:

 C:\Projects\Cordova\mobspec-android\platforms\android\src\org\apache\cordova\whitelist\LegacyWhitelistPlugin.java:44:
 error: cannot find symbol
 public void handleStartTag(XmlPullParser xml) {
^
   symbol: class XmlPullParser
 C:\Projects\Cordova\mobspec-android\platforms\android\src\org\apache\cordova\whitelist\LegacyWhitelistPlugin.java:68:
 error: cannot find symbol
 public void handleEndTag(XmlPullParser xml) {
  ^
   symbol: class XmlPullParser


 Is this expected?

 Thanks,
 Alexander Sorokin

 -Original Message-
 From: Steven Gill [mailto:stevengil...@gmail.com]
 Sent: Wednesday, March 25, 2015 23:23
 To: dev@cordova.apache.org
 Subject: [VOTE] Cordova-Plugin-Whitelist and 
 Cordova-Plugin-Legacy-Whitelist Plugins Release

 Please review and vote on the releases of cordova-plugin-whitelist and 
 cordova-plugin-legacy-whitelist plugins.

 Release issue: https://issues.apache.org/jira/browse/CB-8739

 The plugins have been published to
 dist/dev:https://dist.apache.org/repos/dist/dev/cordova/CB-8739/

 The packages were published from their corresponding git tags:
 cordova-plugin-whitelist: 1.0.0 (38f5a9fa2c)
 cordova-plugin-legacy-whitelist: 1.0.0 (b4e1b3726a)

 Upon a successful vote I will upload the archives to dist/ and upload 
 them to npm.

 Voting guidelines:
 https://github.com/apache/cordova-coho/blob/master/docs/release-voting
 .md

 Voting will go on for a minimum of 48 hours.

 I vote +1:
 * Ran coho audit-license-headers over the relevant repos
 * Ran coho check-license to ensure all dependencies and 
 subdependencies have Apache-compatible licenses

 -
 To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
 For additional commands, e-mail: dev-h...@cordova.apache.org

Re: [VOTE] Cordova-Plugin-Whitelist and Cordova-Plugin-Legacy-Whitelist Plugins Release

[Ian Clelland]

Yeah :(

Hash changes, code changes, checksums and pgp signatures change... all
necessitates a new vote.
At least we get to abort early.

On Thu, Mar 26, 2015 at 1:28 PM, Parashuram N (MS OPEN TECH) 
panar...@microsoft.com wrote:

 Should we have to restart the vote thread, now that the tag will change ?

 -Original Message-
 From: agri...@google.com [mailto:agri...@google.com] On Behalf Of Andrew
 Grieve
 Sent: Thursday, March 26, 2015 7:41 AM
 To: dev
 Subject: Re: [VOTE] Cordova-Plugin-Whitelist and
 Cordova-Plugin-Legacy-Whitelist Plugins Release

 That'd be pretty sad if it were expected :P.

 Totally my bad on this one. I've committed a fix.

 On Thu, Mar 26, 2015 at 9:40 AM, Alexander Sorokin (Akvelon) 
 v-als...@microsoft.com wrote:

  Hi guys,
 
  I am getting the following error when trying to build a project with
  legacy-whitelist plugin installed for android@4.0.0-dev:
 
 
 C:\Projects\Cordova\mobspec-android\platforms\android\src\org\apache\cordova\whitelist\LegacyWhitelistPlugin.java:44:
  error: cannot find symbol
  public void handleStartTag(XmlPullParser xml) {
 ^
symbol: class XmlPullParser
 
 C:\Projects\Cordova\mobspec-android\platforms\android\src\org\apache\cordova\whitelist\LegacyWhitelistPlugin.java:68:
  error: cannot find symbol
  public void handleEndTag(XmlPullParser xml) {
   ^
symbol: class XmlPullParser
 
 
  Is this expected?
 
  Thanks,
  Alexander Sorokin
 
  -Original Message-
  From: Steven Gill [mailto:stevengil...@gmail.com]
  Sent: Wednesday, March 25, 2015 23:23
  To: dev@cordova.apache.org
  Subject: [VOTE] Cordova-Plugin-Whitelist and
  Cordova-Plugin-Legacy-Whitelist Plugins Release
 
  Please review and vote on the releases of cordova-plugin-whitelist and
  cordova-plugin-legacy-whitelist plugins.
 
  Release issue: https://issues.apache.org/jira/browse/CB-8739
 
  The plugins have been published to
  dist/dev:https://dist.apache.org/repos/dist/dev/cordova/CB-8739/
 
  The packages were published from their corresponding git tags:
  cordova-plugin-whitelist: 1.0.0 (38f5a9fa2c)
  cordova-plugin-legacy-whitelist: 1.0.0 (b4e1b3726a)
 
  Upon a successful vote I will upload the archives to dist/ and upload
  them to npm.
 
  Voting guidelines:
  https://github.com/apache/cordova-coho/blob/master/docs/release-voting
  .md
 
  Voting will go on for a minimum of 48 hours.
 
  I vote +1:
  * Ran coho audit-license-headers over the relevant repos
  * Ran coho check-license to ensure all dependencies and
  subdependencies have Apache-compatible licenses
 
  -
  To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
  For additional commands, e-mail: dev-h...@cordova.apache.org
 
 

RE: [VOTE] Cordova-Plugin-Whitelist and Cordova-Plugin-Legacy-Whitelist Plugins Release

[Alexander Sorokin (Akvelon)]

Hi guys,

I am getting the following error when trying to build a project with 
legacy-whitelist plugin installed for android@4.0.0-dev:

C:\Projects\Cordova\mobspec-android\platforms\android\src\org\apache\cordova\whitelist\LegacyWhitelistPlugin.java:44:
 error: cannot find symbol
public void handleStartTag(XmlPullParser xml) {
   ^
  symbol: class XmlPullParser
C:\Projects\Cordova\mobspec-android\platforms\android\src\org\apache\cordova\whitelist\LegacyWhitelistPlugin.java:68:
 error: cannot find symbol
public void handleEndTag(XmlPullParser xml) {
 ^
  symbol: class XmlPullParser


Is this expected?

Thanks,
Alexander Sorokin

-Original Message-
From: Steven Gill [mailto:stevengil...@gmail.com] 
Sent: Wednesday, March 25, 2015 23:23
To: dev@cordova.apache.org
Subject: [VOTE] Cordova-Plugin-Whitelist and Cordova-Plugin-Legacy-Whitelist 
Plugins Release

Please review and vote on the releases of cordova-plugin-whitelist and 
cordova-plugin-legacy-whitelist plugins.

Release issue: https://issues.apache.org/jira/browse/CB-8739

The plugins have been published to
dist/dev:https://dist.apache.org/repos/dist/dev/cordova/CB-8739/

The packages were published from their corresponding git tags:
cordova-plugin-whitelist: 1.0.0 (38f5a9fa2c)
cordova-plugin-legacy-whitelist: 1.0.0 (b4e1b3726a)

Upon a successful vote I will upload the archives to dist/ and upload them to 
npm.

Voting guidelines:
https://github.com/apache/cordova-coho/blob/master/docs/release-voting.md

Voting will go on for a minimum of 48 hours.

I vote +1:
* Ran coho audit-license-headers over the relevant repos
* Ran coho check-license to ensure all dependencies and subdependencies have 
Apache-compatible licenses

-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org

Re: [VOTE] Cordova-Plugin-Whitelist and Cordova-Plugin-Legacy-Whitelist Plugins Release

[Steven Gill]

I'll send out a new one soon
On Mar 26, 2015 10:48 AM, Ian Clelland iclell...@chromium.org wrote:

 Yeah :(

 Hash changes, code changes, checksums and pgp signatures change... all
 necessitates a new vote.
 At least we get to abort early.

 On Thu, Mar 26, 2015 at 1:28 PM, Parashuram N (MS OPEN TECH) 
 panar...@microsoft.com wrote:

  Should we have to restart the vote thread, now that the tag will change ?
 
  -Original Message-
  From: agri...@google.com [mailto:agri...@google.com] On Behalf Of Andrew
  Grieve
  Sent: Thursday, March 26, 2015 7:41 AM
  To: dev
  Subject: Re: [VOTE] Cordova-Plugin-Whitelist and
  Cordova-Plugin-Legacy-Whitelist Plugins Release
 
  That'd be pretty sad if it were expected :P.
 
  Totally my bad on this one. I've committed a fix.
 
  On Thu, Mar 26, 2015 at 9:40 AM, Alexander Sorokin (Akvelon) 
  v-als...@microsoft.com wrote:
 
   Hi guys,
  
   I am getting the following error when trying to build a project with
   legacy-whitelist plugin installed for android@4.0.0-dev:
  
  
 
 C:\Projects\Cordova\mobspec-android\platforms\android\src\org\apache\cordova\whitelist\LegacyWhitelistPlugin.java:44:
   error: cannot find symbol
   public void handleStartTag(XmlPullParser xml) {
  ^
 symbol: class XmlPullParser
  
 
 C:\Projects\Cordova\mobspec-android\platforms\android\src\org\apache\cordova\whitelist\LegacyWhitelistPlugin.java:68:
   error: cannot find symbol
   public void handleEndTag(XmlPullParser xml) {
^
 symbol: class XmlPullParser
  
  
   Is this expected?
  
   Thanks,
   Alexander Sorokin
  
   -Original Message-
   From: Steven Gill [mailto:stevengil...@gmail.com]
   Sent: Wednesday, March 25, 2015 23:23
   To: dev@cordova.apache.org
   Subject: [VOTE] Cordova-Plugin-Whitelist and
   Cordova-Plugin-Legacy-Whitelist Plugins Release
  
   Please review and vote on the releases of cordova-plugin-whitelist and
   cordova-plugin-legacy-whitelist plugins.
  
   Release issue: https://issues.apache.org/jira/browse/CB-8739
  
   The plugins have been published to
   dist/dev:https://dist.apache.org/repos/dist/dev/cordova/CB-8739/
  
   The packages were published from their corresponding git tags:
   cordova-plugin-whitelist: 1.0.0 (38f5a9fa2c)
   cordova-plugin-legacy-whitelist: 1.0.0 (b4e1b3726a)
  
   Upon a successful vote I will upload the archives to dist/ and upload
   them to npm.
  
   Voting guidelines:
   https://github.com/apache/cordova-coho/blob/master/docs/release-voting
   .md
  
   Voting will go on for a minimum of 48 hours.
  
   I vote +1:
   * Ran coho audit-license-headers over the relevant repos
   * Ran coho check-license to ensure all dependencies and
   subdependencies have Apache-compatible licenses
  
   -
   To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
   For additional commands, e-mail: dev-h...@cordova.apache.org
  
  
 

[VOTE] Cordova-Plugin-Whitelist and Cordova-Plugin-Legacy-Whitelist Plugins Release (attempt 2)

[Steven Gill]

Please review and vote on the releases of cordova-plugin-whitelist and
cordova-plugin-legacy-whitelist plugins.

Release issue: https://issues.apache.org/jira/browse/CB-8739

The plugins have been published to
dist/dev:https://dist.apache.org/repos/dist/dev/cordova/CB-8739/

The packages were published from their corresponding git tags:
cordova-plugin-whitelist: 1.0.0
(38f5a9fa2c)cordova-plugin-legacy-whitelist: 1.0.0 (1ce26eba64)

Upon a successful vote I will upload the archives to dist/ and upload
them to npm.

Voting guidelines:
https://github.com/apache/cordova-coho/blob/master/docs/release-voting.md

Voting will go on for a minimum of 48 hours.

I vote +1:
* Ran coho audit-license-headers over the relevant repos
* Ran coho check-license to ensure all dependencies and
subdependencies have Apache-compatible licenses

Re: [VOTE] Cordova-Plugin-Whitelist and Cordova-Plugin-Legacy-Whitelist Plugins Release

[Steven Gill]

This vote has failed

On Thu, Mar 26, 2015 at 12:41 PM, Steven Gill stevengil...@gmail.com
wrote:

 I'll send out a new one soon
 On Mar 26, 2015 10:48 AM, Ian Clelland iclell...@chromium.org wrote:

 Yeah :(

 Hash changes, code changes, checksums and pgp signatures change... all
 necessitates a new vote.
 At least we get to abort early.

 On Thu, Mar 26, 2015 at 1:28 PM, Parashuram N (MS OPEN TECH) 
 panar...@microsoft.com wrote:

  Should we have to restart the vote thread, now that the tag will change
 ?
 
  -Original Message-
  From: agri...@google.com [mailto:agri...@google.com] On Behalf Of
 Andrew
  Grieve
  Sent: Thursday, March 26, 2015 7:41 AM
  To: dev
  Subject: Re: [VOTE] Cordova-Plugin-Whitelist and
  Cordova-Plugin-Legacy-Whitelist Plugins Release
 
  That'd be pretty sad if it were expected :P.
 
  Totally my bad on this one. I've committed a fix.
 
  On Thu, Mar 26, 2015 at 9:40 AM, Alexander Sorokin (Akvelon) 
  v-als...@microsoft.com wrote:
 
   Hi guys,
  
   I am getting the following error when trying to build a project with
   legacy-whitelist plugin installed for android@4.0.0-dev:
  
  
 
 C:\Projects\Cordova\mobspec-android\platforms\android\src\org\apache\cordova\whitelist\LegacyWhitelistPlugin.java:44:
   error: cannot find symbol
   public void handleStartTag(XmlPullParser xml) {
  ^
 symbol: class XmlPullParser
  
 
 C:\Projects\Cordova\mobspec-android\platforms\android\src\org\apache\cordova\whitelist\LegacyWhitelistPlugin.java:68:
   error: cannot find symbol
   public void handleEndTag(XmlPullParser xml) {
^
 symbol: class XmlPullParser
  
  
   Is this expected?
  
   Thanks,
   Alexander Sorokin
  
   -Original Message-
   From: Steven Gill [mailto:stevengil...@gmail.com]
   Sent: Wednesday, March 25, 2015 23:23
   To: dev@cordova.apache.org
   Subject: [VOTE] Cordova-Plugin-Whitelist and
   Cordova-Plugin-Legacy-Whitelist Plugins Release
  
   Please review and vote on the releases of cordova-plugin-whitelist and
   cordova-plugin-legacy-whitelist plugins.
  
   Release issue: https://issues.apache.org/jira/browse/CB-8739
  
   The plugins have been published to
   dist/dev:https://dist.apache.org/repos/dist/dev/cordova/CB-8739/
  
   The packages were published from their corresponding git tags:
   cordova-plugin-whitelist: 1.0.0 (38f5a9fa2c)
   cordova-plugin-legacy-whitelist: 1.0.0 (b4e1b3726a)
  
   Upon a successful vote I will upload the archives to dist/ and upload
   them to npm.
  
   Voting guidelines:
  
 https://github.com/apache/cordova-coho/blob/master/docs/release-voting
   .md
  
   Voting will go on for a minimum of 48 hours.
  
   I vote +1:
   * Ran coho audit-license-headers over the relevant repos
   * Ran coho check-license to ensure all dependencies and
   subdependencies have Apache-compatible licenses
  
   -
   To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
   For additional commands, e-mail: dev-h...@cordova.apache.org
  
  
 

Re: [VOTE] Cordova-Plugin-Whitelist and Cordova-Plugin-Legacy-Whitelist Plugins Release

[Andrew Grieve]

That'd be pretty sad if it were expected :P.

Totally my bad on this one. I've committed a fix.

On Thu, Mar 26, 2015 at 9:40 AM, Alexander Sorokin (Akvelon) 
v-als...@microsoft.com wrote:

 Hi guys,

 I am getting the following error when trying to build a project with
 legacy-whitelist plugin installed for android@4.0.0-dev:

 C:\Projects\Cordova\mobspec-android\platforms\android\src\org\apache\cordova\whitelist\LegacyWhitelistPlugin.java:44:
 error: cannot find symbol
 public void handleStartTag(XmlPullParser xml) {
^
   symbol: class XmlPullParser
 C:\Projects\Cordova\mobspec-android\platforms\android\src\org\apache\cordova\whitelist\LegacyWhitelistPlugin.java:68:
 error: cannot find symbol
 public void handleEndTag(XmlPullParser xml) {
  ^
   symbol: class XmlPullParser


 Is this expected?

 Thanks,
 Alexander Sorokin

 -Original Message-
 From: Steven Gill [mailto:stevengil...@gmail.com]
 Sent: Wednesday, March 25, 2015 23:23
 To: dev@cordova.apache.org
 Subject: [VOTE] Cordova-Plugin-Whitelist and
 Cordova-Plugin-Legacy-Whitelist Plugins Release

 Please review and vote on the releases of cordova-plugin-whitelist and
 cordova-plugin-legacy-whitelist plugins.

 Release issue: https://issues.apache.org/jira/browse/CB-8739

 The plugins have been published to
 dist/dev:https://dist.apache.org/repos/dist/dev/cordova/CB-8739/

 The packages were published from their corresponding git tags:
 cordova-plugin-whitelist: 1.0.0 (38f5a9fa2c)
 cordova-plugin-legacy-whitelist: 1.0.0 (b4e1b3726a)

 Upon a successful vote I will upload the archives to dist/ and upload them
 to npm.

 Voting guidelines:
 https://github.com/apache/cordova-coho/blob/master/docs/release-voting.md

 Voting will go on for a minimum of 48 hours.

 I vote +1:
 * Ran coho audit-license-headers over the relevant repos
 * Ran coho check-license to ensure all dependencies and subdependencies
 have Apache-compatible licenses

 -
 To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
 For additional commands, e-mail: dev-h...@cordova.apache.org

Re: whitelist as a plugin

[Ian Clelland]

I'm still thinking in the old CadVer world here -- yes, it is a breaking
change, and would absolutely require a major version change. 3.7.0 is
certainly not a possible version number for it.

I suppose the issue of master vs. 4.0.x in my head was whether the feature
branch should be rooted on the branch named 4.0.x, and so depend on
pluggable-webviews, or rooted on where master is today, and so be eligible
for landing before the webview breakout.

Of course, I'd really love both for pluggable webviews to ship, and to not
have to do the whitelist work twice, so I'm happy with basing it on the
4.0.x branch.


On Thu, Oct 9, 2014 at 2:28 PM, Andrew Grieve agri...@chromium.org wrote:

 It's technically a breaking change, so agree 4.0.x makes sense.

 On Thu, Oct 9, 2014 at 12:09 PM, Joe Bowser bows...@gmail.com wrote:

  This should land in 4.0.x
  On Oct 9, 2014 7:38 AM, Ian Clelland iclell...@chromium.org wrote:
 
   I'm running into more and more problems caused by the whitelist (today,
   it's because of the dual use of the internal whitelist for should be
  able
   to navigate to URL and should be able to XHR from URL)
  
   I'm going to start to pull it out, on a topic branch based off of
 Android
   4.0.x right now. I'll create a JIRA issue to track the work.
  
   Is 4.0.x the best place for this to land, or is there any support for
   putting it on master as well, for an eventual 3.7 release?
  
  
   On Wed, Jul 9, 2014 at 1:22 PM, Shazron shaz...@gmail.com wrote:
  
+1 to remove it  for all the above reasons (and WKWebView in iOS 8)
Those interested in this security blanket for checkmark ✓ purposes
 can
install the plugin, and perhaps maintain it as well.
   
On Wed, Jul 9, 2014 at 10:17 AM, Brian LeRoux b...@brian.io wrote:
 Or remove it altogether and let the evolution of that code be
   maintained
by
 those interested in the narrative it provides? :)

 On Wednesday, July 9, 2014, Andrew Grieve agri...@chromium.org
   wrote:

 Sounds like we both agree that it doesn't work and adds a false
  sense
   of
 security (to those that do opt into it) :P.

 Maybe what we should do is redesign the whitelist to do something
  more
 useful.

 e.g. A whitelist that says what URLs you can navigate to is useful
  and
easy
 to implement. Let's just drop the trying to stop network requests
aspect of
 it?


 On Tue, Jul 8, 2014 at 12:54 PM, Joe Bowser bows...@gmail.com
 javascript:; wrote:

  I'm in agreement with Andrew on this one.  If we can get CSP
   working,
  that's a far better solution than our Whitelist, which was done
  because it was needed at the time for the enterprise use case
 that
   IBM
  had.  I don't think we're ever going to stop are users from
 doing
   dumb
  things like including thirdpartyadnetworkthatdoesnoteusehttps.js
  in
  their apps any time soon, but they'll have to jump through more
   hoops
  to do dumb things, and making dumb things harder is a good
 thing.
 
  On Tue, Jul 8, 2014 at 9:47 AM, Brian LeRoux b...@brian.io
javascript:;
 wrote:
   Heh. Why do we always seem to be at the opposite end of
considerations?
   (Not a bad thing anyhow. ;)
  
   So making whitelist a plugin would most certainly isolate the
  code
 which
   would help us better understand:
  
   1.) where the surface for bugs are (we seem to miss/find new
security
  holes
   each quarter…)
   2.) if people actually use it
  
   I'm more interested in #2. I suspect the only people whom do
 use
   it
are
   security researchers disproving the whitelist veracity. I feel
   this
API
  was
   a mistake, is misleading, and ultimately leads to poor web
   security
   practices wrt 3rd part scripts. I'd like the evidence to
 remove
  it
   completely and making it a plugin would do that. (And still
  allow
for
 its
   existence to those whom want to contribute to a marketing
  based
api.)
  
  
  
   On Tue, Jul 8, 2014 at 6:52 AM, Andrew Grieve 
   agri...@chromium.org
 javascript:;
  wrote:
  
   I don't think moving the whitelist to a plugin would aid in
 its
   understanding. Right now the whitelist is used for two
 things:
  
   1. Whether to allow network requests through (although this
 is
broken
  for
   audio/video on iOS, and broken for them + websockets on
   Android
   2. Whether to allow top frame navigations (e.g. clicking a
 link
   to
  http://
   *
   opens in system browser vs. webview)
  
   #1 doesn't work very well due to technical limitations.
   #2 is actually the more import one security-wise I think,
 and I
don't
  think
   should be relegated to a plugin.
  
   I'm hoping medium-term that CSP can replace the use-case of
 #1

Re: whitelist as a plugin

[Joe Bowser]

I'd like to see this tie into Pluggable WebViews because based on the work
I'm doing on MozillaView, I think we're going to need it broken out into a
plugin and an API added for it.  That said, I'm hoping the delta isn't too
different, because if we decide to completely redesign the Pluggable
WebView API, I think it'll be another six months until this feature sees
the light of day.

On Fri, Oct 10, 2014 at 8:17 AM, Ian Clelland iclell...@chromium.org
wrote:

 I'm still thinking in the old CadVer world here -- yes, it is a breaking
 change, and would absolutely require a major version change. 3.7.0 is
 certainly not a possible version number for it.

 I suppose the issue of master vs. 4.0.x in my head was whether the feature
 branch should be rooted on the branch named 4.0.x, and so depend on
 pluggable-webviews, or rooted on where master is today, and so be eligible
 for landing before the webview breakout.

 Of course, I'd really love both for pluggable webviews to ship, and to not
 have to do the whitelist work twice, so I'm happy with basing it on the
 4.0.x branch.


 On Thu, Oct 9, 2014 at 2:28 PM, Andrew Grieve agri...@chromium.org
 wrote:

  It's technically a breaking change, so agree 4.0.x makes sense.
 
  On Thu, Oct 9, 2014 at 12:09 PM, Joe Bowser bows...@gmail.com wrote:
 
   This should land in 4.0.x
   On Oct 9, 2014 7:38 AM, Ian Clelland iclell...@chromium.org wrote:
  
I'm running into more and more problems caused by the whitelist
 (today,
it's because of the dual use of the internal whitelist for should be
   able
to navigate to URL and should be able to XHR from URL)
   
I'm going to start to pull it out, on a topic branch based off of
  Android
4.0.x right now. I'll create a JIRA issue to track the work.
   
Is 4.0.x the best place for this to land, or is there any support for
putting it on master as well, for an eventual 3.7 release?
   
   
On Wed, Jul 9, 2014 at 1:22 PM, Shazron shaz...@gmail.com wrote:
   
 +1 to remove it  for all the above reasons (and WKWebView in iOS 8)
 Those interested in this security blanket for checkmark ✓ purposes
  can
 install the plugin, and perhaps maintain it as well.

 On Wed, Jul 9, 2014 at 10:17 AM, Brian LeRoux b...@brian.io wrote:
  Or remove it altogether and let the evolution of that code be
maintained
 by
  those interested in the narrative it provides? :)
 
  On Wednesday, July 9, 2014, Andrew Grieve agri...@chromium.org
wrote:
 
  Sounds like we both agree that it doesn't work and adds a false
   sense
of
  security (to those that do opt into it) :P.
 
  Maybe what we should do is redesign the whitelist to do
 something
   more
  useful.
 
  e.g. A whitelist that says what URLs you can navigate to is
 useful
   and
 easy
  to implement. Let's just drop the trying to stop network
 requests
 aspect of
  it?
 
 
  On Tue, Jul 8, 2014 at 12:54 PM, Joe Bowser bows...@gmail.com
  javascript:; wrote:
 
   I'm in agreement with Andrew on this one.  If we can get CSP
working,
   that's a far better solution than our Whitelist, which was
 done
   because it was needed at the time for the enterprise use case
  that
IBM
   had.  I don't think we're ever going to stop are users from
  doing
dumb
   things like including
 thirdpartyadnetworkthatdoesnoteusehttps.js
   in
   their apps any time soon, but they'll have to jump through
 more
hoops
   to do dumb things, and making dumb things harder is a good
  thing.
  
   On Tue, Jul 8, 2014 at 9:47 AM, Brian LeRoux b...@brian.io
 javascript:;
  wrote:
Heh. Why do we always seem to be at the opposite end of
 considerations?
(Not a bad thing anyhow. ;)
   
So making whitelist a plugin would most certainly isolate
 the
   code
  which
would help us better understand:
   
1.) where the surface for bugs are (we seem to miss/find new
 security
   holes
each quarter…)
2.) if people actually use it
   
I'm more interested in #2. I suspect the only people whom do
  use
it
 are
security researchers disproving the whitelist veracity. I
 feel
this
 API
   was
a mistake, is misleading, and ultimately leads to poor web
security
practices wrt 3rd part scripts. I'd like the evidence to
  remove
   it
completely and making it a plugin would do that. (And still
   allow
 for
  its
existence to those whom want to contribute to a marketing
   based
 api.)
   
   
   
On Tue, Jul 8, 2014 at 6:52 AM, Andrew Grieve 
agri...@chromium.org
  javascript:;
   wrote:
   
I don't think moving the whitelist to a plugin would aid in
  its
understanding. Right now the whitelist is used for two
  things

Re: whitelist as a plugin

[Ian Clelland]

I'm running into more and more problems caused by the whitelist (today,
it's because of the dual use of the internal whitelist for should be able
to navigate to URL and should be able to XHR from URL)

I'm going to start to pull it out, on a topic branch based off of Android
4.0.x right now. I'll create a JIRA issue to track the work.

Is 4.0.x the best place for this to land, or is there any support for
putting it on master as well, for an eventual 3.7 release?


On Wed, Jul 9, 2014 at 1:22 PM, Shazron shaz...@gmail.com wrote:

 +1 to remove it  for all the above reasons (and WKWebView in iOS 8)
 Those interested in this security blanket for checkmark ✓ purposes can
 install the plugin, and perhaps maintain it as well.

 On Wed, Jul 9, 2014 at 10:17 AM, Brian LeRoux b...@brian.io wrote:
  Or remove it altogether and let the evolution of that code be maintained
 by
  those interested in the narrative it provides? :)
 
  On Wednesday, July 9, 2014, Andrew Grieve agri...@chromium.org wrote:
 
  Sounds like we both agree that it doesn't work and adds a false sense of
  security (to those that do opt into it) :P.
 
  Maybe what we should do is redesign the whitelist to do something more
  useful.
 
  e.g. A whitelist that says what URLs you can navigate to is useful and
 easy
  to implement. Let's just drop the trying to stop network requests
 aspect of
  it?
 
 
  On Tue, Jul 8, 2014 at 12:54 PM, Joe Bowser bows...@gmail.com
  javascript:; wrote:
 
   I'm in agreement with Andrew on this one.  If we can get CSP working,
   that's a far better solution than our Whitelist, which was done
   because it was needed at the time for the enterprise use case that IBM
   had.  I don't think we're ever going to stop are users from doing dumb
   things like including thirdpartyadnetworkthatdoesnoteusehttps.js in
   their apps any time soon, but they'll have to jump through more hoops
   to do dumb things, and making dumb things harder is a good thing.
  
   On Tue, Jul 8, 2014 at 9:47 AM, Brian LeRoux b...@brian.io
 javascript:;
  wrote:
Heh. Why do we always seem to be at the opposite end of
 considerations?
(Not a bad thing anyhow. ;)
   
So making whitelist a plugin would most certainly isolate the code
  which
would help us better understand:
   
1.) where the surface for bugs are (we seem to miss/find new
 security
   holes
each quarter…)
2.) if people actually use it
   
I'm more interested in #2. I suspect the only people whom do use it
 are
security researchers disproving the whitelist veracity. I feel this
 API
   was
a mistake, is misleading, and ultimately leads to poor web security
practices wrt 3rd part scripts. I'd like the evidence to remove it
completely and making it a plugin would do that. (And still allow
 for
  its
existence to those whom want to contribute to a marketing based
 api.)
   
   
   
On Tue, Jul 8, 2014 at 6:52 AM, Andrew Grieve agri...@chromium.org
  javascript:;
   wrote:
   
I don't think moving the whitelist to a plugin would aid in its
understanding. Right now the whitelist is used for two things:
   
1. Whether to allow network requests through (although this is
 broken
   for
audio/video on iOS, and broken for them + websockets on Android
2. Whether to allow top frame navigations (e.g. clicking a link to
   http://
*
opens in system browser vs. webview)
   
#1 doesn't work very well due to technical limitations.
#2 is actually the more import one security-wise I think, and I
 don't
   think
should be relegated to a plugin.
   
I'm hoping medium-term that CSP can replace the use-case of #1.
   
   
On Mon, Jul 7, 2014 at 10:21 PM, Ian Clelland 
 iclell...@chromium.org
  javascript:;
wrote:
   
 What would be the security implication of removing it from core?
 No
access
 at all by default? Or unlimited access by default?

 I suspect that if the default policy with no plugin installed is
 the
 latter, then we will be given the impression that it's not
 important
   at
all
 :)

 I had considered just turning the whitelist settings into a
 plugin
  --
 either leaving the default rules as they are, and writing a
 cordova-security plugin that locks it down, or tighten
 everything
  by
 default, and tell people to install cordova-plugin-insecurity
 if
   they
 want to open it up :)

 I like the idea of making the entire whitelist architecture into
 a
plugin,
 though. If nothing else, it should be easier to reason about it,
 and
easier
 to fix or replace it in the future if we need to.


 On Mon, Jul 7, 2014 at 3:55 PM, Shazron shaz...@gmail.com
  javascript:; wrote:

  Actually it's already possible in any iOS version, we just
 have to
  make sure the plugin loads at startup. This is for UIWebView
 only,
  WKWebView has this issue:
  https://issues.apache.org/jira/browse

Re: whitelist as a plugin

[Ian Clelland]

CB-7747, for those following along at home.

On Thu, Oct 9, 2014 at 10:38 AM, Ian Clelland iclell...@chromium.org
wrote:

 I'm running into more and more problems caused by the whitelist (today,
 it's because of the dual use of the internal whitelist for should be able
 to navigate to URL and should be able to XHR from URL)

 I'm going to start to pull it out, on a topic branch based off of Android
 4.0.x right now. I'll create a JIRA issue to track the work.

 Is 4.0.x the best place for this to land, or is there any support for
 putting it on master as well, for an eventual 3.7 release?


 On Wed, Jul 9, 2014 at 1:22 PM, Shazron shaz...@gmail.com wrote:

 +1 to remove it  for all the above reasons (and WKWebView in iOS 8)
 Those interested in this security blanket for checkmark ✓ purposes can
 install the plugin, and perhaps maintain it as well.

 On Wed, Jul 9, 2014 at 10:17 AM, Brian LeRoux b...@brian.io wrote:
  Or remove it altogether and let the evolution of that code be
 maintained by
  those interested in the narrative it provides? :)
 
  On Wednesday, July 9, 2014, Andrew Grieve agri...@chromium.org wrote:
 
  Sounds like we both agree that it doesn't work and adds a false sense
 of
  security (to those that do opt into it) :P.
 
  Maybe what we should do is redesign the whitelist to do something more
  useful.
 
  e.g. A whitelist that says what URLs you can navigate to is useful and
 easy
  to implement. Let's just drop the trying to stop network requests
 aspect of
  it?
 
 
  On Tue, Jul 8, 2014 at 12:54 PM, Joe Bowser bows...@gmail.com
  javascript:; wrote:
 
   I'm in agreement with Andrew on this one.  If we can get CSP working,
   that's a far better solution than our Whitelist, which was done
   because it was needed at the time for the enterprise use case that
 IBM
   had.  I don't think we're ever going to stop are users from doing
 dumb
   things like including thirdpartyadnetworkthatdoesnoteusehttps.js in
   their apps any time soon, but they'll have to jump through more hoops
   to do dumb things, and making dumb things harder is a good thing.
  
   On Tue, Jul 8, 2014 at 9:47 AM, Brian LeRoux b...@brian.io
 javascript:;
  wrote:
Heh. Why do we always seem to be at the opposite end of
 considerations?
(Not a bad thing anyhow. ;)
   
So making whitelist a plugin would most certainly isolate the code
  which
would help us better understand:
   
1.) where the surface for bugs are (we seem to miss/find new
 security
   holes
each quarter…)
2.) if people actually use it
   
I'm more interested in #2. I suspect the only people whom do use
 it are
security researchers disproving the whitelist veracity. I feel
 this API
   was
a mistake, is misleading, and ultimately leads to poor web security
practices wrt 3rd part scripts. I'd like the evidence to remove it
completely and making it a plugin would do that. (And still allow
 for
  its
existence to those whom want to contribute to a marketing based
 api.)
   
   
   
On Tue, Jul 8, 2014 at 6:52 AM, Andrew Grieve 
 agri...@chromium.org
  javascript:;
   wrote:
   
I don't think moving the whitelist to a plugin would aid in its
understanding. Right now the whitelist is used for two things:
   
1. Whether to allow network requests through (although this is
 broken
   for
audio/video on iOS, and broken for them + websockets on
 Android
2. Whether to allow top frame navigations (e.g. clicking a link to
   http://
*
opens in system browser vs. webview)
   
#1 doesn't work very well due to technical limitations.
#2 is actually the more import one security-wise I think, and I
 don't
   think
should be relegated to a plugin.
   
I'm hoping medium-term that CSP can replace the use-case of #1.
   
   
On Mon, Jul 7, 2014 at 10:21 PM, Ian Clelland 
 iclell...@chromium.org
  javascript:;
wrote:
   
 What would be the security implication of removing it from
 core? No
access
 at all by default? Or unlimited access by default?

 I suspect that if the default policy with no plugin installed
 is the
 latter, then we will be given the impression that it's not
 important
   at
all
 :)

 I had considered just turning the whitelist settings into a
 plugin
  --
 either leaving the default rules as they are, and writing a
 cordova-security plugin that locks it down, or tighten
 everything
  by
 default, and tell people to install cordova-plugin-insecurity
 if
   they
 want to open it up :)

 I like the idea of making the entire whitelist architecture
 into a
plugin,
 though. If nothing else, it should be easier to reason about
 it, and
easier
 to fix or replace it in the future if we need to.


 On Mon, Jul 7, 2014 at 3:55 PM, Shazron shaz...@gmail.com
  javascript:; wrote:

  Actually it's already possible in any iOS version, we just
 have to
  make sure

Re: whitelist as a plugin

[Joe Bowser]

This should land in 4.0.x
On Oct 9, 2014 7:38 AM, Ian Clelland iclell...@chromium.org wrote:

 I'm running into more and more problems caused by the whitelist (today,
 it's because of the dual use of the internal whitelist for should be able
 to navigate to URL and should be able to XHR from URL)

 I'm going to start to pull it out, on a topic branch based off of Android
 4.0.x right now. I'll create a JIRA issue to track the work.

 Is 4.0.x the best place for this to land, or is there any support for
 putting it on master as well, for an eventual 3.7 release?


 On Wed, Jul 9, 2014 at 1:22 PM, Shazron shaz...@gmail.com wrote:

  +1 to remove it  for all the above reasons (and WKWebView in iOS 8)
  Those interested in this security blanket for checkmark ✓ purposes can
  install the plugin, and perhaps maintain it as well.
 
  On Wed, Jul 9, 2014 at 10:17 AM, Brian LeRoux b...@brian.io wrote:
   Or remove it altogether and let the evolution of that code be
 maintained
  by
   those interested in the narrative it provides? :)
  
   On Wednesday, July 9, 2014, Andrew Grieve agri...@chromium.org
 wrote:
  
   Sounds like we both agree that it doesn't work and adds a false sense
 of
   security (to those that do opt into it) :P.
  
   Maybe what we should do is redesign the whitelist to do something more
   useful.
  
   e.g. A whitelist that says what URLs you can navigate to is useful and
  easy
   to implement. Let's just drop the trying to stop network requests
  aspect of
   it?
  
  
   On Tue, Jul 8, 2014 at 12:54 PM, Joe Bowser bows...@gmail.com
   javascript:; wrote:
  
I'm in agreement with Andrew on this one.  If we can get CSP
 working,
that's a far better solution than our Whitelist, which was done
because it was needed at the time for the enterprise use case that
 IBM
had.  I don't think we're ever going to stop are users from doing
 dumb
things like including thirdpartyadnetworkthatdoesnoteusehttps.js in
their apps any time soon, but they'll have to jump through more
 hoops
to do dumb things, and making dumb things harder is a good thing.
   
On Tue, Jul 8, 2014 at 9:47 AM, Brian LeRoux b...@brian.io
  javascript:;
   wrote:
 Heh. Why do we always seem to be at the opposite end of
  considerations?
 (Not a bad thing anyhow. ;)

 So making whitelist a plugin would most certainly isolate the code
   which
 would help us better understand:

 1.) where the surface for bugs are (we seem to miss/find new
  security
holes
 each quarter…)
 2.) if people actually use it

 I'm more interested in #2. I suspect the only people whom do use
 it
  are
 security researchers disproving the whitelist veracity. I feel
 this
  API
was
 a mistake, is misleading, and ultimately leads to poor web
 security
 practices wrt 3rd part scripts. I'd like the evidence to remove it
 completely and making it a plugin would do that. (And still allow
  for
   its
 existence to those whom want to contribute to a marketing based
  api.)



 On Tue, Jul 8, 2014 at 6:52 AM, Andrew Grieve 
 agri...@chromium.org
   javascript:;
wrote:

 I don't think moving the whitelist to a plugin would aid in its
 understanding. Right now the whitelist is used for two things:

 1. Whether to allow network requests through (although this is
  broken
for
 audio/video on iOS, and broken for them + websockets on
 Android
 2. Whether to allow top frame navigations (e.g. clicking a link
 to
http://
 *
 opens in system browser vs. webview)

 #1 doesn't work very well due to technical limitations.
 #2 is actually the more import one security-wise I think, and I
  don't
think
 should be relegated to a plugin.

 I'm hoping medium-term that CSP can replace the use-case of #1.


 On Mon, Jul 7, 2014 at 10:21 PM, Ian Clelland 
  iclell...@chromium.org
   javascript:;
 wrote:

  What would be the security implication of removing it from
 core?
  No
 access
  at all by default? Or unlimited access by default?
 
  I suspect that if the default policy with no plugin installed
 is
  the
  latter, then we will be given the impression that it's not
  important
at
 all
  :)
 
  I had considered just turning the whitelist settings into a
  plugin
   --
  either leaving the default rules as they are, and writing a
  cordova-security plugin that locks it down, or tighten
  everything
   by
  default, and tell people to install cordova-plugin-insecurity
  if
they
  want to open it up :)
 
  I like the idea of making the entire whitelist architecture
 into
  a
 plugin,
  though. If nothing else, it should be easier to reason about
 it,
  and
 easier
  to fix or replace it in the future if we need to.
 
 
  On Mon, Jul 7, 2014 at 3:55 PM, Shazron shaz...@gmail.com

Re: whitelist as a plugin

[Andrew Grieve]

It's technically a breaking change, so agree 4.0.x makes sense.

On Thu, Oct 9, 2014 at 12:09 PM, Joe Bowser bows...@gmail.com wrote:

 This should land in 4.0.x
 On Oct 9, 2014 7:38 AM, Ian Clelland iclell...@chromium.org wrote:

  I'm running into more and more problems caused by the whitelist (today,
  it's because of the dual use of the internal whitelist for should be
 able
  to navigate to URL and should be able to XHR from URL)
 
  I'm going to start to pull it out, on a topic branch based off of Android
  4.0.x right now. I'll create a JIRA issue to track the work.
 
  Is 4.0.x the best place for this to land, or is there any support for
  putting it on master as well, for an eventual 3.7 release?
 
 
  On Wed, Jul 9, 2014 at 1:22 PM, Shazron shaz...@gmail.com wrote:
 
   +1 to remove it  for all the above reasons (and WKWebView in iOS 8)
   Those interested in this security blanket for checkmark ✓ purposes can
   install the plugin, and perhaps maintain it as well.
  
   On Wed, Jul 9, 2014 at 10:17 AM, Brian LeRoux b...@brian.io wrote:
Or remove it altogether and let the evolution of that code be
  maintained
   by
those interested in the narrative it provides? :)
   
On Wednesday, July 9, 2014, Andrew Grieve agri...@chromium.org
  wrote:
   
Sounds like we both agree that it doesn't work and adds a false
 sense
  of
security (to those that do opt into it) :P.
   
Maybe what we should do is redesign the whitelist to do something
 more
useful.
   
e.g. A whitelist that says what URLs you can navigate to is useful
 and
   easy
to implement. Let's just drop the trying to stop network requests
   aspect of
it?
   
   
On Tue, Jul 8, 2014 at 12:54 PM, Joe Bowser bows...@gmail.com
javascript:; wrote:
   
 I'm in agreement with Andrew on this one.  If we can get CSP
  working,
 that's a far better solution than our Whitelist, which was done
 because it was needed at the time for the enterprise use case that
  IBM
 had.  I don't think we're ever going to stop are users from doing
  dumb
 things like including thirdpartyadnetworkthatdoesnoteusehttps.js
 in
 their apps any time soon, but they'll have to jump through more
  hoops
 to do dumb things, and making dumb things harder is a good thing.

 On Tue, Jul 8, 2014 at 9:47 AM, Brian LeRoux b...@brian.io
   javascript:;
wrote:
  Heh. Why do we always seem to be at the opposite end of
   considerations?
  (Not a bad thing anyhow. ;)
 
  So making whitelist a plugin would most certainly isolate the
 code
which
  would help us better understand:
 
  1.) where the surface for bugs are (we seem to miss/find new
   security
 holes
  each quarter…)
  2.) if people actually use it
 
  I'm more interested in #2. I suspect the only people whom do use
  it
   are
  security researchers disproving the whitelist veracity. I feel
  this
   API
 was
  a mistake, is misleading, and ultimately leads to poor web
  security
  practices wrt 3rd part scripts. I'd like the evidence to remove
 it
  completely and making it a plugin would do that. (And still
 allow
   for
its
  existence to those whom want to contribute to a marketing
 based
   api.)
 
 
 
  On Tue, Jul 8, 2014 at 6:52 AM, Andrew Grieve 
  agri...@chromium.org
javascript:;
 wrote:
 
  I don't think moving the whitelist to a plugin would aid in its
  understanding. Right now the whitelist is used for two things:
 
  1. Whether to allow network requests through (although this is
   broken
 for
  audio/video on iOS, and broken for them + websockets on
  Android
  2. Whether to allow top frame navigations (e.g. clicking a link
  to
 http://
  *
  opens in system browser vs. webview)
 
  #1 doesn't work very well due to technical limitations.
  #2 is actually the more import one security-wise I think, and I
   don't
 think
  should be relegated to a plugin.
 
  I'm hoping medium-term that CSP can replace the use-case of #1.
 
 
  On Mon, Jul 7, 2014 at 10:21 PM, Ian Clelland 
   iclell...@chromium.org
javascript:;
  wrote:
 
   What would be the security implication of removing it from
  core?
   No
  access
   at all by default? Or unlimited access by default?
  
   I suspect that if the default policy with no plugin installed
  is
   the
   latter, then we will be given the impression that it's not
   important
 at
  all
   :)
  
   I had considered just turning the whitelist settings into a
   plugin
--
   either leaving the default rules as they are, and writing a
   cordova-security plugin that locks it down, or tighten
   everything
by
   default, and tell people to install
 cordova-plugin-insecurity
   if
 they
   want to open it up :)
  
   I like

Re: whitelist as a plugin

[Andrew Grieve]

Sounds like we both agree that it doesn't work and adds a false sense of
security (to those that do opt into it) :P.

Maybe what we should do is redesign the whitelist to do something more
useful.

e.g. A whitelist that says what URLs you can navigate to is useful and easy
to implement. Let's just drop the trying to stop network requests aspect of
it?


On Tue, Jul 8, 2014 at 12:54 PM, Joe Bowser bows...@gmail.com wrote:

 I'm in agreement with Andrew on this one.  If we can get CSP working,
 that's a far better solution than our Whitelist, which was done
 because it was needed at the time for the enterprise use case that IBM
 had.  I don't think we're ever going to stop are users from doing dumb
 things like including thirdpartyadnetworkthatdoesnoteusehttps.js in
 their apps any time soon, but they'll have to jump through more hoops
 to do dumb things, and making dumb things harder is a good thing.

 On Tue, Jul 8, 2014 at 9:47 AM, Brian LeRoux b...@brian.io wrote:
  Heh. Why do we always seem to be at the opposite end of considerations?
  (Not a bad thing anyhow. ;)
 
  So making whitelist a plugin would most certainly isolate the code which
  would help us better understand:
 
  1.) where the surface for bugs are (we seem to miss/find new security
 holes
  each quarter…)
  2.) if people actually use it
 
  I'm more interested in #2. I suspect the only people whom do use it are
  security researchers disproving the whitelist veracity. I feel this API
 was
  a mistake, is misleading, and ultimately leads to poor web security
  practices wrt 3rd part scripts. I'd like the evidence to remove it
  completely and making it a plugin would do that. (And still allow for its
  existence to those whom want to contribute to a marketing based api.)
 
 
 
  On Tue, Jul 8, 2014 at 6:52 AM, Andrew Grieve agri...@chromium.org
 wrote:
 
  I don't think moving the whitelist to a plugin would aid in its
  understanding. Right now the whitelist is used for two things:
 
  1. Whether to allow network requests through (although this is broken
 for
  audio/video on iOS, and broken for them + websockets on Android
  2. Whether to allow top frame navigations (e.g. clicking a link to
 http://
  *
  opens in system browser vs. webview)
 
  #1 doesn't work very well due to technical limitations.
  #2 is actually the more import one security-wise I think, and I don't
 think
  should be relegated to a plugin.
 
  I'm hoping medium-term that CSP can replace the use-case of #1.
 
 
  On Mon, Jul 7, 2014 at 10:21 PM, Ian Clelland iclell...@chromium.org
  wrote:
 
   What would be the security implication of removing it from core? No
  access
   at all by default? Or unlimited access by default?
  
   I suspect that if the default policy with no plugin installed is the
   latter, then we will be given the impression that it's not important
 at
  all
   :)
  
   I had considered just turning the whitelist settings into a plugin --
   either leaving the default rules as they are, and writing a
   cordova-security plugin that locks it down, or tighten everything by
   default, and tell people to install cordova-plugin-insecurity if
 they
   want to open it up :)
  
   I like the idea of making the entire whitelist architecture into a
  plugin,
   though. If nothing else, it should be easier to reason about it, and
  easier
   to fix or replace it in the future if we need to.
  
  
   On Mon, Jul 7, 2014 at 3:55 PM, Shazron shaz...@gmail.com wrote:
  
Actually it's already possible in any iOS version, we just have to
make sure the plugin loads at startup. This is for UIWebView only,
WKWebView has this issue:
https://issues.apache.org/jira/browse/CB-7049 - you can't intercept
any requests from it currently (not sure if anything changed in iOS
 8
beta 3)
   
On Mon, Jul 7, 2014 at 11:45 AM, Brian LeRoux b...@brian.io wrote:
 Was discussing this w/ Shaz and Joe and, in theory, this is
 possible
   from
 iOS8 onward and possibly w/ some refactoring in the 4.x series of
Android.

 Its also probably the single most problematic areas of
  misunderstanding
as
 it relates to security we have. Isolating it from core would give
 us
  a
 better picture of how important it truly is.

 Thoughts?
   
  
 

Re: whitelist as a plugin

[Brian LeRoux]

Or remove it altogether and let the evolution of that code be maintained by
those interested in the narrative it provides? :)

On Wednesday, July 9, 2014, Andrew Grieve agri...@chromium.org wrote:

 Sounds like we both agree that it doesn't work and adds a false sense of
 security (to those that do opt into it) :P.

 Maybe what we should do is redesign the whitelist to do something more
 useful.

 e.g. A whitelist that says what URLs you can navigate to is useful and easy
 to implement. Let's just drop the trying to stop network requests aspect of
 it?


 On Tue, Jul 8, 2014 at 12:54 PM, Joe Bowser bows...@gmail.com
 javascript:; wrote:

  I'm in agreement with Andrew on this one.  If we can get CSP working,
  that's a far better solution than our Whitelist, which was done
  because it was needed at the time for the enterprise use case that IBM
  had.  I don't think we're ever going to stop are users from doing dumb
  things like including thirdpartyadnetworkthatdoesnoteusehttps.js in
  their apps any time soon, but they'll have to jump through more hoops
  to do dumb things, and making dumb things harder is a good thing.
 
  On Tue, Jul 8, 2014 at 9:47 AM, Brian LeRoux b...@brian.io javascript:;
 wrote:
   Heh. Why do we always seem to be at the opposite end of considerations?
   (Not a bad thing anyhow. ;)
  
   So making whitelist a plugin would most certainly isolate the code
 which
   would help us better understand:
  
   1.) where the surface for bugs are (we seem to miss/find new security
  holes
   each quarter…)
   2.) if people actually use it
  
   I'm more interested in #2. I suspect the only people whom do use it are
   security researchers disproving the whitelist veracity. I feel this API
  was
   a mistake, is misleading, and ultimately leads to poor web security
   practices wrt 3rd part scripts. I'd like the evidence to remove it
   completely and making it a plugin would do that. (And still allow for
 its
   existence to those whom want to contribute to a marketing based api.)
  
  
  
   On Tue, Jul 8, 2014 at 6:52 AM, Andrew Grieve agri...@chromium.org
 javascript:;
  wrote:
  
   I don't think moving the whitelist to a plugin would aid in its
   understanding. Right now the whitelist is used for two things:
  
   1. Whether to allow network requests through (although this is broken
  for
   audio/video on iOS, and broken for them + websockets on Android
   2. Whether to allow top frame navigations (e.g. clicking a link to
  http://
   *
   opens in system browser vs. webview)
  
   #1 doesn't work very well due to technical limitations.
   #2 is actually the more import one security-wise I think, and I don't
  think
   should be relegated to a plugin.
  
   I'm hoping medium-term that CSP can replace the use-case of #1.
  
  
   On Mon, Jul 7, 2014 at 10:21 PM, Ian Clelland iclell...@chromium.org
 javascript:;
   wrote:
  
What would be the security implication of removing it from core? No
   access
at all by default? Or unlimited access by default?
   
I suspect that if the default policy with no plugin installed is the
latter, then we will be given the impression that it's not important
  at
   all
:)
   
I had considered just turning the whitelist settings into a plugin
 --
either leaving the default rules as they are, and writing a
cordova-security plugin that locks it down, or tighten everything
 by
default, and tell people to install cordova-plugin-insecurity if
  they
want to open it up :)
   
I like the idea of making the entire whitelist architecture into a
   plugin,
though. If nothing else, it should be easier to reason about it, and
   easier
to fix or replace it in the future if we need to.
   
   
On Mon, Jul 7, 2014 at 3:55 PM, Shazron shaz...@gmail.com
 javascript:; wrote:
   
 Actually it's already possible in any iOS version, we just have to
 make sure the plugin loads at startup. This is for UIWebView only,
 WKWebView has this issue:
 https://issues.apache.org/jira/browse/CB-7049 - you can't
 intercept
 any requests from it currently (not sure if anything changed in
 iOS
  8
 beta 3)

 On Mon, Jul 7, 2014 at 11:45 AM, Brian LeRoux b...@brian.io
 javascript:; wrote:
  Was discussing this w/ Shaz and Joe and, in theory, this is
  possible
from
  iOS8 onward and possibly w/ some refactoring in the 4.x series
 of
 Android.
 
  Its also probably the single most problematic areas of
   misunderstanding
 as
  it relates to security we have. Isolating it from core would
 give
  us
   a
  better picture of how important it truly is.
 
  Thoughts?

   
  
 

Re: whitelist as a plugin

[Shazron]

+1 to remove it  for all the above reasons (and WKWebView in iOS 8)
Those interested in this security blanket for checkmark ✓ purposes can
install the plugin, and perhaps maintain it as well.

On Wed, Jul 9, 2014 at 10:17 AM, Brian LeRoux b...@brian.io wrote:
 Or remove it altogether and let the evolution of that code be maintained by
 those interested in the narrative it provides? :)

 On Wednesday, July 9, 2014, Andrew Grieve agri...@chromium.org wrote:

 Sounds like we both agree that it doesn't work and adds a false sense of
 security (to those that do opt into it) :P.

 Maybe what we should do is redesign the whitelist to do something more
 useful.

 e.g. A whitelist that says what URLs you can navigate to is useful and easy
 to implement. Let's just drop the trying to stop network requests aspect of
 it?


 On Tue, Jul 8, 2014 at 12:54 PM, Joe Bowser bows...@gmail.com
 javascript:; wrote:

  I'm in agreement with Andrew on this one.  If we can get CSP working,
  that's a far better solution than our Whitelist, which was done
  because it was needed at the time for the enterprise use case that IBM
  had.  I don't think we're ever going to stop are users from doing dumb
  things like including thirdpartyadnetworkthatdoesnoteusehttps.js in
  their apps any time soon, but they'll have to jump through more hoops
  to do dumb things, and making dumb things harder is a good thing.
 
  On Tue, Jul 8, 2014 at 9:47 AM, Brian LeRoux b...@brian.io javascript:;
 wrote:
   Heh. Why do we always seem to be at the opposite end of considerations?
   (Not a bad thing anyhow. ;)
  
   So making whitelist a plugin would most certainly isolate the code
 which
   would help us better understand:
  
   1.) where the surface for bugs are (we seem to miss/find new security
  holes
   each quarter…)
   2.) if people actually use it
  
   I'm more interested in #2. I suspect the only people whom do use it are
   security researchers disproving the whitelist veracity. I feel this API
  was
   a mistake, is misleading, and ultimately leads to poor web security
   practices wrt 3rd part scripts. I'd like the evidence to remove it
   completely and making it a plugin would do that. (And still allow for
 its
   existence to those whom want to contribute to a marketing based api.)
  
  
  
   On Tue, Jul 8, 2014 at 6:52 AM, Andrew Grieve agri...@chromium.org
 javascript:;
  wrote:
  
   I don't think moving the whitelist to a plugin would aid in its
   understanding. Right now the whitelist is used for two things:
  
   1. Whether to allow network requests through (although this is broken
  for
   audio/video on iOS, and broken for them + websockets on Android
   2. Whether to allow top frame navigations (e.g. clicking a link to
  http://
   *
   opens in system browser vs. webview)
  
   #1 doesn't work very well due to technical limitations.
   #2 is actually the more import one security-wise I think, and I don't
  think
   should be relegated to a plugin.
  
   I'm hoping medium-term that CSP can replace the use-case of #1.
  
  
   On Mon, Jul 7, 2014 at 10:21 PM, Ian Clelland iclell...@chromium.org
 javascript:;
   wrote:
  
What would be the security implication of removing it from core? No
   access
at all by default? Or unlimited access by default?
   
I suspect that if the default policy with no plugin installed is the
latter, then we will be given the impression that it's not important
  at
   all
:)
   
I had considered just turning the whitelist settings into a plugin
 --
either leaving the default rules as they are, and writing a
cordova-security plugin that locks it down, or tighten everything
 by
default, and tell people to install cordova-plugin-insecurity if
  they
want to open it up :)
   
I like the idea of making the entire whitelist architecture into a
   plugin,
though. If nothing else, it should be easier to reason about it, and
   easier
to fix or replace it in the future if we need to.
   
   
On Mon, Jul 7, 2014 at 3:55 PM, Shazron shaz...@gmail.com
 javascript:; wrote:
   
 Actually it's already possible in any iOS version, we just have to
 make sure the plugin loads at startup. This is for UIWebView only,
 WKWebView has this issue:
 https://issues.apache.org/jira/browse/CB-7049 - you can't
 intercept
 any requests from it currently (not sure if anything changed in
 iOS
  8
 beta 3)

 On Mon, Jul 7, 2014 at 11:45 AM, Brian LeRoux b...@brian.io
 javascript:; wrote:
  Was discussing this w/ Shaz and Joe and, in theory, this is
  possible
from
  iOS8 onward and possibly w/ some refactoring in the 4.x series
 of
 Android.
 
  Its also probably the single most problematic areas of
   misunderstanding
 as
  it relates to security we have. Isolating it from core would
 give
  us
   a
  better picture of how important it truly is.
 
  Thoughts?

   
  
 

Re: whitelist as a plugin

[Andrew Grieve]

I don't think moving the whitelist to a plugin would aid in its
understanding. Right now the whitelist is used for two things:

1. Whether to allow network requests through (although this is broken for
audio/video on iOS, and broken for them + websockets on Android
2. Whether to allow top frame navigations (e.g. clicking a link to http://*
opens in system browser vs. webview)

#1 doesn't work very well due to technical limitations.
#2 is actually the more import one security-wise I think, and I don't think
should be relegated to a plugin.

I'm hoping medium-term that CSP can replace the use-case of #1.


On Mon, Jul 7, 2014 at 10:21 PM, Ian Clelland iclell...@chromium.org
wrote:

 What would be the security implication of removing it from core? No access
 at all by default? Or unlimited access by default?

 I suspect that if the default policy with no plugin installed is the
 latter, then we will be given the impression that it's not important at all
 :)

 I had considered just turning the whitelist settings into a plugin --
 either leaving the default rules as they are, and writing a
 cordova-security plugin that locks it down, or tighten everything by
 default, and tell people to install cordova-plugin-insecurity if they
 want to open it up :)

 I like the idea of making the entire whitelist architecture into a plugin,
 though. If nothing else, it should be easier to reason about it, and easier
 to fix or replace it in the future if we need to.


 On Mon, Jul 7, 2014 at 3:55 PM, Shazron shaz...@gmail.com wrote:

  Actually it's already possible in any iOS version, we just have to
  make sure the plugin loads at startup. This is for UIWebView only,
  WKWebView has this issue:
  https://issues.apache.org/jira/browse/CB-7049 - you can't intercept
  any requests from it currently (not sure if anything changed in iOS 8
  beta 3)
 
  On Mon, Jul 7, 2014 at 11:45 AM, Brian LeRoux b...@brian.io wrote:
   Was discussing this w/ Shaz and Joe and, in theory, this is possible
 from
   iOS8 onward and possibly w/ some refactoring in the 4.x series of
  Android.
  
   Its also probably the single most problematic areas of misunderstanding
  as
   it relates to security we have. Isolating it from core would give us a
   better picture of how important it truly is.
  
   Thoughts?
 

Re: whitelist as a plugin

[Brian LeRoux]

Heh. Why do we always seem to be at the opposite end of considerations?
(Not a bad thing anyhow. ;)

So making whitelist a plugin would most certainly isolate the code which
would help us better understand:

1.) where the surface for bugs are (we seem to miss/find new security holes
each quarter…)
2.) if people actually use it

I'm more interested in #2. I suspect the only people whom do use it are
security researchers disproving the whitelist veracity. I feel this API was
a mistake, is misleading, and ultimately leads to poor web security
practices wrt 3rd part scripts. I'd like the evidence to remove it
completely and making it a plugin would do that. (And still allow for its
existence to those whom want to contribute to a marketing based api.)



On Tue, Jul 8, 2014 at 6:52 AM, Andrew Grieve agri...@chromium.org wrote:

 I don't think moving the whitelist to a plugin would aid in its
 understanding. Right now the whitelist is used for two things:

 1. Whether to allow network requests through (although this is broken for
 audio/video on iOS, and broken for them + websockets on Android
 2. Whether to allow top frame navigations (e.g. clicking a link to http://
 *
 opens in system browser vs. webview)

 #1 doesn't work very well due to technical limitations.
 #2 is actually the more import one security-wise I think, and I don't think
 should be relegated to a plugin.

 I'm hoping medium-term that CSP can replace the use-case of #1.


 On Mon, Jul 7, 2014 at 10:21 PM, Ian Clelland iclell...@chromium.org
 wrote:

  What would be the security implication of removing it from core? No
 access
  at all by default? Or unlimited access by default?
 
  I suspect that if the default policy with no plugin installed is the
  latter, then we will be given the impression that it's not important at
 all
  :)
 
  I had considered just turning the whitelist settings into a plugin --
  either leaving the default rules as they are, and writing a
  cordova-security plugin that locks it down, or tighten everything by
  default, and tell people to install cordova-plugin-insecurity if they
  want to open it up :)
 
  I like the idea of making the entire whitelist architecture into a
 plugin,
  though. If nothing else, it should be easier to reason about it, and
 easier
  to fix or replace it in the future if we need to.
 
 
  On Mon, Jul 7, 2014 at 3:55 PM, Shazron shaz...@gmail.com wrote:
 
   Actually it's already possible in any iOS version, we just have to
   make sure the plugin loads at startup. This is for UIWebView only,
   WKWebView has this issue:
   https://issues.apache.org/jira/browse/CB-7049 - you can't intercept
   any requests from it currently (not sure if anything changed in iOS 8
   beta 3)
  
   On Mon, Jul 7, 2014 at 11:45 AM, Brian LeRoux b...@brian.io wrote:
Was discussing this w/ Shaz and Joe and, in theory, this is possible
  from
iOS8 onward and possibly w/ some refactoring in the 4.x series of
   Android.
   
Its also probably the single most problematic areas of
 misunderstanding
   as
it relates to security we have. Isolating it from core would give us
 a
better picture of how important it truly is.
   
Thoughts?
  
 

Re: whitelist as a plugin

[Joe Bowser]

I'm in agreement with Andrew on this one.  If we can get CSP working,
that's a far better solution than our Whitelist, which was done
because it was needed at the time for the enterprise use case that IBM
had.  I don't think we're ever going to stop are users from doing dumb
things like including thirdpartyadnetworkthatdoesnoteusehttps.js in
their apps any time soon, but they'll have to jump through more hoops
to do dumb things, and making dumb things harder is a good thing.

On Tue, Jul 8, 2014 at 9:47 AM, Brian LeRoux b...@brian.io wrote:
 Heh. Why do we always seem to be at the opposite end of considerations?
 (Not a bad thing anyhow. ;)

 So making whitelist a plugin would most certainly isolate the code which
 would help us better understand:

 1.) where the surface for bugs are (we seem to miss/find new security holes
 each quarter…)
 2.) if people actually use it

 I'm more interested in #2. I suspect the only people whom do use it are
 security researchers disproving the whitelist veracity. I feel this API was
 a mistake, is misleading, and ultimately leads to poor web security
 practices wrt 3rd part scripts. I'd like the evidence to remove it
 completely and making it a plugin would do that. (And still allow for its
 existence to those whom want to contribute to a marketing based api.)



 On Tue, Jul 8, 2014 at 6:52 AM, Andrew Grieve agri...@chromium.org wrote:

 I don't think moving the whitelist to a plugin would aid in its
 understanding. Right now the whitelist is used for two things:

 1. Whether to allow network requests through (although this is broken for
 audio/video on iOS, and broken for them + websockets on Android
 2. Whether to allow top frame navigations (e.g. clicking a link to http://
 *
 opens in system browser vs. webview)

 #1 doesn't work very well due to technical limitations.
 #2 is actually the more import one security-wise I think, and I don't think
 should be relegated to a plugin.

 I'm hoping medium-term that CSP can replace the use-case of #1.


 On Mon, Jul 7, 2014 at 10:21 PM, Ian Clelland iclell...@chromium.org
 wrote:

  What would be the security implication of removing it from core? No
 access
  at all by default? Or unlimited access by default?
 
  I suspect that if the default policy with no plugin installed is the
  latter, then we will be given the impression that it's not important at
 all
  :)
 
  I had considered just turning the whitelist settings into a plugin --
  either leaving the default rules as they are, and writing a
  cordova-security plugin that locks it down, or tighten everything by
  default, and tell people to install cordova-plugin-insecurity if they
  want to open it up :)
 
  I like the idea of making the entire whitelist architecture into a
 plugin,
  though. If nothing else, it should be easier to reason about it, and
 easier
  to fix or replace it in the future if we need to.
 
 
  On Mon, Jul 7, 2014 at 3:55 PM, Shazron shaz...@gmail.com wrote:
 
   Actually it's already possible in any iOS version, we just have to
   make sure the plugin loads at startup. This is for UIWebView only,
   WKWebView has this issue:
   https://issues.apache.org/jira/browse/CB-7049 - you can't intercept
   any requests from it currently (not sure if anything changed in iOS 8
   beta 3)
  
   On Mon, Jul 7, 2014 at 11:45 AM, Brian LeRoux b...@brian.io wrote:
Was discussing this w/ Shaz and Joe and, in theory, this is possible
  from
iOS8 onward and possibly w/ some refactoring in the 4.x series of
   Android.
   
Its also probably the single most problematic areas of
 misunderstanding
   as
it relates to security we have. Isolating it from core would give us
 a
better picture of how important it truly is.
   
Thoughts?
  
 

whitelist as a plugin

[Brian LeRoux]

Was discussing this w/ Shaz and Joe and, in theory, this is possible from
iOS8 onward and possibly w/ some refactoring in the 4.x series of Android.

Its also probably the single most problematic areas of misunderstanding as
it relates to security we have. Isolating it from core would give us a
better picture of how important it truly is.

Thoughts?

Re: whitelist as a plugin

[Shazron]

Actually it's already possible in any iOS version, we just have to
make sure the plugin loads at startup. This is for UIWebView only,
WKWebView has this issue:
https://issues.apache.org/jira/browse/CB-7049 - you can't intercept
any requests from it currently (not sure if anything changed in iOS 8
beta 3)

On Mon, Jul 7, 2014 at 11:45 AM, Brian LeRoux b...@brian.io wrote:
 Was discussing this w/ Shaz and Joe and, in theory, this is possible from
 iOS8 onward and possibly w/ some refactoring in the 4.x series of Android.

 Its also probably the single most problematic areas of misunderstanding as
 it relates to security we have. Isolating it from core would give us a
 better picture of how important it truly is.

 Thoughts?

Re: whitelist as a plugin

[Ian Clelland]

What would be the security implication of removing it from core? No access
at all by default? Or unlimited access by default?

I suspect that if the default policy with no plugin installed is the
latter, then we will be given the impression that it's not important at all
:)

I had considered just turning the whitelist settings into a plugin --
either leaving the default rules as they are, and writing a
cordova-security plugin that locks it down, or tighten everything by
default, and tell people to install cordova-plugin-insecurity if they
want to open it up :)

I like the idea of making the entire whitelist architecture into a plugin,
though. If nothing else, it should be easier to reason about it, and easier
to fix or replace it in the future if we need to.


On Mon, Jul 7, 2014 at 3:55 PM, Shazron shaz...@gmail.com wrote:

 Actually it's already possible in any iOS version, we just have to
 make sure the plugin loads at startup. This is for UIWebView only,
 WKWebView has this issue:
 https://issues.apache.org/jira/browse/CB-7049 - you can't intercept
 any requests from it currently (not sure if anything changed in iOS 8
 beta 3)

 On Mon, Jul 7, 2014 at 11:45 AM, Brian LeRoux b...@brian.io wrote:
  Was discussing this w/ Shaz and Joe and, in theory, this is possible from
  iOS8 onward and possibly w/ some refactoring in the 4.x series of
 Android.
 
  Its also probably the single most problematic areas of misunderstanding
 as
  it relates to security we have. Isolating it from core would give us a
  better picture of how important it truly is.
 
  Thoughts?