Mobile LC Apps Downloading Stacks After installation

[Mark Waddingham]

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