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