Re: Mobile LC Apps Downloading Stacks After installation

[Richard Gaskin via use-livecode]

Mark Waddingham wrote:

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

Great post. Thanks.

My apologies if anything I wrote was construed as misrepresenting your 
opinion.  Not my intention.  Perhaps I misinterpreted the meaning of 
"fine" here in your post from May in the thread about similar 
downloading policies on Android:


If LCB FFI is not used, then everything is fine. If it is used,
then it does open the door to being able to download non-native
executable (LCB VM) code to be downloaded and extend the API
access of an app.



The following reflects only my own opinions; I am neither an attorney 
nor a representative of any company other than my own:



In actionable terms, this discussion, like so many others in life, may 
be boiled down to four words:


   Don't be a jerk.

No OS vendor wants to approve an app for distribution through their 
platform and have it later morph into something else.


Downloading "executable code" is probably the least of concerns for most 
developers.  Most OS vendors provide a long list of reasons they may 
remove your app and/or ban you from their distribution outlets, 
including content they deem objectionable, simply being one of a 
category they consider already overpopulated, being in their view too 
easily replicable in a web page, or just not looking good.


Moreover, in addition to the explicit reasons they list, they also 
provide a catch-all for a potentially infinite variety of reasons not 
listed.


iOS:
   9. Amendment; Communication. Apple reserves the right, at its
   discretion, to modify this Agreement, including any rules and
   policies at any time.


Android:
   7. Google Takedowns
   ...other terms of service as may be updated by Google from time to
   time in its sole discretion;


These rules are vague, but not arbitrary.  All of them, including the 
"at its sole discretion" clauses, are there to protect interests of the 
company and/or their customers.


We can explore "executable code" as long as we find the discussion 
enjoyable (I'll even indulge in a bit of that below), but the bottom 
line is that we don't want to build a reputation for ourselves as 
developers, or for LiveCode as a platform, as being a gang of rogue 
miscreants hellbent on testing the boundaries of acceptability.  That 
would be jerkish.  Don't be a jerk.



Beyond "executable code", we want to try to adhere to all aspects of app 
safety and quality the distribution outlet vendors ask for.  I think 
Mark's opening and closing comments sum this up well:


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


Earnestness goes a long way in building trust.  Make an earnest effort 
to deliver a high-quality user experience that's useful and enjoyable, 
and your chances of meeting with app removal will drop significantly.


Those chances of removal will never be completely eliminated. Even if 
you don't download "executable code" and reasonably comply with the 
other stated terms, the "at its sole discretion" clause le

Re: Mobile LC Apps Downloading Stacks After installation

[Mark Waddingham via use-livecode]

That sounds like the best approach.

Whilst it might seem 'annoying' to not use code in download files, I think 
LiveCode still makes it easier to not have to.

It is just that you have to work a little bit harder to separate content from 
code - and parameterise the parts (using data) which you might have written 
directly in code if there wasn't such a restriction.

Of course, as Richard points out, there are still areas where 'executable code' 
has to be allowed (expressions in spreadsheets are code after all - although 
admittedly side-effect free in some sense which *might* be the start of a line 
to draw) - however I think it wise to restrict those to things which are 
created by the user in their documents - and make sure they are heavily 
sandboxed / only allow very specific actions in line with the purpose the app.

Warmest Regards,

Mark.

Sent from my iPhone

> On 11 Aug 2017, at 20:21, Sannyasin Brahmanathaswami via use-livecode 
>  wrote:
> 
> Mark, thanks for the thorough explanation.
> 
> I would go on record to say that "vision" for our use of such  
> post/sideloading option would fall well within th UI/UX of the existing app, 
> since, from a design point of view our goals would want it to be virtually 
> transparent.
> 
> That said, the CMS can get a bit snakey over time, and possibly a better way 
> to go, at least in our context of wanting to add on new modules, would be to 
> bundle the LC binary/views/script into updates that would be reviewed and 
> then post download only   image-sounds-words-jsons-assets.gz bundles. unpack 
> these and then binary uses them…
> 
> This then allow us to add more to the app without adding more  MB to the 
> package size (since these LC binaries as pure view can be as small as 50 K) 
> and then we just use side loading for what really *is* only *data*
> 
> this would be playing it very safe, and in someways, guard against ad hoc dev 
> CMS which is too easy to do with LC 
> 
> 
> BR
> 
> On 8/10/17, 9:56 PM, "use-livecode on behalf of Mark Waddingham via 
> use-livecode"  use-livecode@lists.runrev.com> wrote:
> 
>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.
> 
> ___
> 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


___
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

Re: Mobile LC Apps Downloading Stacks After installation

[Sannyasin Brahmanathaswami via use-livecode]

Mark, thanks for the thorough explanation.

I would go on record to say that "vision" for our use of such  post/sideloading 
option would fall well within th UI/UX of the existing app, since, from a 
design point of view our goals would want it to be virtually transparent.

That said, the CMS can get a bit snakey over time, and possibly a better way to 
go, at least in our context of wanting to add on new modules, would be to 
bundle the LC binary/views/script into updates that would be reviewed and then 
post download only   image-sounds-words-jsons-assets.gz bundles. unpack these 
and then binary uses them…

This then allow us to add more to the app without adding more  MB to the 
package size (since these LC binaries as pure view can be as small as 50 K) and 
then we just use side loading for what really *is* only *data*

this would be playing it very safe, and in someways, guard against ad hoc dev 
CMS which is too easy to do with LC 


BR

On 8/10/17, 9:56 PM, "use-livecode on behalf of Mark Waddingham via 
use-livecode"  wrote:

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.

___
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

Re: Mobile LC Apps Downloading Stacks After installation

[Mark Waddingham via use-livecode]

On 2017-08-11 18:00, Mike Kerner via use-livecode wrote:
That's not what I'm saying.  What I'm saying is while telling everyone 
to
control themselves is good, removing these capabilities from LC is bad, 
so

if the time comes where it is necessary to do something to stop someone
from behaving badly, please make sure we have a switch in place that 
allows

the rest of us to continue as-is.


Hence my comment about 'when being run from an App Store installed 
environment'. It is easy to check if an App is running when installed 
from an AppStore...


Indeed, you have to build such things using a 'distribution profile' 
specific to the store - so any action would be at standalone-build time, 
rather than anywhere else.


To be fair, I don't think it is likely to happen... However, unlikely 
does not mean impossible!


Warmest Regards,

Mark.

P.S. I'd also rather not have to expend the resources doing it - there 
are far better things we could be doing than figuring out ways to turn 
dynamic features into static ones, or reworking stuff so the dynamic 
features could be turned off. I much prefer the 'with great power comes 
great responsibility' approach - i.e. trust!


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

Re: Mobile LC Apps Downloading Stacks After installation

[Mike Kerner via use-livecode]

That's not what I'm saying.  What I'm saying is while telling everyone to
control themselves is good, removing these capabilities from LC is bad, so
if the time comes where it is necessary to do something to stop someone
from behaving badly, please make sure we have a switch in place that allows
the rest of us to continue as-is.

On Fri, Aug 11, 2017 at 11:31 AM, Mark Waddingham via use-livecode <
use-livecode@lists.runrev.com> wrote:

> On 2017-08-11 16:35, Mike Kerner via use-livecode wrote:
>
>> Unless I read your post incorrectly, mark, "Do" works just fine, at least
>>
>
> Yes it does - the point I was making was that breaking the rules in the
> App Store could end up with us having to restrict what the LiveCode engine
> can do when being run in an App Store Installed environment to ensure that
> we aren't blocked from said App Store. The blunt instrument would be not
> allowing *any* dynamic code execution (which is essentially what Apple
> *did* do for a while in 2010).
>
> The sideloading/bootstrapping capabilities in LC are a fantastic way to
>> work on corporate apps, force updates, and save everyone time and hassle.
>>
>
> What happens inside corporations within the Enterprise schemes the App
> Stores have is not the issue here. There you can do whatever you like -
> within what the IT departments allow, at least.
>
> This is the consumer facing App Store(s) which have these restrictions.
> Primarily to protect people who don't want to have to understand all the
> details of the risks involved with having hugely powerful computational
> devices in their pockets which can download and run code provided by (what
> are, in reality) very loosely vetted organisations/businesses/individuals.
> Particularly when those computational devices also tend to store their
> entire 'lives' (in terms of personal details, financial details, contacts,
> etc.).
>
>
> Warmest Regards,
>
> Mark.
>
> --
> 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
>



-- 
On the first day, God created the heavens and the Earth
On the second day, God created the oceans.
On the third day, God put the animals on hold for a few hours,
   and did a little diving.
And God said, "This is good."
___
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

Re: Mobile LC Apps Downloading Stacks After installation

[Mark Waddingham via use-livecode]

On 2017-08-11 16:35, Mike Kerner via use-livecode wrote:
Unless I read your post incorrectly, mark, "Do" works just fine, at 
least


Yes it does - the point I was making was that breaking the rules in the 
App Store could end up with us having to restrict what the LiveCode 
engine can do when being run in an App Store Installed environment to 
ensure that we aren't blocked from said App Store. The blunt instrument 
would be not allowing *any* dynamic code execution (which is essentially 
what Apple *did* do for a while in 2010).



The sideloading/bootstrapping capabilities in LC are a fantastic way to
work on corporate apps, force updates, and save everyone time and 
hassle.


What happens inside corporations within the Enterprise schemes the App 
Stores have is not the issue here. There you can do whatever you like - 
within what the IT departments allow, at least.


This is the consumer facing App Store(s) which have these restrictions. 
Primarily to protect people who don't want to have to understand all the 
details of the risks involved with having hugely powerful computational 
devices in their pockets which can download and run code provided by 
(what are, in reality) very loosely vetted 
organisations/businesses/individuals. Particularly when those 
computational devices also tend to store their entire 'lives' (in terms 
of personal details, financial details, contacts, etc.).


Warmest Regards,

Mark.

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

Re: Mobile LC Apps Downloading Stacks After installation

[Mike Kerner via use-livecode]

Unless I read your post incorrectly, mark, "Do" works just fine, at least
for ad hoc apps, as well it better, because it is a critically important
part of trying to debug mobile apps at runtime, with some of the rather
annoying things that happen at runtime, like some failure in a script
causing that script to silently exit without any notice or message.  "Do"
lets me add the equivalent of the message box when I'm working on an app.
Before I realized that it worked, about half of the lines of code in any
app I wrote was related to debugging some issue or another.  The ability to
use "Do" means far fewer debugging builds and a lot less shaking my
monitor, cursing the runtime engine for being so unhelpful, and me for
choosing coding over septic technician.

The remote debugger is a great new tool to have in the toolbox, but "do" is
still the one that saves me when everything just stops.

The sideloading/bootstrapping capabilities in LC are a fantastic way to
work on corporate apps, force updates, and save everyone time and hassle.
___
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

Re: Mobile LC Apps Downloading Stacks After installation

[Jonathan Lynch via use-livecode]

If we could have our own LC App Store, where people could play an app with a 
player app on different platforms, it would be quite excellent.

At the very least, I think Apple would object.

Sent from my iPhone

> On Aug 11, 2017, at 10:09 AM, Roger Eller via use-livecode 
>  wrote:
> 
> Several companies HAVE their own app stores.  Samsung is one that comes to
> mind.  http://joyofandroid.com/android-app-store-alternatives/
> 
> ~Roger
> 
> 
> On Fri, Aug 11, 2017 at 10:00 AM, Jonathan Lynch via use-livecode <
> use-livecode@lists.runrev.com> wrote:
> 
>> If Apple and Google allowed player apps that play external code, companies
>> could essentially set up their own app stores, bypassing google play and
>> iTunes.
>> I cannot imagine either company would appreciate that.
>> 
>> Sent from my iPhone
>> 
>>> On Aug 11, 2017, at 9:52 AM, Ralph DiMola via use-livecode <
>> use-livecode@lists.runrev.com> wrote:
>>> 
>>> Mark,
>>> 
>>> Thanks for weighing in. I would like to read into those licenses that I
>>> could update my core LCS, but I know in my soul that if I do that it's
>> just
>>> a shoe waiting to drop that could affect not only my license but the
>> entire
>>> LC community. I also feel that when I create an extra button(with stub
>> code)
>>> because a "data" update offers more options that I am staying within the
>>> guidelines and the spirit of the App/Play store rules. I see this as
>> simple
>>> decision. I call it the "Johnny, did you eat a cookie?" scenario. Johnny
>>> says "no" because he did not eat "A" cookie but ate 3 cookies. I am not
>> a 2
>>> year old and know what these rules were intended to prevent.
>>> 
>>> By the way, I was once rejected because my data update "answer" dialog
>> was
>>> worded as "An app update is available". I explained that it was a data
>>> update and not code and changed the verbiage of the dialog. I then passed
>>> the review. Moral: The review team can look VERY close at any app during
>>> review.
>>> 
>>> As it was said in Goodfellows... At least, that's how I feel.
>>> 
>>> Ralph DiMola
>>> IT Director
>>> Evergreen Information Services
>>> rdim...@evergreeninfo.net
>>> 
>>> 
>>> -Original Message-
>>> From: use-livecode [mailto:use-livecode-boun...@lists.runrev.com] On
>> Behalf
>>> Of Mark Waddingham via use-livecode
>>> Sent: Friday, August 11, 2017 7:24 AM
>>> To: How to use LiveCode
>>> Cc: Mark Waddingham
>>> Subject: Re: Mobile LC Apps Downloading Stacks After installation
>>> 
>>>> On 2017-08-11 12:20, Jonathan Lynch via use-livecode wrote:
>>>> I know the reviewers at app stores are not always careful, but
>>>> something like an LC player would surely get their notice.
>>> 
>>> Review, from my understanding, is heavily automated (it has to be - if
>> you
>>> think of the scale of the App Stores these days). However, there is
>> always a
>>> means to get in contact with a human about specific issues (which can
>> take a
>>> while to get escalated with someone who can actually do something - but
>> at
>>> least it is possible).
>>> 
>>>> They do allow us to import JS, but JS is way more sandboxed than LC.
>>> 
>>> Yes - this is true - however, as I noticed this morning Apple no longer
>> have
>>> their advisory about allowing arbitrary JS to be downloaded and run
>> within a
>>> WebView. This is simply because you can could build a host app which
>> gives
>>> access to every single OS API on iOS and make all of them callable from
>> JS
>>> (even if the JS bundled with the app does not use any of it).
>>> 
>>> So, the point is the language is not the point - what the code running in
>>> the language does is important.
>>> 
>>> Like Google, Apple are wanting to know precisely what OS APIs your app is
>>> calling at the point of review - so they have some idea of the surface
>> area
>>> of attack for any malicious intent. How much analysis they currently do,
>>> no-one really knows - however the guidelines means that (in principal)
>> they
>>> have reasons to pull any apps very quickly if they find that they are
>> doing
>>> something which is 'not allowed'.
>>> 
>>> Warmest 

Re: Mobile LC Apps Downloading Stacks After installation

[Roger Eller via use-livecode]

Several companies HAVE their own app stores.  Samsung is one that comes to
mind.  http://joyofandroid.com/android-app-store-alternatives/

~Roger


On Fri, Aug 11, 2017 at 10:00 AM, Jonathan Lynch via use-livecode <
use-livecode@lists.runrev.com> wrote:

> If Apple and Google allowed player apps that play external code, companies
> could essentially set up their own app stores, bypassing google play and
> iTunes.
> I cannot imagine either company would appreciate that.
>
> Sent from my iPhone
>
> > On Aug 11, 2017, at 9:52 AM, Ralph DiMola via use-livecode <
> use-livecode@lists.runrev.com> wrote:
> >
> > Mark,
> >
> > Thanks for weighing in. I would like to read into those licenses that I
> > could update my core LCS, but I know in my soul that if I do that it's
> just
> > a shoe waiting to drop that could affect not only my license but the
> entire
> > LC community. I also feel that when I create an extra button(with stub
> code)
> > because a "data" update offers more options that I am staying within the
> > guidelines and the spirit of the App/Play store rules. I see this as
> simple
> > decision. I call it the "Johnny, did you eat a cookie?" scenario. Johnny
> > says "no" because he did not eat "A" cookie but ate 3 cookies. I am not
> a 2
> > year old and know what these rules were intended to prevent.
> >
> > By the way, I was once rejected because my data update "answer" dialog
> was
> > worded as "An app update is available". I explained that it was a data
> > update and not code and changed the verbiage of the dialog. I then passed
> > the review. Moral: The review team can look VERY close at any app during
> > review.
> >
> > As it was said in Goodfellows... At least, that's how I feel.
> >
> > Ralph DiMola
> > IT Director
> > Evergreen Information Services
> > rdim...@evergreeninfo.net
> >
> >
> > -----Original Message-
> > From: use-livecode [mailto:use-livecode-boun...@lists.runrev.com] On
> Behalf
> > Of Mark Waddingham via use-livecode
> > Sent: Friday, August 11, 2017 7:24 AM
> > To: How to use LiveCode
> > Cc: Mark Waddingham
> > Subject: Re: Mobile LC Apps Downloading Stacks After installation
> >
> >> On 2017-08-11 12:20, Jonathan Lynch via use-livecode wrote:
> >> I know the reviewers at app stores are not always careful, but
> >> something like an LC player would surely get their notice.
> >
> > Review, from my understanding, is heavily automated (it has to be - if
> you
> > think of the scale of the App Stores these days). However, there is
> always a
> > means to get in contact with a human about specific issues (which can
> take a
> > while to get escalated with someone who can actually do something - but
> at
> > least it is possible).
> >
> >> They do allow us to import JS, but JS is way more sandboxed than LC.
> >
> > Yes - this is true - however, as I noticed this morning Apple no longer
> have
> > their advisory about allowing arbitrary JS to be downloaded and run
> within a
> > WebView. This is simply because you can could build a host app which
> gives
> > access to every single OS API on iOS and make all of them callable from
> JS
> > (even if the JS bundled with the app does not use any of it).
> >
> > So, the point is the language is not the point - what the code running in
> > the language does is important.
> >
> > Like Google, Apple are wanting to know precisely what OS APIs your app is
> > calling at the point of review - so they have some idea of the surface
> area
> > of attack for any malicious intent. How much analysis they currently do,
> > no-one really knows - however the guidelines means that (in principal)
> they
> > have reasons to pull any apps very quickly if they find that they are
> doing
> > something which is 'not allowed'.
> >
> > Warmest Regards,
> >
> > Mark.
> >
> > --
> > 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
> >
> >
> > ___
> > 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
>
> ___
> 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
>
___
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

Re: Mobile LC Apps Downloading Stacks After installation

[Jonathan Lynch via use-livecode]

If Apple and Google allowed player apps that play external code, companies 
could essentially set up their own app stores, bypassing google play and iTunes.
I cannot imagine either company would appreciate that.

Sent from my iPhone

> On Aug 11, 2017, at 9:52 AM, Ralph DiMola via use-livecode 
>  wrote:
> 
> Mark,
> 
> Thanks for weighing in. I would like to read into those licenses that I
> could update my core LCS, but I know in my soul that if I do that it's just
> a shoe waiting to drop that could affect not only my license but the entire
> LC community. I also feel that when I create an extra button(with stub code)
> because a "data" update offers more options that I am staying within the
> guidelines and the spirit of the App/Play store rules. I see this as simple
> decision. I call it the "Johnny, did you eat a cookie?" scenario. Johnny
> says "no" because he did not eat "A" cookie but ate 3 cookies. I am not a 2
> year old and know what these rules were intended to prevent.
> 
> By the way, I was once rejected because my data update "answer" dialog was
> worded as "An app update is available". I explained that it was a data
> update and not code and changed the verbiage of the dialog. I then passed
> the review. Moral: The review team can look VERY close at any app during
> review.
> 
> As it was said in Goodfellows... At least, that's how I feel.
> 
> Ralph DiMola
> IT Director
> Evergreen Information Services
> rdim...@evergreeninfo.net
> 
> 
> -Original Message-
> From: use-livecode [mailto:use-livecode-boun...@lists.runrev.com] On Behalf
> Of Mark Waddingham via use-livecode
> Sent: Friday, August 11, 2017 7:24 AM
> To: How to use LiveCode
> Cc: Mark Waddingham
> Subject: Re: Mobile LC Apps Downloading Stacks After installation
> 
>> On 2017-08-11 12:20, Jonathan Lynch via use-livecode wrote:
>> I know the reviewers at app stores are not always careful, but 
>> something like an LC player would surely get their notice.
> 
> Review, from my understanding, is heavily automated (it has to be - if you
> think of the scale of the App Stores these days). However, there is always a
> means to get in contact with a human about specific issues (which can take a
> while to get escalated with someone who can actually do something - but at
> least it is possible).
> 
>> They do allow us to import JS, but JS is way more sandboxed than LC.
> 
> Yes - this is true - however, as I noticed this morning Apple no longer have
> their advisory about allowing arbitrary JS to be downloaded and run within a
> WebView. This is simply because you can could build a host app which gives
> access to every single OS API on iOS and make all of them callable from JS
> (even if the JS bundled with the app does not use any of it).
> 
> So, the point is the language is not the point - what the code running in
> the language does is important.
> 
> Like Google, Apple are wanting to know precisely what OS APIs your app is
> calling at the point of review - so they have some idea of the surface area
> of attack for any malicious intent. How much analysis they currently do,
> no-one really knows - however the guidelines means that (in principal) they
> have reasons to pull any apps very quickly if they find that they are doing
> something which is 'not allowed'.
> 
> Warmest Regards,
> 
> Mark.
> 
> --
> 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
> 
> 
> ___
> 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

___
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

RE: Mobile LC Apps Downloading Stacks After installation

[Ralph DiMola via use-livecode]

Mark,

Thanks for weighing in. I would like to read into those licenses that I
could update my core LCS, but I know in my soul that if I do that it's just
a shoe waiting to drop that could affect not only my license but the entire
LC community. I also feel that when I create an extra button(with stub code)
because a "data" update offers more options that I am staying within the
guidelines and the spirit of the App/Play store rules. I see this as simple
decision. I call it the "Johnny, did you eat a cookie?" scenario. Johnny
says "no" because he did not eat "A" cookie but ate 3 cookies. I am not a 2
year old and know what these rules were intended to prevent.

By the way, I was once rejected because my data update "answer" dialog was
worded as "An app update is available". I explained that it was a data
update and not code and changed the verbiage of the dialog. I then passed
the review. Moral: The review team can look VERY close at any app during
review.

As it was said in Goodfellows... At least, that's how I feel.

Ralph DiMola
IT Director
Evergreen Information Services
rdim...@evergreeninfo.net


-Original Message-
From: use-livecode [mailto:use-livecode-boun...@lists.runrev.com] On Behalf
Of Mark Waddingham via use-livecode
Sent: Friday, August 11, 2017 7:24 AM
To: How to use LiveCode
Cc: Mark Waddingham
Subject: Re: Mobile LC Apps Downloading Stacks After installation

On 2017-08-11 12:20, Jonathan Lynch via use-livecode wrote:
> I know the reviewers at app stores are not always careful, but 
> something like an LC player would surely get their notice.

Review, from my understanding, is heavily automated (it has to be - if you
think of the scale of the App Stores these days). However, there is always a
means to get in contact with a human about specific issues (which can take a
while to get escalated with someone who can actually do something - but at
least it is possible).

> They do allow us to import JS, but JS is way more sandboxed than LC.

Yes - this is true - however, as I noticed this morning Apple no longer have
their advisory about allowing arbitrary JS to be downloaded and run within a
WebView. This is simply because you can could build a host app which gives
access to every single OS API on iOS and make all of them callable from JS
(even if the JS bundled with the app does not use any of it).

So, the point is the language is not the point - what the code running in
the language does is important.

Like Google, Apple are wanting to know precisely what OS APIs your app is
calling at the point of review - so they have some idea of the surface area
of attack for any malicious intent. How much analysis they currently do,
no-one really knows - however the guidelines means that (in principal) they
have reasons to pull any apps very quickly if they find that they are doing
something which is 'not allowed'.

Warmest Regards,

Mark.

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


___
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

Re: Mobile LC Apps Downloading Stacks After installation

[Mark Waddingham via use-livecode]

On 2017-08-11 12:20, Jonathan Lynch via use-livecode wrote:

I know the reviewers at app stores are not always careful, but
something like an LC player would surely get their notice.


Review, from my understanding, is heavily automated (it has to be - if 
you think of the scale of the App Stores these days). However, there is 
always a means to get in contact with a human about specific issues 
(which can take a while to get escalated with someone who can actually 
do something - but at least it is possible).



They do allow us to import JS, but JS is way more sandboxed than LC.


Yes - this is true - however, as I noticed this morning Apple no longer 
have their advisory about allowing arbitrary JS to be downloaded and run 
within a WebView. This is simply because you can could build a host app 
which gives access to every single OS
API on iOS and make all of them callable from JS (even if the JS bundled 
with the app does not use any of it).


So, the point is the language is not the point - what the code running 
in the language does is important.


Like Google, Apple are wanting to know precisely what OS APIs your app 
is calling at the point of review - so they have some idea of the 
surface area of attack for any malicious intent. How much analysis they 
currently do, no-one really knows - however the guidelines means that 
(in principal) they have reasons to pull any apps very quickly if they 
find that they are doing something which is 'not allowed'.


Warmest Regards,

Mark.

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

Re: Mobile LC Apps Downloading Stacks After installation

[Jonathan Lynch via use-livecode]

Thank you, Mark.

This was a great explanation.

I know the reviewers at app stores are not always careful, but something like 
an LC player would surely get their notice. 

They do allow us to import JS, but JS is way more sandboxed than LC.

Sent from my iPhone

> On Aug 11, 2017, at 3:55 AM, Mark Waddingham via use-livecode 
>  wrote:
> 
> 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 web

Re: Mobile LC Apps Downloading Stacks After installation

[Mark Waddingham via use-livecode]

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