cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steven Gill <stevengil...@gmail.com>
Subject Re: Android's new Whitelist Plugins
Date Wed, 11 Mar 2015 21:49:22 GMT
Hey Andrew,

I don't see the new plugins in coho yet. Did you forget to push them?

On Wed, Mar 11, 2015 at 7:35 AM, Andrew Grieve <agrieve@chromium.org> wrote:

> Done! They are now alive at their now spots and added to coho's plugins
> list.
>
> On Thu, Mar 5, 2015 at 3:49 PM, Jesse <purplecabbage@gmail.com> wrote:
>
> > +1
> > better late than never
> >
> > @purplecabbage
> > risingj.com
> >
> > On Thu, Mar 5, 2015 at 12:39 PM, Andrew Grieve <agrieve@chromium.org>
> > wrote:
> >
> > > Going with it: https://issues.apache.org/jira/browse/INFRA-9238
> > >
> > > On Wed, Mar 4, 2015 at 11:22 PM, Michal Mocny <mmocny@chromium.org>
> > wrote:
> > >
> > > > +1 to names.
> > > >
> > > > On Wed, Mar 4, 2015 at 9:03 PM, Andrew Grieve <agrieve@chromium.org>
> > > > wrote:
> > > >
> > > >> No comments about the names yet, but I'm now leaning towards:
> > > >>
> > > >> cordova-plugin-legacy-whitelist
> > > >>
> > > >> and
> > > >>
> > > >> cordova-plugin-whitelist
> > > >>
> > > >> as the two new git repos to create (rather than "url-policy")
> > > >>
> > > >> On Wed, Mar 4, 2015 at 8:49 PM, Andrew Grieve <agrieve@chromium.org
> >
> > > >> wrote:
> > > >>
> > > >> > I think how Cordova works right now was the best way. Have access
> > > >> blocked
> > > >> > by default, but have a <access origin="*"/> in the default
> template.
> > > It
> > > >> > makes the setting visible, while still working out-of-the-box.
> > > >> >
> > > >> > If we turned on requests when no whitelist plugin is installed,
> then
> > > >> > existing apps that have <access> tags will have their whitelist
> > > removed
> > > >> > with 4.0.0 and not know it. If someone updates and their app
can't
> > hit
> > > >> the
> > > >> > network anymore, then I think Stack Overflow will tell them why
> > pretty
> > > >> > quickly. We should also be very clear in the release notes and
> > upgrade
> > > >> > guide.
> > > >> >
> > > >> >
> > > >> >
> > > >> >
> > > >> > On Wed, Mar 4, 2015 at 7:54 PM, Nikhil Khandelwal <
> > > >> nikhilkh@microsoft.com>
> > > >> > wrote:
> > > >> >
> > > >> >> I like Ian's proposal of blocking network access only when
a
> > > whitelist
> > > >> >> plugin is added to do so and is choosing to override the
default
> > > >> behavior.
> > > >> >>
> > > >> >> Scanning config.xml on upgrade might be a good way to warn
devs
> to
> > > >> refer
> > > >> >> them to use this plugin. These changes should also be documented
> in
> > > the
> > > >> >> migration guide from Android 3.x to 4.0.
> > > >> >>
> > > >> >> Thanks,
> > > >> >> Nikhil
> > > >> >>
> > > >> >>
> > > >> >> -----Original Message-----
> > > >> >> From: Jesse [mailto:purplecabbage@gmail.com]
> > > >> >> Sent: Wednesday, March 4, 2015 11:05 AM
> > > >> >> To: dev@cordova.apache.org
> > > >> >> Subject: Re: Android's new Whitelist Plugins
> > > >> >>
> > > >> >> I like the defaults as discussed, regardless of how they
are
> > > achieved.
> > > >> >> ie. network yes, intents no
> > > >> >> This is similar to how a plain webview works if you add it
to a
> > > native
> > > >> >> app on ios or android, at least the network part, not sure
what
> the
> > > >> default
> > > >> >> intent handling is.
> > > >> >>
> > > >> >> Are there portions of this functionality that make more sense
as
> > part
> > > >> of
> > > >> >> the platform native code?  To me a plugin that is installed
by
> > > default
> > > >> is
> > > >> >> just modular platform code. Is there ever a reason to NOT
want
> this
> > > >> plugin,
> > > >> >> versus just opening up access?
> > > >> >>
> > > >> >>
> > > >> >>
> > > >> >>
> > > >> >>
> > > >> >>
> > > >> >>
> > > >> >>
> > > >> >>
> > > >> >> @purplecabbage
> > > >> >> risingj.com
> > > >> >>
> > > >> >> On Wed, Mar 4, 2015 at 9:37 AM, Michal Mocny <
> mmocny@chromium.org>
> > > >> wrote:
> > > >> >>
> > > >> >> > I've been working on adding support to just install
the
> whitelist
> > > >> >> > plugin by default, and to add the <access origin="*">
to the
> > > default
> > > >> >> app.
> > > >> >> >
> > > >> >> > Is that sufficient?  I think we may still need to do
what Ian
> > > >> suggests
> > > >> >> > and prompt on upgrade (or prepare)?
> > > >> >> >
> > > >> >> > For downstreams, especially IDE based ones, they will
need to
> > make
> > > >> >> > sure the plugin is added by default however they do
that.
> > > >> >> >
> > > >> >> > On Wed, Mar 4, 2015 at 12:06 PM, Ian Clelland <
> > > >> iclelland@chromium.org>
> > > >> >> > wrote:
> > > >> >> >
> > > >> >> > > On Tue, Mar 3, 2015 at 8:20 PM, Nikhil Khandelwal
<
> > > >> >> > nikhilkh@microsoft.com>
> > > >> >> > > wrote:
> > > >> >> > >
> > > >> >> > > > Here are my thoughts on the default behavior:
> > > >> >> > > > - navigation should be disabled.
> > > >> >> > > > - XHR & network request should be enabled.
> > > >> >> > > >
> > > >> >> > >
> > > >> >> > > And application launch through intent URLs should
also be
> > > disabled.
> > > >> >> > > (IMO)
> > > >> >> > >
> > > >> >> > > That's not a bad default -- it enables CSP usage
by default,
> > > which
> > > >> I
> > > >> >> > think
> > > >> >> > > is good. It also (I think) means we're giving up
on
> suggesting
> > > that
> > > >> >> > network
> > > >> >> > > requests can be completely blocked by default,
because that's
> > > >> >> > > definitely not the case on Android.
> > > >> >> > >
> > > >> >> > > We can implement this within the new framework:
there is the
> > idea
> > > >> of
> > > >> >> > > a 'default policy' that only comes into effect
when no
> plugins
> > > take
> > > >> >> > > responsibility for the whitelist. As soon as any
plugin,
> > though,
> > > >> >> > > handles the shouldAllowRequest() call, for instance,
the
> > default
> > > >> >> > > policy is no longer in effect, and it is a true
whitelist
> > > >> >> > > (block-by-default)
> > > >> >> > >
> > > >> >> > > My biggest concern with this is that developers
are going to
> > > >> blindly
> > > >> >> > update
> > > >> >> > > to Cordova 4.0.0, and when their app *just works*,
they are
> not
> > > >> >> > > going to realize that they are actually less secure
than
> > before.
> > > >> >> > > (Without a
> > > >> >> > plugin,
> > > >> >> > > we've opened up all network access)
> > > >> >> > >
> > > >> >> > > Idea -- maybe we can scan config.xml -- at run
time, or on
> > > prepare,
> > > >> >> > > or on upgrade -- and if we see any access tag other
than
> > <access
> > > >> >> > > origin="*"> we can display a loud message, suggesting
> strongly
> > > that
> > > >> >> > > they install an appropriate plugin.
> > > >> >> > >
> > > >> >> > > Ian
> > > >> >> > >
> > > >> >> > >
> > > >> >> > > >
> > > >> >> > > > The plugin name is fine.
> > > >> >> > > >
> > > >> >> > > > I'm not convinced about a user having to add
this plugin to
> > > >> enable
> > > >> >> > > network
> > > >> >> > > > requests for Android/iOS. This default behavior
should work
> > > with
> > > >> >> > > > the platform and should not require a plugin.
This inhibits
> > > users
> > > >> >> > > > from
> > > >> >> > > getting
> > > >> >> > > > the ground running on a Cordova app. It breaks
existing
> > > templates
> > > >> >> > > > in
> > > >> >> > IDEs
> > > >> >> > > > and other downstream CLIs as well - as all
of them need to
> > > >> include
> > > >> >> > > > this plugin to have any network access work.
> > > >> >> > > >
> > > >> >> > > > Thanks,
> > > >> >> > > > Nikhil
> > > >> >> > > >
> > > >> >> > > >
> > > >> >> > > > -----Original Message-----
> > > >> >> > > > From: mmocny@google.com [mailto:mmocny@google.com]
On
> Behalf
> > > Of
> > > >> >> > > > Michal Mocny
> > > >> >> > > > Sent: Tuesday, March 3, 2015 11:22 AM
> > > >> >> > > > To: dev
> > > >> >> > > > Subject: Re: Android's new Whitelist Plugins
> > > >> >> > > >
> > > >> >> > > > I've filed a JIRA issue with my thoughts on
how to approach
> > > this:
> > > >> >> > > > https://issues.apache.org/jira/browse/CB-8597
> > > >> >> > > >
> > > >> >> > > > On Tue, Mar 3, 2015 at 1:02 PM, Andrew Grieve
> > > >> >> > > > <agrieve@chromium.org>
> > > >> >> > > > wrote:
> > > >> >> > > >
> > > >> >> > > > > Like your ideas a lot. Updating the project
template
> makes
> > a
> > > >> lot
> > > >> >> > > > > of
> > > >> >> > > > sense.
> > > >> >> > > > >
> > > >> >> > > > > Tried to make it clear in the README,
so if any part was
> > not
> > > >> >> > > > > clear please fix it. But, the CSP tag
is the more
> important
> > > >> bit,
> > > >> >> > > > > since <access> can't actually block
all requests. The
> only
> > > >> >> > > > > reason to even leave <access> in
there is to support
> > > pre-kitkat
> > > >> >> > > > > webviews, where no CSP support exists.
CSP is also used
> to
> > > set
> > > >> a
> > > >> >> > > > > navigation whitelist
> > > >> >> > for
> > > >> >> > > > > subframes, which the native side is not
able to do.
> > > >> >> > > > >
> > > >> >> > > > > On Tue, Mar 3, 2015 at 11:22 AM, Michal
Mocny
> > > >> >> > > > > <mmocny@chromium.org>
> > > >> >> > > > wrote:
> > > >> >> > > > >
> > > >> >> > > > > > My thoughts:
> > > >> >> > > > > >
> > > >> >> > > > > > - The split between <allow-navigation>,
<allow-intent>,
> > and
> > > >> >> > <access>:
> > > >> >> > > > > Like
> > > >> >> > > > > > it a lot.
> > > >> >> > > > > > - I think the defaults *for the
plugin* are very
> > > reasonable.
> > > >> >> > > > > > However, we may want to provide
a default set of tags
> for
> > > the
> > > >> >> > > > > > hello world app.  A
> > > >> >> > > > > year
> > > >> >> > > > > > or so ago we added a default access
* whitelist and I
> > think
> > > >> >> > > > > > maybe
> > > >> >> > we
> > > >> >> > > > > should
> > > >> >> > > > > > continue that.  (on the other hand,
I've gotten used to
> > > >> >> > > > > > explicitly whitelisting every url
as part of chrome
> > > packaged
> > > >> >> > > > > > app development and its not so bad).
> > > >> >> > > > > >   - Additionally, that means this
plugin should be
> > > installed
> > > >> >> > > > > > by
> > > >> >> > > > default.
> > > >> >> > > > > > As we discussed this morning, with
the new plugin
> --save
> > > >> >> > > > > > functionality we could just add
this to the helloworld
> > > >> >> > > > > > config.xml,
> > > >> >> > I
> > > >> >> > > > think!
> > > >> >> > > > > > - Do you really need a CSP meta
tag *and* <access>
> > > >> declarations?
> > > >> >> > > >  Thats
> > > >> >> > > > > > what the README.md implies, but
I would assume CSP
> > trumps?
> > > >> >> > > > > >
> > > >> >> > > > > > -Michal
> > > >> >> > > > > >
> > > >> >> > > > > > On Mon, Mar 2, 2015 at 9:38 PM,
Andrew Grieve <
> > > >> >> > agrieve@chromium.org>
> > > >> >> > > > > > wrote:
> > > >> >> > > > > >
> > > >> >> > > > > > > I've tried to explain it in
the plugin's readme:
> > > >> >> > > > > > >
> > > >> >> > > > > > >
> > > >> https://github.com/apache/cordova-plugins/tree/master/url-po
> > > >> >> > > > > > > licy
> > > >> >> > > > > > >
> > > >> >> > > > > > > Some points for discussion:
> > > >> >> > > > > > > - What should the default behaviour
be for the three
> > > >> >> > > > > > > whitelists (what should happen
if not whitelist
> plugin
> > is
> > > >> >> installed).
> > > >> >> > > > > > >   - right now it can't open
external URLs
> > > >> >> > > > > > >   - and can't do XHRs to http(s)
> > > >> >> > > > > > > - Is the plugin name decent
("url-policy"). We should
> > > make
> > > >> a
> > > >> >> > > > > > > dedicated
> > > >> >> > > > > > git
> > > >> >> > > > > > > repo for it (as well as for
legacy-whitelist plugin)
> > > >> >> > > > > > >
> > > >> >> > > > > >
> > > >> >> > > > >
> > > >> >> > > >
> > > >> >> > >
> > > >> >> >
> > > >> >>
> > > >> >>
> > ---------------------------------------------------------------------
> > > >> >> To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> > > >> >> For additional commands, e-mail: dev-help@cordova.apache.org
> > > >> >>
> > > >> >
> > > >> >
> > > >>
> > > >
> > > >
> > >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message