cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ian Clelland <iclell...@chromium.org>
Subject Re: whitelist as a plugin
Date Fri, 10 Oct 2014 15:17:29 GMT
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 <agrieve@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 <bowserj@gmail.com> wrote:
>
> > This should land in 4.0.x
> > On Oct 9, 2014 7:38 AM, "Ian Clelland" <iclelland@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 <shazron@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 <agrieve@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 <bowserj@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 <
> > > agrieve@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 <
> > > > iclelland@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 <shazron@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?
> > > > >> > >> > >
> > > > >> > >> >
> > > > >> > >>
> > > > >> >
> > > > >>
> > > >
> > >
> >
>

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