Splash-stack apps on Google Play

Mark Waddingham mark at livecode.com
Mon May 21 14:15:50 EDT 2018


On 2018-05-21 17:51, J. Landman Gay via use-livecode wrote:
> My client sells supplies to hospitals and the mobile app is part of a
> tracking system. We have been distributing the app from a web site but
> some users don't trust that and others don't understand why they need
> to enable "unknown sources" in prefs. It would be easier to distribute
> through the official channel.
> 
> If there are any issues with the app we need immediate fixes or the
> tracking breaks. A remote stack allows me to do that.
> 
> A while back Colin was going to get a Google reviewer in touch with
> Mark Waddingham so Mark could explain why this isn't dangerous in LC
> but I'm not sure what happened to that.

I never received any contact from Google on this topic - although it 
sounds like Colin has had confirmation that they seem relatively happy 
with the LiveCode apps they have found with regards the new Play Store 
rules.

Re-reading the policy again the two main points it contains which are 
relevant here are as follows:

"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:
...
Apps or SDKs that download executable code, such as dex files or native 
code, from a source other than Google Play.
..."

The reason to impose these rules is simply to protect the end-user from 
malicious intent. In this case, the specific thing they are trying to 
protect users from is an app vendor who unknowingly creates a vehicle 
for such action - the maliciousness could be from being able to exploit 
unknown vulnerabilities in system APIs (breaking the app sandbox), or 
from being able to subvert an app and the interaction it has with the 
user.

The thing to remember is that anything downloaded over the internet is 
at risk if the connection is not properly secured. For a connection to 
be properly secured it is not just sufficient to use SSL (or variants 
there-of) but also to ensure that the server end-point is also secure. 
For example, you might put your code update on a server which is subject 
to a hacking attack, and in through doing so the hackers find they can 
inject arbitrary code into all currently installed instances of your app 
by changing the update code file which is downloaded.

Maintaining a server which allows download of invisible executable code 
updates straight into apps on end-user devices is a significant 
responsibility - and it is too much of a risk to allow in the general 
case especially given both the quantity of app vendors and their widely 
varying resources.

So, what can we do?

The first thing is something you as a developer can do (and really 
should if you need this convenicene)...

If you need to download updates 'on the fly', and your updates do 
contain executable code (which LiveCode Script is) the you can use 
public key cryptography to sign your downloads. Basically you generate a 
public and private RSA key pair. The private one must be treated with 
due diligence, and is used to create a signature of the stack which 
contains your updates. The app itself contains the public key - when the 
app updates, after downloading the stack, it verifies the signature and 
only applies it if the verification succeeds. Assuming you take due 
diligence over your private key (in particular never store it on the 
same server as the app update!), then it means that your updates cannot 
be subverted - regardless of whether your update server is hacked. If 
your private key does become compromised, then you release no more 
updates signed with it, and issue a Google Play Store update for your 
app which contains a new public key.

Note: I should point out, you don't need a 'root CA signed code cert' 
for the above - a public/private key pair you generate yourself is more 
than sufficient since you are baking the public key into an app 
submitted to the google play store which is signed using similar trust 
mechanisms which is globally verifiable.

The second thing is something we can do to the engine itself...

There is a critical line in the above: "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)."

As it stands right now, you can load LCB extensions at runtime in 
standalones which have bene downloaded. This is a hole we can close by 
adding an option to turn off the 'load extension' command in standalones 
in the S/B. This means that LiveCode Android apps, when built with that 
option turned on fall into the category of "code that runs in a virtual 
machine and has limited access to Android APIs". I'll chat to Ali about 
making this happen sooner rather than later, we can make it a curmudgeon 
in the first instance, and (if there is need) make it more fine-grained 
in the future (after all an LCB module which does not use any foreign 
handlers is of no risk).

We, therefore, have a two-pronged attack we can make to ensure that 
LiveCode app vendors can use the convenience of side-loaded updates 
which should fit well within the bounds of the Google Play Store API.

So, @Jacque, carry on doing what you are doing but do implement the 
code-signing as outlined above as soon as you possibly can - even 
without any changes to the engine itself, with that in place, if Google 
were to question your app's behavior, you can clearly demonstrate you 
have taken due diligence and have essentially ensured that your client's 
app can never be a vehicle for malicious intent.

Warmest Regards,

P.S. I realize the above 'outline' of how to do code signing using PKI 
is somewhat brief. I'll endeavour to write it up in more detail as soon 
as I can.

-- 
Mark Waddingham ~ mark at livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps




More information about the use-livecode mailing list