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 <iclell...@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 <agri...@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 <bows...@gmail.com> wrote: > > > > > This should land in 4.0.x > > > On Oct 9, 2014 7:38 AM, "Ian Clelland" <iclell...@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 <shaz...@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 <agri...@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 <bows...@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 < > > > > agri...@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 < > > > > > iclell...@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 < > shaz...@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? > > > > > >> > >> > > > > > > > >> > >> > > > > > > >> > >> > > > > > >> > > > > > > >> > > > > > > > > > > > > > > >
