Android policy update

[Mark Waddingham]

On 2017-05-18 00:25, J. Landman Gay via use-livecode wrote:
> I just got a developer email about a revision to Google's policies for
> apps on Google Play. Google will not allow apps that download
> executable code, similar to Apple's policy. It sounds like that
> includes stack content downloaded via a "launcher" app.
> 
> https://play.google.com/about/privacy-security/malicious-behavior/

I would agree with Richard's analysis - albeit with one caveat discussed 
later on.

Is it just me or is the wording of that page is atrocious? I hope there 
is a more detailed normative document in which these restrictions are 
placed (like the Apple SDK/Store Agreement). After all in the 
(presumably non-normative preamble) it says:

"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)."

Then in what appears to be the normative section, it says:

"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."

This is somewhat contradictory without an explicit definition of what 
they mean by 'executable code'. However, reading between the lines I 
would infer that what they mean is this:

"It is explicitly prohibited to allow an app to download code from 
outside of Google Play which is able to call more Android APIs than the 
host app was originally able to do."

Anyway, reading between the lines, the reasoning behind this is simple - 
google can check all dex, JAR and .SO files which flow through Google 
Play for malicious code. They cannot check any code which is downloaded 
outside of Google Play - so if code is downloaded outside of Google Play 
then it must not create any more 'routes in' to the OS in order to 
trigger vulnerabilities and the only 'routes in' to the OS are Android 
API calls, whether they be Java or C.

Anyway, I think you are fine as right now the range of APIs which the 
Android engine uses is fixed at the point of building an Android 
standalone and we are definitely a VM (LiveCode Script runs using an 
Abstract Syntax Tree, LiveCode Builder a ByteCode Machine) - thus we can 
be considered 'JavaScript in a WebView'-like.

Okay so the caveat. I really want the above paragraph to be true, 
however it actually isn't if one casts a critical eye over the whole 
system...

We potentially have an issue with LiveCode Builder... Well, not LiveCode 
Builder, but its FFI capabilities.

It's very presence and the way it works means that in actual fact, we 
cannot say that 'code that runs in a virtual machine has limited access 
to Android APIs' - even the existing C FFI mechanism allows you to hook 
up to arbitrary C APIs; the upcoming Java FFI mechanism makes this even 
easier (as connecting to Java APIs is a fair bit easily than C - from 
the point of view of the developer, at least).

Indeed, LCB modules are loadable at runtime, so you could download an 
LCB module which hooks into APIs the existing app does not; and then 
call them. Further than that, it is possible to write an LCB module 
which allows arbitrary machine code to be executed directly.

This will require some thought - I'd rather LiveCode didn't get 
blacklisted from being considered a 'JavaScript running in a 
WebView'-like language.

Warmest Regards,

Mark.

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