Since the whitelist plugin blocks only a subset of sub-resource loads (just like the existing whitelists), I think we really want to call out that people should not just include the backwards-compatible plugin. Here's a stab at messaging:
If you want nothing to change, use org.apache.cordova.legacy-whitelist. If you care about security, then please understand that there are three types of whitelists to consider: 1. Network traffic - The whitelist has never been able to fully block all network requests in this manner (on iOS and Android). Instead, we recommend using <meta http-equiv="Content-Security-Policy" content="[POLICY GOES HERE]"> in your <head>, which is supported on Android 4.4 and iOS 7. 2. Navigation - By default the webview is allowed to navigate to any page within the same directory tree as the start page. If you'd like to navigate to a different directory, or to a http(s) address, then you should use org.apache.cordova.navigation-whitelist. 3. Intents - By default all URLs that cause an external action (e.g. tel:, sms:, etc) are disabled. If you need to use any of these, then you should use org.apache.cordova.intent-whitelist. On Mon, Nov 3, 2014 at 10:08 PM, Ian Clelland <iclell...@chromium.org> wrote: > On Mon Nov 03 2014 at 4:05:51 PM Marcel Kinard <cmarc...@gmail.com> wrote: > > > This sounds very interesting and relatively graceful. > > > > For a user upgrading to this new world, what would the migration steps > > look like? Or in other words, what would a rough sketch of the upgrade > > guide for this look like? The reason I ask is to see how much pain we'll > > ask our users to go through. > > > > That's certainly a concern -- so for one thing, this would have to be on a > 4.x version of any platforms that it applies to. It is a break in backwards > compatibility, so users should at least be prepared for it. > > That said, I've tried to make it as simple as possible for them: If what > you want is no change at all in behaviour, then your upgrade should be > just: > > cordova plugin add org.apache.cordova.whitelist > > There would be no configuration changes to make: the plugin reads the old > access tags, just as before, and applies the same policies based on them > that it did in 3.6. > > And if your application doesn't rely on access to external sites, then it's > even simpler -- don't install the plugin, and you're likely more secure > than you were before. > > > > On Oct 30, 2014, at 4:04 PM, Ian Clelland <iclell...@chromium.org> > wrote: > > > > > I've spent the majority of the week finishing up the whitelist-breakout > > > code, and I'd invite the rest of the community to take a look, before > we > > > make anything official. > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org > > For additional commands, e-mail: dev-h...@cordova.apache.org > > > > >
