On 2020-03-25 19:31, Pi Digital via use-livecode wrote:
In an app on the AppStore this is definitely a security risk from
Apple’s point of view. Devs could insert any nefarious code into their
app. This has been true from iOS2. Only content like video and
images, maybe some animation data and so on is deemed ok and
encouraged.
This was once very much the case for the iOS AppStore - as those of you
who were with us around 2010/11 will probably remember...
However now it isn't any longer true (I did post relatively recent about
the most recent app store agreements for both Google and Apple but I
couldn't find it when searching just now).
Essentially both Google and Apple's restrictions on what you can do in
terms of downloadable code are essentially the same these days in both.
Obviously both explicitly disallow any sort or malware or nefarious code
of *any* sort.
However, you are allowed to download code which runs in some sort of
interpreter - i.e. the binary/text being downloaded which you are going
to run is not in any way related to the actual instructions which run on
the local CPU (so classic interpreters are fine, as are JITs -
downloading machine code blobs is not).
However there are two rules which must be followed:
1) Downloaded code must not allow the app to access any more system
provided APIs that it could before.
2) Downloaded code must not allow the app to 'morph' (as Richard put
it) into something even slightly unrelated to what it was at the point
of review; nor should it add significantly different features
(particularly in terms of UI).
In practice conforming to (1) is easy - you aren't allowed to download
LCB extensions, loading them at runtime, which use FFI to access system
functions.
Conforming to (2) might sound like it is too fuzzy to really know what
you are allowed to do, but it isn't really. It is one of those cases
where if you really have to ask yourself whether the bit of script or
stack you want to download might be seen as extending the app
significantly or morphing the app into something other than what it was
when it was reviewed - then it probably is!
Some examples:
Additional game levels (which often have 'code' in them of some sort) in
the spirit of those already offered are fine; 'levels' which turn s
puzzle game into a first-person shooter probably are not; adding a
level-editor to your game probably would not be.
Additional music-related interactive content in a sheet music related
app would be fine; interactive recipe-related interactive content being
downloaded into a sheet music related app would probably not be fine;
adding the ability for a user to add and share comments with others on
the original content probably would not be.
Replacement business rules required to provide new and updated tax rules
in an accounting app would be fine; a module which turns an accounting
app into a point-of-sale system would probably not be fine.
These two rules are there for very different reasons.
Rule (1) is there so both Google and Apple 'know' the surface area of
attack on their OSes will not increase. Its important to remember that
OSes have bugs too, and bugs sometimes enable exploits - these always
come about due to bugs in system APIs enabling something to be done
which shouldn't be allowed.
Rule (2) is there for more social/business/marketing reasons - they
don't want consumers duped, they want to have some idea of what the app
is meant to be and they want to try to (at least minimally) provide a
reasonably cohesive 'store' environment.
At the end of the day, these two rules are really easy to keep within.
If you need to make substantial functional changes to your app then you
need to get it re-reviewed, but if you are merely extending what was
already there before in any sort of 'reasonable' way (particularly by
providing extra content incremental to what was there) then you will
have no problem at all.
Hope this helps!
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
