+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? >> > >> > > >> > >> > >> > >> >> > >>
