cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Bowser <bows...@gmail.com>
Subject Re: whitelist as a plugin
Date Fri, 10 Oct 2014 16:09:06 GMT
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 <iclelland@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 <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