It is great design for development, and netflix. Sent from my iPhone
> On Aug 1, 2014, at 4:26 PM, Marc Weiner <[email protected]> wrote: > > It's technically possible, and even (arguably) legal according to Apple's > documentation, depending on the nature of the code and how it's implemented: > > 3.3.2 An Application may not download or install executable code. > Interpreted code may only be used in an Application if all scripts, code > and interpreters are packaged in the Application and not downloaded. The > only exception to the foregoing is scripts and code downloaded and run by > Apple's built-in WebKit framework, provided that such scripts and code do > not change the primary purpose of the Application by providing features or > functionality that are inconsistent with the intended and advertised > purpose of the Application as submitted to the App Store. > > However, I would only do so if the code is coming from a server that you > control, and if you are able to control what code is getting executed. > Loading in 3rd party, unverified scripts into your Cordova view is a big > "no-no" for security reasons, and could get your app delisted (or rejected). > > If anyone else has more information on the topic, I'd be interested in > hearing it. > > Marc > > >> On Fri, Aug 1, 2014 at 7:01 PM, Victor Sosa <[email protected]> wrote: >> >> Hi Frederico. >> >> While what you are saying about the policies stores is true, this applies >> to public stores only (as far as I can tell). For on-premise app stores >> this might be false because each store owner need to set and apply the >> governance for the apps. It could end on horrible results due to a bad >> implementation. >> >> I concur with everyone, it is possible but awful design >> On Aug 1, 2014 4:35 PM, "Frederico Galvão" < >> [email protected]> >> wrote: >> >>> I don't have the details in hand at the moment, but I remember seeing in >>> more than one application store last year policies being changed to >>> disallow remote code to run in an application on-demand. Such rules >> *could* >>> as well be applied to Cordova apps that load remote content considered as >>> code (HTML isn't, but JS is). It's not only a security concern per se, >> but >>> also an imposed limitation on the stores (which were obviously created >> for >>> security concerns in the first place). >>> >>> Not even mentioning the issues with providing the right cordova.js >> version >>> from the remote server not really knowing where the request came from. >>> However, it's good to note too that aside Phonegap Developer App, there >> is >>> also Adobe Hydration that does the exact same thing as a side service to >>> Phonegap Build. I don't know if they've come into any of the issues >>> mentioned, and I haven't even heard of it being used in production. >>> >>> >>> 2014-08-01 17:36 GMT-03:00 purplecabbage <[email protected]>: >>> >>>> I agree with all your statements Marcel. I use this approach frequently >>> in >>>> dev for fast turnaround. >>>> Ultimately App Store policies decide what can and cannot be done. >>>> >>>> Regarding security, there is nothing I can do with a remote page that I >>>> can't already do inside my app. It's an issue of trust. >>>> >>>> >>>> Sent from my iPhone >>>> >>>>> On Aug 1, 2014, at 10:35 AM, Shazron <[email protected]> wrote: >>>>> >>>>> I agree that it is not recommended, but it's possible. I delved into >>>>> this question here: >>>>> https://github.com/shazron/phonegap-questions/issues/37 >>>>> >>>>> The PhoneGap Developer App is an example of how this is working at >>>>> http://app.phonegap.com but they do some proxying to get around the >>>>> CORS limitations I believe. >>>>> >>>>>> On Fri, Aug 1, 2014 at 10:23 AM, Marcel Kinard <[email protected]> >>>> wrote: >>>>>> I've been getting occasional questions about users trying to use >>>> remotely-loaded (non-local) HTML pages with Cordova (in the webview, >> not >>>> InAppBrowser), and still expecting to have access to the plugin APIs >>>> (camera is a popular one). My response so far is: "This is an >> unsupported >>>> configuration, because Cordova was not designed for this and the >>> community >>>> does no testing of this configuration. While it can work in some >>>> circumstances, it is not recommended nor supported." >>>>>> >>>>>> My definition of "unsupported" is not that it is incapable, but that >>> we >>>> don't claim that it is supposed to work, and more importantly, we won't >>>> actively fix user-submitted defects on this topic. >>>>>> >>>>>> The main concern I have on this is same origin policy, and matching >>> the >>>> remotely-served cordova.js with the locally-installed native Cordova >>>> platform to avoid version mismatch. >>>>>> >>>>>> Do you think I'm out in-the-weeds on this, or do you agree? >>>>>> >>>>>> If you agree, what would you think of a blurb in cordova-docs >>> somewhere >>>> that captures this gist? >>>>>> >>>>>> Thanks for your feedback! >>> >>> >>> >>> -- >>> >>> *Frederico Galvão* >>> >>> Diretor de Tecnologia >>> >>> PontoGet Inovação Web >>> >>> >>> ( +55(62) 8131-5720 >>> >>> * www.pontoget.com.br <http://www.pontoget.com/> >>
