You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cordova.apache.org by Ian Clelland <ic...@chromium.org> on 2014/10/30 21:04:07 UTC
Whitelist breakout update
I've spent the majority of the week finishing up the whitelist-breakout
code, and I'd invite the rest of the community to take a look, before we
make anything official.
In order to retain some kind of backward compatibility with existing apps
(because it's a terrible situation for everyone when we break that), I've
endeavoured to provide hooks so that all of the existing functionality can
be moved to a plugin, and so that *something* useful still happens if you
don't have any plugins at all.
Policy decisions are made centrally (in Android, by CordovaUriHelper; in
iOS, by CDVViewController), first by asking all installed plugins whether
to allow or deny the request, and if no plugins reply, then by applying a
default policy (which is sane, but more restrictive than Cordova 3.6)
Without any plugins, Cordova will allow navigation within the app itself,
to file urls, and will allow resource loads (XHRs) from that space as well.
External applications are *not* launched. <access> tags in config.xml are
completely ignored.
I've also modified the config parsers so that they can be used by plugins.
(For example, the sample cordova-plugin-whitelist plugin reads config.xml
to extract <access> tags for building its own whitelist, but other plugins
could use any other method they wanted)
All of this is in git, on branches named "unplug-whitelist", on these repos:
cordova-android
cordova-ios
cordova-plugin-inappbrowser
cordova-plugin-file-transfer
cordova-mobile-spec
I wrote a sample plugin --
https://github.com/clelland/cordova-plugin-whitelist -- which implements
the Cordova 3.6 behaviour. With that plugin, <access> tags in config.xml
are parsed, just as they are right now. Navigation and XHR access to
external resources is controlled by <access origin=... > tags, and
launching of other applications is controlled by <access origin=...
launch-external="yes"> tags.
Comments welcome -- either here or on
https://issues.apache.org/jira/browse/CB-7747
Ian
Re: Whitelist breakout update
Posted by Michal Mocny <mm...@chromium.org>.
On Mon, Nov 3, 2014 at 11:13 PM, Andrew Grieve <ag...@chromium.org> wrote:
> Since the whitelist plugin blocks only a subset of sub-resource loads (just
> like the existing whitelists), I think we really want to call out that
> people should not just include the backwards-compatible plugin. Here's a
> stab at messaging:
>
>
> If you want nothing to change, use org.apache.cordova.legacy-whitelist. If
> you care about security, then please understand that there are three types
> of whitelists to consider:
>
> 1. Network traffic - The whitelist has never been able to fully block all
> network requests in this manner (on iOS and Android). Instead, we recommend
> using <meta http-equiv="Content-Security-Policy" content="[POLICY GOES
> HERE]"> in your <head>, which is supported on Android 4.4 and iOS 7.
>
(If this is going to land in Android 4.0, we can message Android 4.0+ w/
crosswalk)
>
> 2. Navigation - By default the webview is allowed to navigate to any page
> within the same directory tree as the start page. If you'd like to navigate
> to a different directory, or to a http(s) address, then you should use
> org.apache.cordova.navigation-whitelist.
>
> 3. Intents - By default all URLs that cause an external action (e.g. tel:,
> sms:, etc) are disabled. If you need to use any of these, then you should
> use org.apache.cordova.intent-whitelist.
>
>
> On Mon, Nov 3, 2014 at 10:08 PM, Ian Clelland <ic...@chromium.org>
> wrote:
>
> > On Mon Nov 03 2014 at 4:05:51 PM Marcel Kinard <cm...@gmail.com>
> wrote:
> >
> > > This sounds very interesting and relatively graceful.
> > >
> > > For a user upgrading to this new world, what would the migration steps
> > > look like? Or in other words, what would a rough sketch of the upgrade
> > > guide for this look like? The reason I ask is to see how much pain
> we'll
> > > ask our users to go through.
> > >
> >
> > That's certainly a concern -- so for one thing, this would have to be on
> a
> > 4.x version of any platforms that it applies to. It is a break in
> backwards
> > compatibility, so users should at least be prepared for it.
> >
> > That said, I've tried to make it as simple as possible for them: If what
> > you want is no change at all in behaviour, then your upgrade should be
> > just:
> >
> > cordova plugin add org.apache.cordova.whitelist
> >
> > There would be no configuration changes to make: the plugin reads the old
> > access tags, just as before, and applies the same policies based on them
> > that it did in 3.6.
> >
> > And if your application doesn't rely on access to external sites, then
> it's
> > even simpler -- don't install the plugin, and you're likely more secure
> > than you were before.
> >
> >
> > > On Oct 30, 2014, at 4:04 PM, Ian Clelland <ic...@chromium.org>
> > wrote:
> > >
> > > > I've spent the majority of the week finishing up the
> whitelist-breakout
> > > > code, and I'd invite the rest of the community to take a look, before
> > we
> > > > make anything official.
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> > > For additional commands, e-mail: dev-help@cordova.apache.org
> > >
> > >
> >
>
Re: Whitelist breakout update
Posted by Ian Clelland <ic...@chromium.org>.
Sorry for dropping this thread for a week; let me see if I can address that
--
By default, for brand new apps created with Cordova 4.x with no plugins,
those will be blocked (this includes protocols like tel: and mailto:) .
This was considered to be a security issue earlier this year, and we put
measures unto Cordova 3.5.1 to ensure that Cordova apps couldn't launch
other intents without the app author's cooperation. (This makes Cordova
apps a bit more like native apps, and a bit less like websites, when
displaying external content, which is probably a good thing re: security)
If you add the cordova-legacy-whitelist plugin, then you get back exactly
the same level of control that you had with Cordova, say, 3.7.0, and the
goal is that you don't have to do anything else to get backwards
compatibility. If you find any regressions, bring them up on the list or in
JIRA, and we should be able to resolve them. (Hopefully before 4.0.0 is
released).
Any other behaviour that you need should be possible through a plugin;
whether that means a custom one for your app, or something from the
community that hundreds of other devs use, I don't know :)
On Tue Nov 04 2014 at 11:11:57 AM Frederico Galvão <
frederico.galvao@pontoget.com.br> wrote:
> I understand and am already familiar with the configuration for external
> URLs that do not interfere/launch third party apps or intents.
> I just want to understand better what's gonna happen with the custom
> protocols I call, like tel: or mailto:, or even URLs that have custom
> handlers on each platform.
>
> 2014-11-04 14:03 GMT-02:00 Ian Clelland <ic...@chromium.org>:
>
> > On Tue Nov 04 2014 at 10:46:52 AM Frederico Galvão <
> > frederico.galvao@pontoget.com.br> wrote:
> >
> > > So we actually have 4 new plugins:
> > > org.apache.cordova.whitelist
> > > org.apache.cordova.legacy-whitelist
> > > org.apache.cordova.navigation-whitelist
> > > org.apache.cordova.intent-whitelist
> > >
> >
> > I think that org.apache.cordova.legacy-whitelist is a better name for
> what
> > I have published at https://github.com/clelland/cordova-plugin-whitelist
> > as
> > org.apache.cordova.whitelist.
> >
> > So where I had a single plugin implementing the old behaviour, Andrew has
> > suggested releasing three plugins: legacy-whitelist, which is what I
> > implemented; and two new ones: navigation-whitelist, which implements
> > navigation control, and intent-whitelist, which would control launching
> > external apps.
> >
> > (And there's also the very sound advice of "just skip the whitelist
> plugins
> > and use CORS if you can get away with it")
> >
> > >
> > > Right?
> > >
> > > If that's the case, then this is not entirely true:
> > >
> > > If what
> > > > you want is no change at all in behaviour, then your upgrade should
> be
> > > > just:
> > > >
> > > > cordova plugin add org.apache.cordova.whitelist
> > > >
> > > > There would be no configuration changes to make: the plugin reads the
> > old
> > > > access tags, just as before, and applies the same policies based on
> > them
> > > > that it did in 3.6.
> > > >
> > >
> >
> >
> > The messaging is still simple, if all you want is backwards
> compatibility,
> > but if you want something better, then the instructions are more
> > complicated, and depend on your actual needs.
> >
> >
> > >
> > > 2014-11-04 2:13 GMT-02:00 Andrew Grieve <ag...@chromium.org>:
> > >
> > > > Since the whitelist plugin blocks only a subset of sub-resource loads
> > > (just
> > > > like the existing whitelists), I think we really want to call out
> that
> > > > people should not just include the backwards-compatible plugin.
> Here's
> > a
> > > > stab at messaging:
> > > >
> > > >
> > > > If you want nothing to change, use org.apache.cordova.legacy-
> whitelist.
> > > If
> > > > you care about security, then please understand that there are three
> > > types
> > > > of whitelists to consider:
> > > >
> > > > 1. Network traffic - The whitelist has never been able to fully block
> > all
> > > > network requests in this manner (on iOS and Android). Instead, we
> > > recommend
> > > > using <meta http-equiv="Content-Security-Policy" content="[POLICY
> GOES
> > > > HERE]"> in your <head>, which is supported on Android 4.4 and iOS 7.
> > > >
> > > > 2. Navigation - By default the webview is allowed to navigate to any
> > page
> > > > within the same directory tree as the start page. If you'd like to
> > > navigate
> > > > to a different directory, or to a http(s) address, then you should
> use
> > > > org.apache.cordova.navigation-whitelist.
> > > >
> > > > 3. Intents - By default all URLs that cause an external action (e.g.
> > > tel:,
> > > > sms:, etc) are disabled. If you need to use any of these, then you
> > should
> > > > use org.apache.cordova.intent-whitelist.
> > > >
> > > >
> > > > On Mon, Nov 3, 2014 at 10:08 PM, Ian Clelland <
> iclelland@chromium.org>
> > > > wrote:
> > > >
> > > > > On Mon Nov 03 2014 at 4:05:51 PM Marcel Kinard <cmarcelk@gmail.com
> >
> > > > wrote:
> > > > >
> > > > > > This sounds very interesting and relatively graceful.
> > > > > >
> > > > > > For a user upgrading to this new world, what would the migration
> > > steps
> > > > > > look like? Or in other words, what would a rough sketch of the
> > > upgrade
> > > > > > guide for this look like? The reason I ask is to see how much
> pain
> > > > we'll
> > > > > > ask our users to go through.
> > > > > >
> > > > >
> > > > > That's certainly a concern -- so for one thing, this would have to
> be
> > > on
> > > > a
> > > > > 4.x version of any platforms that it applies to. It is a break in
> > > > backwards
> > > > > compatibility, so users should at least be prepared for it.
> > > > >
> > > > > That said, I've tried to make it as simple as possible for them: If
> > > what
> > > > > you want is no change at all in behaviour, then your upgrade should
> > be
> > > > > just:
> > > > >
> > > > > cordova plugin add org.apache.cordova.whitelist
> > > > >
> > > > > There would be no configuration changes to make: the plugin reads
> the
> > > old
> > > > > access tags, just as before, and applies the same policies based on
> > > them
> > > > > that it did in 3.6.
> > > > >
> > > > > And if your application doesn't rely on access to external sites,
> > then
> > > > it's
> > > > > even simpler -- don't install the plugin, and you're likely more
> > secure
> > > > > than you were before.
> > > > >
> > > > >
> > > > > > On Oct 30, 2014, at 4:04 PM, Ian Clelland <
> iclelland@chromium.org>
> > > > > wrote:
> > > > > >
> > > > > > > I've spent the majority of the week finishing up the
> > > > whitelist-breakout
> > > > > > > code, and I'd invite the rest of the community to take a look,
> > > before
> > > > > we
> > > > > > > make anything official.
> > > > > >
> > > > > > ------------------------------------------------------------
> > > ---------
> > > > > > To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> > > > > > For additional commands, e-mail: dev-help@cordova.apache.org
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> > >
> > >
> > > --
> > >
> > > *Frederico Galvão*
> > >
> > > Diretor de Tecnologia
> > >
> > > PontoGet Inovação Web
> > >
> > >
> > > ( +55(62) 8131-5720
> > >
> > > * www.pontoget.com.br <http://www.pontoget.com/>
> > >
> >
>
>
>
> --
>
> *Frederico Galvão*
>
> Diretor de Tecnologia
>
> PontoGet Inovação Web
>
>
> ( +55(62) 8131-5720
>
> * www.pontoget.com.br <http://www.pontoget.com/>
>
Re: Whitelist breakout update
Posted by Frederico Galvão <fr...@pontoget.com.br>.
I understand and am already familiar with the configuration for external
URLs that do not interfere/launch third party apps or intents.
I just want to understand better what's gonna happen with the custom
protocols I call, like tel: or mailto:, or even URLs that have custom
handlers on each platform.
2014-11-04 14:03 GMT-02:00 Ian Clelland <ic...@chromium.org>:
> On Tue Nov 04 2014 at 10:46:52 AM Frederico Galvão <
> frederico.galvao@pontoget.com.br> wrote:
>
> > So we actually have 4 new plugins:
> > org.apache.cordova.whitelist
> > org.apache.cordova.legacy-whitelist
> > org.apache.cordova.navigation-whitelist
> > org.apache.cordova.intent-whitelist
> >
>
> I think that org.apache.cordova.legacy-whitelist is a better name for what
> I have published at https://github.com/clelland/cordova-plugin-whitelist
> as
> org.apache.cordova.whitelist.
>
> So where I had a single plugin implementing the old behaviour, Andrew has
> suggested releasing three plugins: legacy-whitelist, which is what I
> implemented; and two new ones: navigation-whitelist, which implements
> navigation control, and intent-whitelist, which would control launching
> external apps.
>
> (And there's also the very sound advice of "just skip the whitelist plugins
> and use CORS if you can get away with it")
>
> >
> > Right?
> >
> > If that's the case, then this is not entirely true:
> >
> > If what
> > > you want is no change at all in behaviour, then your upgrade should be
> > > just:
> > >
> > > cordova plugin add org.apache.cordova.whitelist
> > >
> > > There would be no configuration changes to make: the plugin reads the
> old
> > > access tags, just as before, and applies the same policies based on
> them
> > > that it did in 3.6.
> > >
> >
>
>
> The messaging is still simple, if all you want is backwards compatibility,
> but if you want something better, then the instructions are more
> complicated, and depend on your actual needs.
>
>
> >
> > 2014-11-04 2:13 GMT-02:00 Andrew Grieve <ag...@chromium.org>:
> >
> > > Since the whitelist plugin blocks only a subset of sub-resource loads
> > (just
> > > like the existing whitelists), I think we really want to call out that
> > > people should not just include the backwards-compatible plugin. Here's
> a
> > > stab at messaging:
> > >
> > >
> > > If you want nothing to change, use org.apache.cordova.legacy-whitelist.
> > If
> > > you care about security, then please understand that there are three
> > types
> > > of whitelists to consider:
> > >
> > > 1. Network traffic - The whitelist has never been able to fully block
> all
> > > network requests in this manner (on iOS and Android). Instead, we
> > recommend
> > > using <meta http-equiv="Content-Security-Policy" content="[POLICY GOES
> > > HERE]"> in your <head>, which is supported on Android 4.4 and iOS 7.
> > >
> > > 2. Navigation - By default the webview is allowed to navigate to any
> page
> > > within the same directory tree as the start page. If you'd like to
> > navigate
> > > to a different directory, or to a http(s) address, then you should use
> > > org.apache.cordova.navigation-whitelist.
> > >
> > > 3. Intents - By default all URLs that cause an external action (e.g.
> > tel:,
> > > sms:, etc) are disabled. If you need to use any of these, then you
> should
> > > use org.apache.cordova.intent-whitelist.
> > >
> > >
> > > On Mon, Nov 3, 2014 at 10:08 PM, Ian Clelland <ic...@chromium.org>
> > > wrote:
> > >
> > > > On Mon Nov 03 2014 at 4:05:51 PM Marcel Kinard <cm...@gmail.com>
> > > wrote:
> > > >
> > > > > This sounds very interesting and relatively graceful.
> > > > >
> > > > > For a user upgrading to this new world, what would the migration
> > steps
> > > > > look like? Or in other words, what would a rough sketch of the
> > upgrade
> > > > > guide for this look like? The reason I ask is to see how much pain
> > > we'll
> > > > > ask our users to go through.
> > > > >
> > > >
> > > > That's certainly a concern -- so for one thing, this would have to be
> > on
> > > a
> > > > 4.x version of any platforms that it applies to. It is a break in
> > > backwards
> > > > compatibility, so users should at least be prepared for it.
> > > >
> > > > That said, I've tried to make it as simple as possible for them: If
> > what
> > > > you want is no change at all in behaviour, then your upgrade should
> be
> > > > just:
> > > >
> > > > cordova plugin add org.apache.cordova.whitelist
> > > >
> > > > There would be no configuration changes to make: the plugin reads the
> > old
> > > > access tags, just as before, and applies the same policies based on
> > them
> > > > that it did in 3.6.
> > > >
> > > > And if your application doesn't rely on access to external sites,
> then
> > > it's
> > > > even simpler -- don't install the plugin, and you're likely more
> secure
> > > > than you were before.
> > > >
> > > >
> > > > > On Oct 30, 2014, at 4:04 PM, Ian Clelland <ic...@chromium.org>
> > > > wrote:
> > > > >
> > > > > > I've spent the majority of the week finishing up the
> > > whitelist-breakout
> > > > > > code, and I'd invite the rest of the community to take a look,
> > before
> > > > we
> > > > > > make anything official.
> > > > >
> > > > > ------------------------------------------------------------
> > ---------
> > > > > To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> > > > > For additional commands, e-mail: dev-help@cordova.apache.org
> > > > >
> > > > >
> > > >
> > >
> >
> >
> >
> > --
> >
> > *Frederico Galvão*
> >
> > Diretor de Tecnologia
> >
> > PontoGet Inovação Web
> >
> >
> > ( +55(62) 8131-5720
> >
> > * www.pontoget.com.br <http://www.pontoget.com/>
> >
>
--
*Frederico Galvão*
Diretor de Tecnologia
PontoGet Inovação Web
( +55(62) 8131-5720
* www.pontoget.com.br <http://www.pontoget.com/>
Re: Whitelist breakout update
Posted by Ian Clelland <ic...@chromium.org>.
On Tue Nov 04 2014 at 10:46:52 AM Frederico Galvão <
frederico.galvao@pontoget.com.br> wrote:
> So we actually have 4 new plugins:
> org.apache.cordova.whitelist
> org.apache.cordova.legacy-whitelist
> org.apache.cordova.navigation-whitelist
> org.apache.cordova.intent-whitelist
>
I think that org.apache.cordova.legacy-whitelist is a better name for what
I have published at https://github.com/clelland/cordova-plugin-whitelist as
org.apache.cordova.whitelist.
So where I had a single plugin implementing the old behaviour, Andrew has
suggested releasing three plugins: legacy-whitelist, which is what I
implemented; and two new ones: navigation-whitelist, which implements
navigation control, and intent-whitelist, which would control launching
external apps.
(And there's also the very sound advice of "just skip the whitelist plugins
and use CORS if you can get away with it")
>
> Right?
>
> If that's the case, then this is not entirely true:
>
> If what
> > you want is no change at all in behaviour, then your upgrade should be
> > just:
> >
> > cordova plugin add org.apache.cordova.whitelist
> >
> > There would be no configuration changes to make: the plugin reads the old
> > access tags, just as before, and applies the same policies based on them
> > that it did in 3.6.
> >
>
The messaging is still simple, if all you want is backwards compatibility,
but if you want something better, then the instructions are more
complicated, and depend on your actual needs.
>
> 2014-11-04 2:13 GMT-02:00 Andrew Grieve <ag...@chromium.org>:
>
> > Since the whitelist plugin blocks only a subset of sub-resource loads
> (just
> > like the existing whitelists), I think we really want to call out that
> > people should not just include the backwards-compatible plugin. Here's a
> > stab at messaging:
> >
> >
> > If you want nothing to change, use org.apache.cordova.legacy-whitelist.
> If
> > you care about security, then please understand that there are three
> types
> > of whitelists to consider:
> >
> > 1. Network traffic - The whitelist has never been able to fully block all
> > network requests in this manner (on iOS and Android). Instead, we
> recommend
> > using <meta http-equiv="Content-Security-Policy" content="[POLICY GOES
> > HERE]"> in your <head>, which is supported on Android 4.4 and iOS 7.
> >
> > 2. Navigation - By default the webview is allowed to navigate to any page
> > within the same directory tree as the start page. If you'd like to
> navigate
> > to a different directory, or to a http(s) address, then you should use
> > org.apache.cordova.navigation-whitelist.
> >
> > 3. Intents - By default all URLs that cause an external action (e.g.
> tel:,
> > sms:, etc) are disabled. If you need to use any of these, then you should
> > use org.apache.cordova.intent-whitelist.
> >
> >
> > On Mon, Nov 3, 2014 at 10:08 PM, Ian Clelland <ic...@chromium.org>
> > wrote:
> >
> > > On Mon Nov 03 2014 at 4:05:51 PM Marcel Kinard <cm...@gmail.com>
> > wrote:
> > >
> > > > This sounds very interesting and relatively graceful.
> > > >
> > > > For a user upgrading to this new world, what would the migration
> steps
> > > > look like? Or in other words, what would a rough sketch of the
> upgrade
> > > > guide for this look like? The reason I ask is to see how much pain
> > we'll
> > > > ask our users to go through.
> > > >
> > >
> > > That's certainly a concern -- so for one thing, this would have to be
> on
> > a
> > > 4.x version of any platforms that it applies to. It is a break in
> > backwards
> > > compatibility, so users should at least be prepared for it.
> > >
> > > That said, I've tried to make it as simple as possible for them: If
> what
> > > you want is no change at all in behaviour, then your upgrade should be
> > > just:
> > >
> > > cordova plugin add org.apache.cordova.whitelist
> > >
> > > There would be no configuration changes to make: the plugin reads the
> old
> > > access tags, just as before, and applies the same policies based on
> them
> > > that it did in 3.6.
> > >
> > > And if your application doesn't rely on access to external sites, then
> > it's
> > > even simpler -- don't install the plugin, and you're likely more secure
> > > than you were before.
> > >
> > >
> > > > On Oct 30, 2014, at 4:04 PM, Ian Clelland <ic...@chromium.org>
> > > wrote:
> > > >
> > > > > I've spent the majority of the week finishing up the
> > whitelist-breakout
> > > > > code, and I'd invite the rest of the community to take a look,
> before
> > > we
> > > > > make anything official.
> > > >
> > > > ------------------------------------------------------------
> ---------
> > > > To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> > > > For additional commands, e-mail: dev-help@cordova.apache.org
> > > >
> > > >
> > >
> >
>
>
>
> --
>
> *Frederico Galvão*
>
> Diretor de Tecnologia
>
> PontoGet Inovação Web
>
>
> ( +55(62) 8131-5720
>
> * www.pontoget.com.br <http://www.pontoget.com/>
>
Re: Whitelist breakout update
Posted by Frederico Galvão <fr...@pontoget.com.br>.
So we actually have 4 new plugins:
org.apache.cordova.whitelist
org.apache.cordova.legacy-whitelist
org.apache.cordova.navigation-whitelist
org.apache.cordova.intent-whitelist
Right?
If that's the case, then this is not entirely true:
If what
> you want is no change at all in behaviour, then your upgrade should be
> just:
>
> cordova plugin add org.apache.cordova.whitelist
>
> There would be no configuration changes to make: the plugin reads the old
> access tags, just as before, and applies the same policies based on them
> that it did in 3.6.
>
2014-11-04 2:13 GMT-02:00 Andrew Grieve <ag...@chromium.org>:
> Since the whitelist plugin blocks only a subset of sub-resource loads (just
> like the existing whitelists), I think we really want to call out that
> people should not just include the backwards-compatible plugin. Here's a
> stab at messaging:
>
>
> If you want nothing to change, use org.apache.cordova.legacy-whitelist. If
> you care about security, then please understand that there are three types
> of whitelists to consider:
>
> 1. Network traffic - The whitelist has never been able to fully block all
> network requests in this manner (on iOS and Android). Instead, we recommend
> using <meta http-equiv="Content-Security-Policy" content="[POLICY GOES
> HERE]"> in your <head>, which is supported on Android 4.4 and iOS 7.
>
> 2. Navigation - By default the webview is allowed to navigate to any page
> within the same directory tree as the start page. If you'd like to navigate
> to a different directory, or to a http(s) address, then you should use
> org.apache.cordova.navigation-whitelist.
>
> 3. Intents - By default all URLs that cause an external action (e.g. tel:,
> sms:, etc) are disabled. If you need to use any of these, then you should
> use org.apache.cordova.intent-whitelist.
>
>
> On Mon, Nov 3, 2014 at 10:08 PM, Ian Clelland <ic...@chromium.org>
> wrote:
>
> > On Mon Nov 03 2014 at 4:05:51 PM Marcel Kinard <cm...@gmail.com>
> wrote:
> >
> > > This sounds very interesting and relatively graceful.
> > >
> > > For a user upgrading to this new world, what would the migration steps
> > > look like? Or in other words, what would a rough sketch of the upgrade
> > > guide for this look like? The reason I ask is to see how much pain
> we'll
> > > ask our users to go through.
> > >
> >
> > That's certainly a concern -- so for one thing, this would have to be on
> a
> > 4.x version of any platforms that it applies to. It is a break in
> backwards
> > compatibility, so users should at least be prepared for it.
> >
> > That said, I've tried to make it as simple as possible for them: If what
> > you want is no change at all in behaviour, then your upgrade should be
> > just:
> >
> > cordova plugin add org.apache.cordova.whitelist
> >
> > There would be no configuration changes to make: the plugin reads the old
> > access tags, just as before, and applies the same policies based on them
> > that it did in 3.6.
> >
> > And if your application doesn't rely on access to external sites, then
> it's
> > even simpler -- don't install the plugin, and you're likely more secure
> > than you were before.
> >
> >
> > > On Oct 30, 2014, at 4:04 PM, Ian Clelland <ic...@chromium.org>
> > wrote:
> > >
> > > > I've spent the majority of the week finishing up the
> whitelist-breakout
> > > > code, and I'd invite the rest of the community to take a look, before
> > we
> > > > make anything official.
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> > > For additional commands, e-mail: dev-help@cordova.apache.org
> > >
> > >
> >
>
--
*Frederico Galvão*
Diretor de Tecnologia
PontoGet Inovação Web
( +55(62) 8131-5720
* www.pontoget.com.br <http://www.pontoget.com/>
Re: Whitelist breakout update
Posted by Andrew Grieve <ag...@chromium.org>.
Since the whitelist plugin blocks only a subset of sub-resource loads (just
like the existing whitelists), I think we really want to call out that
people should not just include the backwards-compatible plugin. Here's a
stab at messaging:
If you want nothing to change, use org.apache.cordova.legacy-whitelist. If
you care about security, then please understand that there are three types
of whitelists to consider:
1. Network traffic - The whitelist has never been able to fully block all
network requests in this manner (on iOS and Android). Instead, we recommend
using <meta http-equiv="Content-Security-Policy" content="[POLICY GOES
HERE]"> in your <head>, which is supported on Android 4.4 and iOS 7.
2. Navigation - By default the webview is allowed to navigate to any page
within the same directory tree as the start page. If you'd like to navigate
to a different directory, or to a http(s) address, then you should use
org.apache.cordova.navigation-whitelist.
3. Intents - By default all URLs that cause an external action (e.g. tel:,
sms:, etc) are disabled. If you need to use any of these, then you should
use org.apache.cordova.intent-whitelist.
On Mon, Nov 3, 2014 at 10:08 PM, Ian Clelland <ic...@chromium.org>
wrote:
> On Mon Nov 03 2014 at 4:05:51 PM Marcel Kinard <cm...@gmail.com> wrote:
>
> > This sounds very interesting and relatively graceful.
> >
> > For a user upgrading to this new world, what would the migration steps
> > look like? Or in other words, what would a rough sketch of the upgrade
> > guide for this look like? The reason I ask is to see how much pain we'll
> > ask our users to go through.
> >
>
> That's certainly a concern -- so for one thing, this would have to be on a
> 4.x version of any platforms that it applies to. It is a break in backwards
> compatibility, so users should at least be prepared for it.
>
> That said, I've tried to make it as simple as possible for them: If what
> you want is no change at all in behaviour, then your upgrade should be
> just:
>
> cordova plugin add org.apache.cordova.whitelist
>
> There would be no configuration changes to make: the plugin reads the old
> access tags, just as before, and applies the same policies based on them
> that it did in 3.6.
>
> And if your application doesn't rely on access to external sites, then it's
> even simpler -- don't install the plugin, and you're likely more secure
> than you were before.
>
>
> > On Oct 30, 2014, at 4:04 PM, Ian Clelland <ic...@chromium.org>
> wrote:
> >
> > > I've spent the majority of the week finishing up the whitelist-breakout
> > > code, and I'd invite the rest of the community to take a look, before
> we
> > > make anything official.
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> > For additional commands, e-mail: dev-help@cordova.apache.org
> >
> >
>
Re: Whitelist breakout update
Posted by Ian Clelland <ic...@chromium.org>.
On Mon Nov 03 2014 at 4:05:51 PM Marcel Kinard <cm...@gmail.com> wrote:
> This sounds very interesting and relatively graceful.
>
> For a user upgrading to this new world, what would the migration steps
> look like? Or in other words, what would a rough sketch of the upgrade
> guide for this look like? The reason I ask is to see how much pain we'll
> ask our users to go through.
>
That's certainly a concern -- so for one thing, this would have to be on a
4.x version of any platforms that it applies to. It is a break in backwards
compatibility, so users should at least be prepared for it.
That said, I've tried to make it as simple as possible for them: If what
you want is no change at all in behaviour, then your upgrade should be just:
cordova plugin add org.apache.cordova.whitelist
There would be no configuration changes to make: the plugin reads the old
access tags, just as before, and applies the same policies based on them
that it did in 3.6.
And if your application doesn't rely on access to external sites, then it's
even simpler -- don't install the plugin, and you're likely more secure
than you were before.
> On Oct 30, 2014, at 4:04 PM, Ian Clelland <ic...@chromium.org> wrote:
>
> > I've spent the majority of the week finishing up the whitelist-breakout
> > code, and I'd invite the rest of the community to take a look, before we
> > make anything official.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> For additional commands, e-mail: dev-help@cordova.apache.org
>
>
Re: Whitelist breakout update
Posted by Michal Mocny <mm...@chromium.org>.
Sounds great Ian! Very elegant actually.
Suggestion: patch cordova-cli to warn if there is an <access> tag and
no cordova-plugin-whitelist?
-Michal
On Mon, Nov 3, 2014 at 4:04 PM, Marcel Kinard <cm...@gmail.com> wrote:
> This sounds very interesting and relatively graceful.
>
> For a user upgrading to this new world, what would the migration steps
> look like? Or in other words, what would a rough sketch of the upgrade
> guide for this look like? The reason I ask is to see how much pain we'll
> ask our users to go through.
>
> On Oct 30, 2014, at 4:04 PM, Ian Clelland <ic...@chromium.org> wrote:
>
> > I've spent the majority of the week finishing up the whitelist-breakout
> > code, and I'd invite the rest of the community to take a look, before we
> > make anything official.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> For additional commands, e-mail: dev-help@cordova.apache.org
>
>
Re: Whitelist breakout update
Posted by Marcel Kinard <cm...@gmail.com>.
This sounds very interesting and relatively graceful.
For a user upgrading to this new world, what would the migration steps look like? Or in other words, what would a rough sketch of the upgrade guide for this look like? The reason I ask is to see how much pain we'll ask our users to go through.
On Oct 30, 2014, at 4:04 PM, Ian Clelland <ic...@chromium.org> wrote:
> I've spent the majority of the week finishing up the whitelist-breakout
> code, and I'd invite the rest of the community to take a look, before we
> make anything official.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
For additional commands, e-mail: dev-help@cordova.apache.org
Re: Whitelist breakout update
Posted by Frederico Galvão <fr...@pontoget.com.br>.
Looks good to me.
As I understood it, updating cordova and installing the
cordova-plugin-whitelist will bring my project up to par with what I
already have regarding external urls that don't launch external
applications.
Now, regarding the ones that do (launch external applications), what
happens with urls like [tel:<>, sms:<>, mailto:<>, etc]? Are they blocked
by default?
And what about normal http urls that have custom listeners registered, like
'https://maps.google.com/maps?<>' or '
http://itunes.apple.com/WebObjects/MZStore.woa/wa/viewContentsUserReviews?<>'
?
2014-10-30 18:04 GMT-02:00 Ian Clelland <ic...@chromium.org>:
> I've spent the majority of the week finishing up the whitelist-breakout
> code, and I'd invite the rest of the community to take a look, before we
> make anything official.
>
> In order to retain some kind of backward compatibility with existing apps
> (because it's a terrible situation for everyone when we break that), I've
> endeavoured to provide hooks so that all of the existing functionality can
> be moved to a plugin, and so that *something* useful still happens if you
> don't have any plugins at all.
>
> Policy decisions are made centrally (in Android, by CordovaUriHelper; in
> iOS, by CDVViewController), first by asking all installed plugins whether
> to allow or deny the request, and if no plugins reply, then by applying a
> default policy (which is sane, but more restrictive than Cordova 3.6)
>
> Without any plugins, Cordova will allow navigation within the app itself,
> to file urls, and will allow resource loads (XHRs) from that space as well.
> External applications are *not* launched. <access> tags in config.xml are
> completely ignored.
>
> I've also modified the config parsers so that they can be used by plugins.
> (For example, the sample cordova-plugin-whitelist plugin reads config.xml
> to extract <access> tags for building its own whitelist, but other plugins
> could use any other method they wanted)
>
> All of this is in git, on branches named "unplug-whitelist", on these
> repos:
> cordova-android
> cordova-ios
> cordova-plugin-inappbrowser
> cordova-plugin-file-transfer
> cordova-mobile-spec
>
> I wrote a sample plugin --
> https://github.com/clelland/cordova-plugin-whitelist -- which implements
> the Cordova 3.6 behaviour. With that plugin, <access> tags in config.xml
> are parsed, just as they are right now. Navigation and XHR access to
> external resources is controlled by <access origin=... > tags, and
> launching of other applications is controlled by <access origin=...
> launch-external="yes"> tags.
>
> Comments welcome -- either here or on
> https://issues.apache.org/jira/browse/CB-7747
>
> Ian
>
--
*Frederico Galvão*
Diretor de Tecnologia
PontoGet Inovação Web
( +55(62) 8131-5720
* www.pontoget.com.br <http://www.pontoget.com/>