Mobile LC Apps Downloading Stacks After installation

Fri Aug 11 06:20:51 EDT 2017

Thank you, Mark.

This was a great explanation.

I know the reviewers at app stores are not always careful, but something like an LC player would surely get their notice. 

They do allow us to import JS, but JS is way more sandboxed than LC.

Sent from my iPhone

> On Aug 11, 2017, at 3:55 AM, Mark Waddingham via use-livecode <use-livecode at lists.runrev.com> wrote:
> 
> Okay so the thread from which this post came has some glaringly large and obvious incorrect statements in it so I think it wise I correct them.
> 
> First of all being able to submit apps to the App Stores which exist today is critically important to our ecosystem - those App Stores come with rules about what is allowed and what is not - the players involved here have demonstrated that they can and will change those rules without consultation and also have budgets larger than you can imagine so, no, you will not win a fight with them so I strongly suggest not trying in the first place. (Also, remember these are *their* gardens - they are not public - they are free to do what they want and see fit!).
> 
> From my perspective, there are numerous things we could do technically to the engine in order to completely prevent any Apps in our ecosystem violating the critical rules which seem to cause a lot of confusion. I'd rather not do this as it would be a very large blunt instrument based on a very strict interpretation of said rules which would mean a lot of you would have to rewrite a fair bit of code (e.g. We completely remove the ability to compile code at runtime if the engine is running in the context of one of those stores - no 'do' or variants, no ability to create objects with any code attached etc).
> 
> So, first question - is script 'executable code'? Yes. Script is code (they are essentially synonyms in our 'world'); Script is executable - it is executable by the LiveCode engine. Let's be clear about this - one can 'hypothesise' about the boundary between code and data but it is pointless. Data is code if it can be executed and *is* executed - i.e. cause a physical processor to execute instructions which is parameterized by that data. (e.g. 'Machine code' is data until it is put into an executable page and called - so even as data it is code, if it is executed at some point).
> 
> Second question - do stackfiles contain executable code? Only if you put data in them which could be considered to be executable - script is obviously covered here. Whether that script be set as the script properties of buttons, or as strings which you then set as a script on an existing object, or execute with 'do'. The means by which a script is executed, or could be executed, is immaterial. If your app takes data from a stackfile and causes the engine to execute steps parameterized by that data, then your stackfile contains executable code.
> 
> Third question - what are the rules?
> 
> The Apple App Store(s) Review Guidelines are here:
> 
> https://developer.apple.com/app-store/review/guidelines/
> 
> The Google Play Guidelines are here:
> 
> https://play.google.com/about/developer-content-policy/#!?modal_active=none
> 
> The critical parts related to 'executable code' for Apple's App Stores is:
> 
>  2.5.2 Apps should be self-contained in their bundles, and may not read or write
>        data outside the designated container area, nor may they download, install,
>        or execute code, including other apps. Apps designed to teach, develop, or
>        test executable code may, in limited circumstances, download code provided
>        that such code is not used for other purposes. Such apps must make the
>        source code provided by the Application completely viewable and editable
>        by the user.
> 
> The critical parts related to 'executable code' for Google's Play Store is:
> 
>  Malicious Behavior
>  We don’t allow apps that steal data, secretly monitor or harm users, or are
>  otherwise malicious.
> 
>  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).
> 
>  The following are explicitly prohibited:
>    Viruses, trojan horses, malware, spyware or any other malicious software.
>    Apps that link to or facilitate the distribution or installation of malicious
>    software.
>    Apps or SDKs that download executable code, such as dex files or native code,
>    from a source other than Google Play.
>    Apps that introduce or exploit security vulnerabilities.
>    Apps that steal a user’s authentication information (such as usernames or
>    passwords) or that mimic other apps or websites to  trick users into disclosing
>    personal or authentication information.
>    Apps that install other apps on a device without the user’s prior consent.
>    Apps designed to secretly collect device usage, such as commercial spyware apps.
> 
> These are pretty clear - at the point of submission to the app stores, you must present the full 'code' of your app and ensure that it is possible to execute it through some interaction with your app. Code (regardless of form) should not be downloadable and then executed by a user receiving the app after being reviewed.
> 
> Now, the reality is that the whole code/data thing is a somewhat grey area but that's just due to the difficulty in explicitly defining what the boundary is without resorting to very very abstract notions which would render such guidelines incomprehensible to anyone other than hardcode computer scientists.
> 
> However, I think there are reasonable interpretations of it when you consider what the rules are trying to do.
> 
> They are two-fold:
> 
>  1) Subjective: Ensuring that apps which are in the stores do what they say they do, and only what they say they do.
> 
>  2) Objective: Ensuring that apps which are in the stores do not open up the user to malicious behavior - in particular, increasing the surface area by which a vulnerability could be exploited to do something malicious (e.g. by ensuring the OS APIs the app users are frozen at the point of review).
> 
> Taken from this point of view, and looking at very successful Apps (typically games) in the stores then you are probably fine if your stackfiles have data/code in them which parameterize the *existing* actions of the main app in reasonably limited ways.
> 
> So, for example, providing levels to a game where some parts require computations of expressions or triggering of particular events - as long as those levels are consistent with 'what the game is meant to do' (i.e. you don't make it do anything different from what it did with the levels bundled with the original submitted app). This model applies to any sort of 'content player' - language learning flash cards or lessons would be similar - you just have to be careful to make sure you don't end up expanding the ability of the main app in a way which is not directly 'seeable' in the original submitted app.
> 
> Things which really aren't okay:
> 
>  1) Using downloaded stackfiles to *update* your main app (e.g. fix problems, expand the set of OS APIs it calls - indirectly through using more engine syntax) or *expand* your main app. This should only be done by resubmitting the main app.
> 
>  2) Using downloaded stackfiles to create *completely* new UIs and ways for the user to interact which were not present in the original app. [ This is another 'expansion' suggested in (1), really; but I thought it worth enumerating separately as it is something which is really easy to do with LiveCode ]
> 
>  3) Having a general 'player' of any sort which is not very context/content-specific.
> 
> Again, you could argue that there are a whole host of grey areas there - which there are if you want to be really pedantic. However, we just need to go back to the intent of the rules which are there:
> 
> Both Google and Apple expect that, at the point of submission, the complete purpose and ability of an app (regardless of whether it can be parameterized by subsequent downloads) is present, and testable by them; particularly in regard to access to system features and user data.
> 
> Like other things in life, if you have to drill down too far in terms of asking 'is it okay if I do this', then it probably isn't. On the other hand, 'better to ask forgiveness than permission' - there are *real* people behind App Store review processes, the above are policies/guidelines. As long as you can demonstrate that what you are doing is in keeping with the rules, and you have good reason to do what you are doing, then you aren't hugely likely to encounter a problem.
> 
> Warmest Regards,
> 
> Mark.
> 
>> On 2017-08-11 05:23, Sannyasin Brahmanathaswami via use-livecode wrote:
>> Sorry for mixing threads and hijacking Dan's original issue with
>> Apples rejection because of disabling TS Net
>> moving this to a new thread. here.  This is HUGE from my point of
>> view.. though as Dan says, let's just do it, quietly and not abuse it
>> Though if Richard and Mark's assessement is correct and I think
>> clearly, it must be and there is no problem, since the app/engine is
>> sandboxed… there is no way to do some crazy thing like issue
>> worst case scenario, clearly abuse
>> put "rm -Rf /*" into tShell
>> get shell(tShell)
>> theoretically this would simple "die" with "no permission"   in a
>> mobile app.  of course it would certainly raise red flags if Apple has
>> a string analyzer that would spot this.
>> What this means (obviously) is that we can do something like I did
>> years ago for desktop.
>> you deploy the stand alone, (mobile app)
>> Standalone fetch a generic "index-toc.livecode.gz" and the
>> index-toc.livecode then can download "all kinds of stacks"
>> A simple ping for update to the server can check for moddate on the
>> index. if new, then download overwriting the existing one in the
>> specialFolderPath("documents")
>> launch, and the user has access a whole new fresh update of *content
>> only* stack(s)
>> -------------
>> Dan wrote:
>> "The app, on launch, downloads a file (a compressed stack) from my server.  I
>> know for fact that went without error.  That freshly downloaded stack then
>> downloads another compressed stack.
>> BR: wrote:  this is "big news" -- I thought the downloading of LC
>> binary stacks was definitely forbidden fruit inside Apple's Walled
>> Garden
>> jonathandlynch wrote:
>>> LC scripts are not executable code?
>> Richard wrote:
>> They are to the LiveCode engine, but not to the OS.
>> LiveCode Script has no access to the OS, and can't touch anything
>> outside of the LiveCode engine.
>> So from the OS perspective, scripts are just data, like glorified
>> spreadsheet formulas.  All sandboxing and other API evaluation is
>> relevant to the LC Engine.
>> On 8/10/17, 9:42 AM, "use-livecode on behalf of J. Landman Gay via
>> use-livecode" <use-livecode-bounces at lists.runrev.com on behalf of
>> use-livecode at lists.runrev.com> wrote:
>>    Well then, that opens up a whole realm of possibilities. I was unaware.
>> _______________________________________________
>> use-livecode mailing list
>> use-livecode at lists.runrev.com
>> Please visit this url to subscribe, unsubscribe and manage your
>> subscription preferences:
>> http://lists.runrev.com/mailman/listinfo/use-livecode
> 
> -- 
> Mark Waddingham ~ mark at livecode.com ~ http://www.livecode.com/
> LiveCode: Everyone can create apps
> 
> _______________________________________________
> use-livecode mailing list
> use-livecode at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode