Hey all, Those of us who have been on the implementing and/or serious consumption side of whitelisting for iOS—I've been on both at one time or another—know how much work has gone into trying to make it a full-featured security subsystem for the iOS version of the framework. I want to share some feedback based on my organization's experiences in implementation, and hopefully spark some discussion about the future of whitelisting on iOS (and maybe the platform as a whole).
We're essentially running into insurmountable issues with whitelisting for the use cases we're attempting, based on the overreach of the NSURLProtocol approach to whitelist handling. I say overreach because, in an ideal world, Cordova should only ever care about safeguarding traffic destined to go through the hybrid/native bridge. This argument can be made for all platforms, but the lack of granularity is most onerously overbearing on iOS, which filters every HTTP(S) packet that goes through the app. Our requirements are very strict with regard to what's whitelisted to go through the bridge. But the bridge is conceptually the only thing we care about, within that particular sphere of security. We have a more relaxed sphere of security for, say, <img src="http://maps.google.com"; />, as the threat vectors exposed through image rendering are considerably less than malicious injected bridge code. Alas, we don't—and arguably never will—have that kind of granular control in iOS, with the current implementation approach. NSURLProtocol is simply too broad-brush to meld into a granular approach for whitelisting. The end result is that we lose the ability to deliver a rich content experience that leverages third party artifacts, because we're forced to go with the sphere of security that gives us the highest scrutiny, across the board. We've been considering (very early phase) some alternative approaches to managing whitelisting. Our current thinking has been focusing on a gatekeeper (on the native side) to the bridge itself. This would enforce some sort of contract between the hybrid and native side, to make a determination of which traffic is authorized to specifically go through the bridge. I'm not sure what that contract looks like at this point, but enforcement would be bridge-specific, and all other webview traffic would otherwise behave as it would in a normal web application. I know from past discussions that many (most?) Cordova developers don't generally use the whitelist, since their security concerns may not be as great, and/or they exclusively host their app functionality locally to the device, which allows them to essentially implement their own controls on attack vectors through selective app content. In our case, we're building an enterprise platform where content could come from any number of sources. And whitelisting controls are not working for us. If there's a future for whitelisting in Cordova 3.0, I personally feel that it needs to be revisited. I'd be interested to hear thoughts from others on their usage patterns, and responses to my concerns. Cheers, Kevin
