Document warnings on using remote source for <content>

[breautek]

I think there should be better warnings documented about using a remote url for the config.xml tag <content src="..." />

It should be noted that using remote urls can be dangerous for security and is also against the terms of service of both the Apple App & Google Play stores. (Text of interest is in bold).

Apple App Store policy at Section 4.7 HTML5 Games, Bots, etc[1] reads:

Apps may contain or run code that is not embedded in the binary (e.g. HTML5-based games, bots, etc.), as long as code distribution isn’t the main purpose of the app, the code is not offered in a store or store-like interface, and provided that the software (1) is free or purchased using in-app purchase; (2) only uses capabilities available in a standard WebKit view (e.g. it must open and run natively in Safari without modifications or additional software); your app must use WebKit and JavaScript Core to run third-party software and should not attempt to extend or expose native platform APIs to third-party software; (3) is offered by developers that have joined the Apple Developer Program and signed the Apple Developer Program License Agreement; (4) does not provide access to real money gaming, lotteries, or charitable donations; (5) adheres to the terms of these App Review Guidelines (e.g. does not include objectionable content); and (6) does not support digital commerce. Upon request, you must provide an index of software and metadata available in your app. It must include Apple Developer Program Team IDs for the providers of the software along with a URL which App Review can use to confirm that the software complies with the requirements above.

Google Play Store policy "Malicious Behaviour" reads:

An app distributed via Google Play may not modify, replace, or update itself using any method other than Google Play's update mechanism. Likewise, an app may not download executable code (e.g. dex, JAR, .so files) from a source other than Google Play. This restriction does not apply to code that runs in a virtual machine and has limited access to Android APIs (such as JavaScript in a webview or browser).

While the text isn't as explicit as Apple, and the examples are mostly native file examples, it does say that this does not apply to code that has limited access to Android APIs such as Javascript but in Cordova, the javascript does have full access to android APIs via the cordova bridge.

Currently the documentation does not warn the users of this, and I see on a rather frequent basis of this kind of usage, which I think is completely improper.

[1] https://developer.apple.com/app-store/review/guidelines/
[2] https://play.google.com/about/developer-content-policy-print/

[Lindsay-Needs-Sleep]

1-ish)

your app must use WebKit and JavaScript Core to run third-party software and should not attempt to extend or expose native platform APIs to third-party software;

As long as third-party software doesn't touch it, it should be fine. If you only go to your website, (and we are 1st or 2nd party in our app right? no definition of third party to be found), it should be fine? And they can't just mean all third party software.... That would mean no jQuery (remote or local).

Most reasonably, the intent, (baring monetary reasons), is probably to prevent malicious third party code from having access to native APIs. So probably the best way to handle this is not load any script tags except for those tags which you explicitly control. Eg. no dynamic facebook/jquery, only the static versions that you host yourself or have loaded to the app yourself (ensuring no third party has the ability to change their code and gain access through your app).

2-ish)

only uses capabilities available in a standard WebKit view (e.g. it must open and run natively in Safari without modifications or additional software)

Is it correct to say Cordova uses extended capabilities provided by the standard webview? Does that count as safari modifications? If so, I would say that is the end of Cordova.

Apple Conclusion:
If Apple is serious about # 2. Well poop.

Android Conclusion:
Yep. That is worrisome. (Note: if you are using cordova with local urls, you should still be warned not include any dynamic libraries [jQuery], as that would violate this as well. Depending on your interpretation.)

Android ranty thoughts:
Technically, if you wrote the longest string true/false values in json, that corresponded to the most absurdly deep algorithm of native if/else that would be allowed. The json is still just an object, it is downloaded, and it is not executable code, but it appears to violate the spirit of this rule. And if we think that that should not be allowed, that should also be extended to the typical task of downloading a json object of user preferences where we check "if user wants notifications" and change the appropriate native setting. It is technically downloaded code that controls native APIs.
So... I don't really have a great point here, other than the rule isn't very good. It can technically be exploited to achieve the similar results as cordova in this case.

On the other hand, after writing this, I think the kind of thing they are more worried about may be security vulnerabilities by allowing injection of actual native code into the app. Cordova does not support injecting native code into the app (as far as I am aware.)

Perhaps the most fun work around idea would be to have your website load in a vanilla webview, send a command to your webserver like, (userX clicked on Chromecast for videoY), which then sends the information back to a native listener in the app which interprets the object and initiates the command. Disgusting, but a workaround for cordova that doesn't violate the rule.

However, none of these workarounds would be able to replicate the functionality of actual injected native code. Native code could do pretty much anything it wants at all. While cordova exposed native functions is limited to what is initially included in the app. (eg. No gaining code on the fly that can do things outside of the user-granted permissions.)

Overall:
It appears that the most potentially worrisome points require the same notice to be given to people who use local urls as those who remote.
If it is true that these rules apply to cordova, then the warning should be advertised for all of Cordova

(PS. Why do you think this kind of usage is improper? I think it has incredible potential. Eg. write one website that works for desktop and apps. Great for teams low on man power.)

[breautek]

As long as third-party software doesn't touch it, it should be fine.

If it is exposed, it's already a problem (and a security vulnerability)

And they can't just mean all third party software.... That would mean no jQuery (remote or local).

In this context, I believe third-party software just simply means remote software. if jQuery is bundled with the app, then I believe it's okay.

Is it correct to say Cordova uses extended capabilities provided by the standard webview? Does that count as safari modifications? If so, I would say that is the end of Cordova.

Cordova provides this functionality via cordova.js and the cordova bridge that allows javascript to send messages to the native environment, which in then turns into native API calls.

Cordova does not support injecting native code into the app (as far as I am aware.)
Cordova's codebase itself does not inject native code, though technically speaking a plugin could offer that can feature, however that isn't really Cordova's concern. Cordova does give native access to javascript via the cordova bridge, and the bigger problem is accessing these APIs using remote sources.

(PS. Why do you think this kind of usage is improper? I think it has incredible potential. Eg. write one website that works for desktop and apps. Great for teams low on man power.)

You can still do this without relying on a remote sources. You simply bundle your sources with your cordova app. This however does require some thought and planning on how to architect your product(s) so that code can be shared between two apps.

Generally speaking, if you bundle your sources with your app then you're fine. These policies I'm sure are mostly to keep your app secure. An insecure app hurts both you as the developer, and the app provider (because people will blame Apple/Google for allowing your insecure app). Additionally, Apple who wants to review every single app update you publish, they don't like mechanisms where your app can significantly change in behaviour and bypass their review process. Hence the policy "code distribution isn’t the main purpose of the app".

Loading remote content still has their uses. Webpack hot reload server for example, which is useful for development. Enterprise users can build iOS apps that don't get distributed via the apple store so they don't have to obey apples policies is another reason why it's okay to keep the functionality. It's just something users should be aware of if they intend to submit their cordova app to the app stores.

[Lindsay-Needs-Sleep]

Apple who wants to review every single app update you publish, they don't like mechanisms where your app can significantly change in behaviour and bypass their review process. Hence the policy "code distribution isn’t the main purpose of the app".

I see. That makes sense mostly.

But then I find it a bit strange that they even allow webviews. How are custom browser apps even allowed to exist? Browsers may not violate # 2, but they definitely violate at least a few other clauses.

[breautek]

Custom browsers aren't allowed on iOS. Apps must use the webviews provided by the iOS SDK. Chrome for iOS for example is not Chromium, but just the standard ios webview with a chrome skin ui wrapped around the webview.

Google doesn't have such a policy afaik and do allow developers to implement their own webviews.

Webviews are inheritly secure due to their limited
and controlled access to native APIs, but the cordova bridge bypasses this. Not sure on the iOS specific details but on android, this is done by overriding the native method that handles the javascript prompt api, where the javascript will send a serialized string prefixed with a token that signals that "this is a native call", which the native code can intercept and read then call the appropriate API, then return a response. There are multiple bridging strategies I believe they will work in a similar fashion.

Again there is nothing wrong with this, as long as you use it in a proper way.

[Lindsay-Needs-Sleep]

Ah, yes. By “custom browser” I did mean ones such as chrome.

I absolutely understand why cordova could be used to violate # 2 and chrome could not.

I said

Browsers may not violate # 2, but they definitely violate at least a few other clauses.

I am curious why browsers, such as chrome, would be allowed when they violate at least # 3, 4, 5, and 6 for sure? (eg. I can go to whatever inappropriate gambling site I desire.)

[breautek]

I am curious why browsers, such as chrome, would be allowed when they violate at least # 3, 4, 5, and 6 for sure? (eg. I can go to whatever inappropriate gambling site I desire.)

Obviously I cannot speak for Apple but probably is a mixture of, 1) they understand it's a web browser, 2) Google is a reputable company with just as much legal power as Apple.

None of this really is a concern of Cordova though.

[Lindsay-Needs-Sleep]

1. Sure, but it appears that it is still violating the rules. Maybe cordova could use a similar exception.

2. There are tons of other less well known (or not known at all) browsers on the app store (plenty of shady ones too I’m sure). I don’t think they can all get the same big powerful corporation pass as google.

I’m not convinced that either of those are the reasons browsers get a pass.

None of this really is a concern of Cordova though.

True, not directly. But it helps in understanding the intent and purpose of this rule and how it is actually applied. (Which does matter when trying to guess how cordova apps will be judged.)

Thank you for answering my questions!

[dpogue]

Any warnings about this in the docs should also mention the security aspects of allowing uncontrolled remote content to load in the Cordova WebView (as in https://cordova.apache.org/news/2020/09/29/cve-2020-6506.html)