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 ~ m...@livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps
_______________________________________________
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
