cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Grieve <agri...@chromium.org>
Subject Re: Android's new Whitelist Plugins
Date Wed, 11 Mar 2015 14:35:49 GMT
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