Android policy update

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Android policy update

Sannyasin Brahmanathaswami via use-livecode
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/

--
Jacqueline Landman Gay         |     [hidden email]
HyperActive Software           |     http://www.hyperactivesw.com

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Android policy update

Sannyasin Brahmanathaswami via use-livecode
J. Landman Gay 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/

Good to know - thanks.

There *might* be some wiggle room here:

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

Whether or not Google would agree that LC is a sort of "VM" is anyone's
guess, but LC Script is limited to LC's APIs and scripts can't extend an
app's permissions beyond what the user has already allowed for the app.

I wouldn't bet the farm on their interpretation, but I know some
developers using a wide range of scripting languages that have been
deploying with data+script download updates for years, even on iOS.  I'm
not recommending it, just noting that apparently within the confines of
the LC VM such things are either not obviously noticeable or not a
concern for the reviewer.

Of course any app that violates any of the other policies outlined on
that page will be dumped ASAP, regardless of how they handle updates.
So folks, don't write jerk apps and let's keep things safe and
user-friendly.

--
  Richard Gaskin
  Fourth World Systems
  Software Design and Development for the Desktop, Mobile, and the Web
  ____________________________________________________________________
  [hidden email]                http://www.FourthWorld.com

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Android policy update

Sannyasin Brahmanathaswami via use-livecode
In reply to this post by Sannyasin Brahmanathaswami via use-livecode
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 ~ [hidden email] ~ http://www.livecode.com/
LiveCode: Everyone can create apps

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Android policy update

Sannyasin Brahmanathaswami via use-livecode
I haven’t been following this topic, but I happen to be at Google I/O. If there are any short questions I could ask while I’m here I could ask around.

One thing I’m going to go to this morning involves Google Play policies.
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Android policy update

Sannyasin Brahmanathaswami via use-livecode
In reply to this post by Sannyasin Brahmanathaswami via use-livecode
The things that you’re talking about, involving an app updating itself, does that currently get past Apple review? That would be an argument to use with Google, in that Apple have usually been tougher about this.

Also, does Google’s policy suggest that you can’t even update an image in the app?
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Android policy update

Sannyasin Brahmanathaswami via use-livecode
On 2017-05-18 15:00, Colin Holgate via use-livecode wrote:
> The things that you’re talking about, involving an app updating
> itself, does that currently get past Apple review? That would be an
> argument to use with Google, in that Apple have usually been tougher
> about this.
>
> Also, does Google’s policy suggest that you can’t even update an image
> in the app?

I think the web-page which Jacque linked to is much too vague - it
doesn't define any of the terms it uses, and contradicts itself as
mentioned
in my previous post.

One thing to find out is what the actual text of the agreement you have
to click through to sign says - I'd imagine that's where the *actual*
T&Cs
are.

As written, a conservative interpretation of that text would suggest no,
you
cannot update an existing image in an app - as that is technically
modifying yourself.

Similarly, it says that you can't 'modify, replace or update' other than
via
the Google Play Store - isn't downloding content modifying the app
technically
speaking?

Of course, I'm splitting hairs here slightly - the intent of the policy
is
crystal clear here, they are trying to ensure that apps cannot leverage
vulnerabilities which were not known at the time the app was submitted
to the
app store.

However, the text on that page is too ill-defined to be *any*
sort of binding agreement - so I hope there's a stricter version.

Warmest Regards,

Mark.

--
Mark Waddingham ~ [hidden email] ~ http://www.livecode.com/
LiveCode: Everyone can create apps

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Android policy update

Sannyasin Brahmanathaswami via use-livecode
In reply to this post by Sannyasin Brahmanathaswami via use-livecode
Dam! I was almost ready to deploy my new iOS app, Jerky 2.0!

Bob S


> On May 17, 2017, at 16:08 , Richard Gaskin via use-livecode <[hidden email]> wrote:
>
> Of course any app that violates any of the other policies outlined on that page will be dumped ASAP, regardless of how they handle updates. So folks, don't write jerk apps and let's keep things safe and user-friendly.
>
> --
> Richard Gaskin


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Android policy update

Sannyasin Brahmanathaswami via use-livecode
The policy does tell you that if an existing app is not allowed you have 30 days to submit an update. So, a little slower that ASAP.


> On May 18, 2017, at 7:51 AM, Bob Sneidar via use-livecode <[hidden email]> wrote:
>
> Dam! I was almost ready to deploy my new iOS app, Jerky 2.0!
>
> Bob S
>
>
>> On May 17, 2017, at 16:08 , Richard Gaskin via use-livecode <[hidden email]> wrote:
>>
>> Of course any app that violates any of the other policies outlined on that page will be dumped ASAP, regardless of how they handle updates. So folks, don't write jerk apps and let's keep things safe and user-friendly.
>>
>> --
>> Richard Gaskin
>


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode