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 <[email protected]> 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 <[email protected]> > 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 <[email protected]> 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 <[email protected]> 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? > > > > > >
