You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cordova.apache.org by Norman Breau <no...@normanbreau.com> on 2019/10/22 15:40:22 UTC
[DISCUSS] Deprecation of allowing remote urls in config's
This is an extension of the issue I raised for adding warnings to the
documentation which can be found at
https://github.com/apache/cordova-docs/issues/1022
In my opinion there are several reasons why using a remote url (such as
https://myserver.com/) to host a cordova app is bad practice.
1. If your app uses native APIs, you're breaking the terms of service of
the Apple and Google Play app stores. See Section 2.5.2 Software
Requirements of apples guidelines.[1]
2. Extending onto #1, it makes the app must more easier to become
vulnerable to exploits, because any other
third party code loaded onto the website may have access to the cordova
APIs.
3. Apple & Google expects your app to be able to launch and "work"
without a data connection. If your index file is
remote, then your app cannot load to provide the user proper feedback
that they require an internet connection. (See section 2.1 App
Completeness & 4.2 Minimum Functionality apple guidelines)[1].
4. Using a remote URL generally causes a lot of CORs related issues when
using non-standard protocols such as cdvfile:// (see
https://github.com/apache/cordova-plugin-file/issues/352)
5. Even if your app does not use native APIs, and it's just repackaging
a website, this goes against section 4.2 on apples policy[1].
I don't exactly know how popular using <content src="remoteurl" /> is,
but I do see it frequent enough on reported issues. This is kind of
frightening.
So given the reasons I listed above, I think allowing remote sources in
the <content> tag should be deprecated, and eventually removed in the
future, of course allowing time for developers to refactor their app to
bundle their code within the app.
Sources:
[1] https://developer.apple.com/app-store/review/guidelines/#design
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
For additional commands, e-mail: dev-help@cordova.apache.org
Re: [DISCUSS] Deprecation of allowing remote urls in config's
Posted by Jesse <pu...@gmail.com>.
Clarifying 1 thing.
PhoneGap apps have definitely been rejected under 2.5.2, but not because of
their use of <content src="remoteurl" />, in the case of the PhoneGap
Developer app it was because it could, and did load arbitrary other (user
entered) apps by url alone. Something Apple thinks of as an attempt to
create your own AppStore, even though it was strictly for development.
There are still many apps in the Apple app store that do this.
On Tue, Oct 22, 2019 at 11:26 AM Jesse <pu...@gmail.com> wrote:
> Yes, it can be risky in an app store, but to date, there have been no
> reports to cordova or phonegap of apps being rejected under this clause.
> Apple's goal, I believe, is primarily to stop the 'app store in an app'
> and apps that significantly change their behavior without going through the
> review process.
>
> The usage, and risks associated with remote usage of this configuration
> item should definitely be documented better.
>
> On Tue, Oct 22, 2019 at 11:15 AM Norman Breau <no...@normanbreau.com>
> wrote:
>
>> Yes, I've conceded on the proposal of limiting the behavior. You two
>> made some good points on why the behavior should be left alone.
>>
>> I've kind of adjusted my position to instead document how it's bad
>> practice to use remote URLs for index/sources because while allowing
>> remote code is still necessary for development, and in some cases
>> production apps, I still think generally speaking it is a practice that
>> should be generally avoided for any app intended to be distributed via
>> the google play or ios app store.
>>
>> Because the only time this is valid, TOS-wise, is if the app makes no
>> use of any of the cordova plugins or use any of the native APIs, in
>> otherwords, if the web app can be ran inside a standard browser as is.
>>
>> The intention here now is to at least have something documented so that
>> users can make better informed decisions on how to architect their
>> cordova app.
>>
>> On 2019-10-22 2:18 p.m., julio cesar sanchez wrote:
>> > I have not tested, but supposedly you can point to a local html error
>> file.
>> > Whenever a navigation error occurs, it should navigate to that local
>> page.
>> >
>> > <preference name="ErrorUrl" value="myErrorPage.html"/>
>> >
>> >
>> > Anyway, I see no point in limiting the content tag, people can still
>> > navigate to remote sites by using javascript as long as the remote url
>> is
>> > whitelisted with the appropriate allow-navigation tag. They just need a
>> > window.location = 'https://remoteurl.com';
>> >
>> >
>> > El mar., 22 oct. 2019 a las 18:56, Norman Breau (<
>> norman@normanbreau.com>)
>> > escribió:
>> >
>> >> There are some things I definitely disagree with in your list of
>> >> responses. I do think
>> >> the enterprise setup is enough of a reason to not add any kind of
>> >> deprecation notice as I originally proposed. So I concede on the idea
>> of
>> >> deprecating this usage of the feature.
>> >>
>> >> I however do still think, a note on this should be documented in the
>> >> config.xml docs as I think many users are not building enterprise apps,
>> >> but still use remote urls for production apps.
>> >>
>> >> #1 is definitely TOS breaking. Code from a remote source must not be a
>> >> requirement for the app, read: "Apps may contain or run code that is
>> not
>> >> embedded in the binary (e.g. HTML5-based games, bots, etc.), as long as
>> >> code distribution isn’t the main purpose of the app"
>> >>
>> >> Code that isn't bundled with the app can only use capabilities
>> available
>> >> in the standard webkit view. Read "(2) only uses capabilities available
>> >> in a standard WebKit view (e.g. it must open and run natively in Safari
>> >> without modifications or additional software)". Google Play also has
>> >> similar text in their policies.
>> >>
>> >> I also fail to understand how a developer can use a remote html page
>> for
>> >> their app index page and still avoid a blank page due to the device not
>> >> having a data connection.
>> >>
>> >> So for these reasons, I think it still should be documented as bad
>> >> practice for production apps at the very least. Of course, it can made
>> >> clear that this note only applies to apps intended to be distributed to
>> >> the app stores.
>> >>
>> >> On 2019-10-22 1:24 p.m., Jesse wrote:
>> >>> Also, please keep in mind that there are other ways to distribute
>> apps.
>> >>> A company/developer with an enterprise license can build apps for
>> >>> company/employee use and distribute them as they see fit.
>> >>>
>> >>>
>> >>> On Tue, Oct 22, 2019 at 9:20 AM Jesse <pu...@gmail.com>
>> wrote:
>> >>>
>> >>>> This is a crucial feature for development tools, and a valid
>> production
>> >>>> use case.
>> >>>>
>> >>>> 1. This is NOT breaking TOS with Apple, unless the developer decides
>> to
>> >>>> significantly change their app, which is bad practice anyway.
>> >>>> 2. Care should be taken in what you deliver to your app, this is not
>> >>>> cordova's concern.
>> >>>> 3. Apps should provide 'some' offline experience, and not show a 404
>> of
>> >>>> course, but that is up to the developer.
>> >>>> 4. Yes, developers should be aware of this.
>> >>>> 5. This is not 'repacking a website' you are missing the point, this
>> is:
>> >>>> 'making a purpose built web-app that you can make minor tweaks to
>> >> without
>> >>>> having to submit to app stores repeatedly, and to do some heavy
>> lifting
>> >> on
>> >>>> the server.' Some notable apps that are examples of this: Amazon,
>> >> Walmart,
>> >>>> Apple Music, Apple App Store, ...
>> >>>>
>> >>>>
>> >>>>
>> >>>>
>> >>>> On Tue, Oct 22, 2019 at 9:05 AM julio cesar sanchez <
>> >>>> jcesarmobile@gmail.com> wrote:
>> >>>>
>> >>>>> The content tag is also used for pointing to local development
>> servers
>> >> and
>> >>>>> benefit from live reloading, so how do you plan to deprecate it only
>> >> for
>> >>>>> remote urls?
>> >>>>>
>> >>>>> El mar., 22 oct. 2019 a las 17:46, Norman Breau (<
>> >> norman@normanbreau.com
>> >>>>>> )
>> >>>>> escribió:
>> >>>>>
>> >>>>>> This is an extension of the issue I raised for adding warnings to
>> the
>> >>>>>> documentation which can be found at
>> >>>>>> https://github.com/apache/cordova-docs/issues/1022
>> >>>>>>
>> >>>>>> In my opinion there are several reasons why using a remote url
>> (such
>> >> as
>> >>>>>> https://myserver.com/) to host a cordova app is bad practice.
>> >>>>>>
>> >>>>>> 1. If your app uses native APIs, you're breaking the terms of
>> service
>> >> of
>> >>>>>> the Apple and Google Play app stores. See Section 2.5.2 Software
>> >>>>>> Requirements of apples guidelines.[1]
>> >>>>>>
>> >>>>>> 2. Extending onto #1, it makes the app must more easier to become
>> >>>>>> vulnerable to exploits, because any other
>> >>>>>> third party code loaded onto the website may have access to the
>> >> cordova
>> >>>>>> APIs.
>> >>>>>>
>> >>>>>> 3. Apple & Google expects your app to be able to launch and "work"
>> >>>>>> without a data connection. If your index file is
>> >>>>>> remote, then your app cannot load to provide the user proper
>> feedback
>> >>>>>> that they require an internet connection. (See section 2.1 App
>> >>>>>> Completeness & 4.2 Minimum Functionality apple guidelines)[1].
>> >>>>>>
>> >>>>>> 4. Using a remote URL generally causes a lot of CORs related issues
>> >> when
>> >>>>>> using non-standard protocols such as cdvfile:// (see
>> >>>>>> https://github.com/apache/cordova-plugin-file/issues/352)
>> >>>>>>
>> >>>>>> 5. Even if your app does not use native APIs, and it's just
>> >> repackaging
>> >>>>>> a website, this goes against section 4.2 on apples policy[1].
>> >>>>>>
>> >>>>>> I don't exactly know how popular using <content src="remoteurl" />
>> is,
>> >>>>>> but I do see it frequent enough on reported issues. This is kind of
>> >>>>>> frightening.
>> >>>>>>
>> >>>>>> So given the reasons I listed above, I think allowing remote
>> sources
>> >> in
>> >>>>>> the <content> tag should be deprecated, and eventually removed in
>> the
>> >>>>>> future, of course allowing time for developers to refactor their
>> app
>> >> to
>> >>>>>> bundle their code within the app.
>> >>>>>>
>> >>>>>> Sources:
>> >>>>>> [1]
>> https://developer.apple.com/app-store/review/guidelines/#design
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> ---------------------------------------------------------------------
>> >>>>>> To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
>> >>>>>> For additional commands, e-mail: dev-help@cordova.apache.org
>> >>>>>>
>> >>>>>>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
>> >> For additional commands, e-mail: dev-help@cordova.apache.org
>> >>
>> >>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
>> For additional commands, e-mail: dev-help@cordova.apache.org
>>
>>
Re: [DISCUSS] Deprecation of allowing remote urls in config's
Posted by Jesse <pu...@gmail.com>.
Yes, it can be risky in an app store, but to date, there have been no
reports to cordova or phonegap of apps being rejected under this clause.
Apple's goal, I believe, is primarily to stop the 'app store in an app' and
apps that significantly change their behavior without going through the
review process.
The usage, and risks associated with remote usage of this configuration
item should definitely be documented better.
On Tue, Oct 22, 2019 at 11:15 AM Norman Breau <no...@normanbreau.com>
wrote:
> Yes, I've conceded on the proposal of limiting the behavior. You two
> made some good points on why the behavior should be left alone.
>
> I've kind of adjusted my position to instead document how it's bad
> practice to use remote URLs for index/sources because while allowing
> remote code is still necessary for development, and in some cases
> production apps, I still think generally speaking it is a practice that
> should be generally avoided for any app intended to be distributed via
> the google play or ios app store.
>
> Because the only time this is valid, TOS-wise, is if the app makes no
> use of any of the cordova plugins or use any of the native APIs, in
> otherwords, if the web app can be ran inside a standard browser as is.
>
> The intention here now is to at least have something documented so that
> users can make better informed decisions on how to architect their
> cordova app.
>
> On 2019-10-22 2:18 p.m., julio cesar sanchez wrote:
> > I have not tested, but supposedly you can point to a local html error
> file.
> > Whenever a navigation error occurs, it should navigate to that local
> page.
> >
> > <preference name="ErrorUrl" value="myErrorPage.html"/>
> >
> >
> > Anyway, I see no point in limiting the content tag, people can still
> > navigate to remote sites by using javascript as long as the remote url is
> > whitelisted with the appropriate allow-navigation tag. They just need a
> > window.location = 'https://remoteurl.com';
> >
> >
> > El mar., 22 oct. 2019 a las 18:56, Norman Breau (<norman@normanbreau.com
> >)
> > escribió:
> >
> >> There are some things I definitely disagree with in your list of
> >> responses. I do think
> >> the enterprise setup is enough of a reason to not add any kind of
> >> deprecation notice as I originally proposed. So I concede on the idea of
> >> deprecating this usage of the feature.
> >>
> >> I however do still think, a note on this should be documented in the
> >> config.xml docs as I think many users are not building enterprise apps,
> >> but still use remote urls for production apps.
> >>
> >> #1 is definitely TOS breaking. Code from a remote source must not be a
> >> requirement for the app, read: "Apps may contain or run code that is not
> >> embedded in the binary (e.g. HTML5-based games, bots, etc.), as long as
> >> code distribution isn’t the main purpose of the app"
> >>
> >> Code that isn't bundled with the app can only use capabilities available
> >> in the standard webkit view. Read "(2) only uses capabilities available
> >> in a standard WebKit view (e.g. it must open and run natively in Safari
> >> without modifications or additional software)". Google Play also has
> >> similar text in their policies.
> >>
> >> I also fail to understand how a developer can use a remote html page for
> >> their app index page and still avoid a blank page due to the device not
> >> having a data connection.
> >>
> >> So for these reasons, I think it still should be documented as bad
> >> practice for production apps at the very least. Of course, it can made
> >> clear that this note only applies to apps intended to be distributed to
> >> the app stores.
> >>
> >> On 2019-10-22 1:24 p.m., Jesse wrote:
> >>> Also, please keep in mind that there are other ways to distribute apps.
> >>> A company/developer with an enterprise license can build apps for
> >>> company/employee use and distribute them as they see fit.
> >>>
> >>>
> >>> On Tue, Oct 22, 2019 at 9:20 AM Jesse <pu...@gmail.com> wrote:
> >>>
> >>>> This is a crucial feature for development tools, and a valid
> production
> >>>> use case.
> >>>>
> >>>> 1. This is NOT breaking TOS with Apple, unless the developer decides
> to
> >>>> significantly change their app, which is bad practice anyway.
> >>>> 2. Care should be taken in what you deliver to your app, this is not
> >>>> cordova's concern.
> >>>> 3. Apps should provide 'some' offline experience, and not show a 404
> of
> >>>> course, but that is up to the developer.
> >>>> 4. Yes, developers should be aware of this.
> >>>> 5. This is not 'repacking a website' you are missing the point, this
> is:
> >>>> 'making a purpose built web-app that you can make minor tweaks to
> >> without
> >>>> having to submit to app stores repeatedly, and to do some heavy
> lifting
> >> on
> >>>> the server.' Some notable apps that are examples of this: Amazon,
> >> Walmart,
> >>>> Apple Music, Apple App Store, ...
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> On Tue, Oct 22, 2019 at 9:05 AM julio cesar sanchez <
> >>>> jcesarmobile@gmail.com> wrote:
> >>>>
> >>>>> The content tag is also used for pointing to local development
> servers
> >> and
> >>>>> benefit from live reloading, so how do you plan to deprecate it only
> >> for
> >>>>> remote urls?
> >>>>>
> >>>>> El mar., 22 oct. 2019 a las 17:46, Norman Breau (<
> >> norman@normanbreau.com
> >>>>>> )
> >>>>> escribió:
> >>>>>
> >>>>>> This is an extension of the issue I raised for adding warnings to
> the
> >>>>>> documentation which can be found at
> >>>>>> https://github.com/apache/cordova-docs/issues/1022
> >>>>>>
> >>>>>> In my opinion there are several reasons why using a remote url (such
> >> as
> >>>>>> https://myserver.com/) to host a cordova app is bad practice.
> >>>>>>
> >>>>>> 1. If your app uses native APIs, you're breaking the terms of
> service
> >> of
> >>>>>> the Apple and Google Play app stores. See Section 2.5.2 Software
> >>>>>> Requirements of apples guidelines.[1]
> >>>>>>
> >>>>>> 2. Extending onto #1, it makes the app must more easier to become
> >>>>>> vulnerable to exploits, because any other
> >>>>>> third party code loaded onto the website may have access to the
> >> cordova
> >>>>>> APIs.
> >>>>>>
> >>>>>> 3. Apple & Google expects your app to be able to launch and "work"
> >>>>>> without a data connection. If your index file is
> >>>>>> remote, then your app cannot load to provide the user proper
> feedback
> >>>>>> that they require an internet connection. (See section 2.1 App
> >>>>>> Completeness & 4.2 Minimum Functionality apple guidelines)[1].
> >>>>>>
> >>>>>> 4. Using a remote URL generally causes a lot of CORs related issues
> >> when
> >>>>>> using non-standard protocols such as cdvfile:// (see
> >>>>>> https://github.com/apache/cordova-plugin-file/issues/352)
> >>>>>>
> >>>>>> 5. Even if your app does not use native APIs, and it's just
> >> repackaging
> >>>>>> a website, this goes against section 4.2 on apples policy[1].
> >>>>>>
> >>>>>> I don't exactly know how popular using <content src="remoteurl" />
> is,
> >>>>>> but I do see it frequent enough on reported issues. This is kind of
> >>>>>> frightening.
> >>>>>>
> >>>>>> So given the reasons I listed above, I think allowing remote sources
> >> in
> >>>>>> the <content> tag should be deprecated, and eventually removed in
> the
> >>>>>> future, of course allowing time for developers to refactor their app
> >> to
> >>>>>> bundle their code within the app.
> >>>>>>
> >>>>>> Sources:
> >>>>>> [1] https://developer.apple.com/app-store/review/guidelines/#design
> >>>>>>
> >>>>>>
> >>>>>>
> ---------------------------------------------------------------------
> >>>>>> To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> >>>>>> For additional commands, e-mail: dev-help@cordova.apache.org
> >>>>>>
> >>>>>>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> >> For additional commands, e-mail: dev-help@cordova.apache.org
> >>
> >>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> For additional commands, e-mail: dev-help@cordova.apache.org
>
>
Re: [DISCUSS] Deprecation of allowing remote urls in config's
Posted by Norman Breau <no...@normanbreau.com>.
Yes, I've conceded on the proposal of limiting the behavior. You two
made some good points on why the behavior should be left alone.
I've kind of adjusted my position to instead document how it's bad
practice to use remote URLs for index/sources because while allowing
remote code is still necessary for development, and in some cases
production apps, I still think generally speaking it is a practice that
should be generally avoided for any app intended to be distributed via
the google play or ios app store.
Because the only time this is valid, TOS-wise, is if the app makes no
use of any of the cordova plugins or use any of the native APIs, in
otherwords, if the web app can be ran inside a standard browser as is.
The intention here now is to at least have something documented so that
users can make better informed decisions on how to architect their
cordova app.
On 2019-10-22 2:18 p.m., julio cesar sanchez wrote:
> I have not tested, but supposedly you can point to a local html error file.
> Whenever a navigation error occurs, it should navigate to that local page.
>
> <preference name="ErrorUrl" value="myErrorPage.html"/>
>
>
> Anyway, I see no point in limiting the content tag, people can still
> navigate to remote sites by using javascript as long as the remote url is
> whitelisted with the appropriate allow-navigation tag. They just need a
> window.location = 'https://remoteurl.com';
>
>
> El mar., 22 oct. 2019 a las 18:56, Norman Breau (<no...@normanbreau.com>)
> escribió:
>
>> There are some things I definitely disagree with in your list of
>> responses. I do think
>> the enterprise setup is enough of a reason to not add any kind of
>> deprecation notice as I originally proposed. So I concede on the idea of
>> deprecating this usage of the feature.
>>
>> I however do still think, a note on this should be documented in the
>> config.xml docs as I think many users are not building enterprise apps,
>> but still use remote urls for production apps.
>>
>> #1 is definitely TOS breaking. Code from a remote source must not be a
>> requirement for the app, read: "Apps may contain or run code that is not
>> embedded in the binary (e.g. HTML5-based games, bots, etc.), as long as
>> code distribution isn’t the main purpose of the app"
>>
>> Code that isn't bundled with the app can only use capabilities available
>> in the standard webkit view. Read "(2) only uses capabilities available
>> in a standard WebKit view (e.g. it must open and run natively in Safari
>> without modifications or additional software)". Google Play also has
>> similar text in their policies.
>>
>> I also fail to understand how a developer can use a remote html page for
>> their app index page and still avoid a blank page due to the device not
>> having a data connection.
>>
>> So for these reasons, I think it still should be documented as bad
>> practice for production apps at the very least. Of course, it can made
>> clear that this note only applies to apps intended to be distributed to
>> the app stores.
>>
>> On 2019-10-22 1:24 p.m., Jesse wrote:
>>> Also, please keep in mind that there are other ways to distribute apps.
>>> A company/developer with an enterprise license can build apps for
>>> company/employee use and distribute them as they see fit.
>>>
>>>
>>> On Tue, Oct 22, 2019 at 9:20 AM Jesse <pu...@gmail.com> wrote:
>>>
>>>> This is a crucial feature for development tools, and a valid production
>>>> use case.
>>>>
>>>> 1. This is NOT breaking TOS with Apple, unless the developer decides to
>>>> significantly change their app, which is bad practice anyway.
>>>> 2. Care should be taken in what you deliver to your app, this is not
>>>> cordova's concern.
>>>> 3. Apps should provide 'some' offline experience, and not show a 404 of
>>>> course, but that is up to the developer.
>>>> 4. Yes, developers should be aware of this.
>>>> 5. This is not 'repacking a website' you are missing the point, this is:
>>>> 'making a purpose built web-app that you can make minor tweaks to
>> without
>>>> having to submit to app stores repeatedly, and to do some heavy lifting
>> on
>>>> the server.' Some notable apps that are examples of this: Amazon,
>> Walmart,
>>>> Apple Music, Apple App Store, ...
>>>>
>>>>
>>>>
>>>>
>>>> On Tue, Oct 22, 2019 at 9:05 AM julio cesar sanchez <
>>>> jcesarmobile@gmail.com> wrote:
>>>>
>>>>> The content tag is also used for pointing to local development servers
>> and
>>>>> benefit from live reloading, so how do you plan to deprecate it only
>> for
>>>>> remote urls?
>>>>>
>>>>> El mar., 22 oct. 2019 a las 17:46, Norman Breau (<
>> norman@normanbreau.com
>>>>>> )
>>>>> escribió:
>>>>>
>>>>>> This is an extension of the issue I raised for adding warnings to the
>>>>>> documentation which can be found at
>>>>>> https://github.com/apache/cordova-docs/issues/1022
>>>>>>
>>>>>> In my opinion there are several reasons why using a remote url (such
>> as
>>>>>> https://myserver.com/) to host a cordova app is bad practice.
>>>>>>
>>>>>> 1. If your app uses native APIs, you're breaking the terms of service
>> of
>>>>>> the Apple and Google Play app stores. See Section 2.5.2 Software
>>>>>> Requirements of apples guidelines.[1]
>>>>>>
>>>>>> 2. Extending onto #1, it makes the app must more easier to become
>>>>>> vulnerable to exploits, because any other
>>>>>> third party code loaded onto the website may have access to the
>> cordova
>>>>>> APIs.
>>>>>>
>>>>>> 3. Apple & Google expects your app to be able to launch and "work"
>>>>>> without a data connection. If your index file is
>>>>>> remote, then your app cannot load to provide the user proper feedback
>>>>>> that they require an internet connection. (See section 2.1 App
>>>>>> Completeness & 4.2 Minimum Functionality apple guidelines)[1].
>>>>>>
>>>>>> 4. Using a remote URL generally causes a lot of CORs related issues
>> when
>>>>>> using non-standard protocols such as cdvfile:// (see
>>>>>> https://github.com/apache/cordova-plugin-file/issues/352)
>>>>>>
>>>>>> 5. Even if your app does not use native APIs, and it's just
>> repackaging
>>>>>> a website, this goes against section 4.2 on apples policy[1].
>>>>>>
>>>>>> I don't exactly know how popular using <content src="remoteurl" /> is,
>>>>>> but I do see it frequent enough on reported issues. This is kind of
>>>>>> frightening.
>>>>>>
>>>>>> So given the reasons I listed above, I think allowing remote sources
>> in
>>>>>> the <content> tag should be deprecated, and eventually removed in the
>>>>>> future, of course allowing time for developers to refactor their app
>> to
>>>>>> bundle their code within the app.
>>>>>>
>>>>>> Sources:
>>>>>> [1] https://developer.apple.com/app-store/review/guidelines/#design
>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
>>>>>> For additional commands, e-mail: dev-help@cordova.apache.org
>>>>>>
>>>>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
>> For additional commands, e-mail: dev-help@cordova.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
For additional commands, e-mail: dev-help@cordova.apache.org
Re: [DISCUSS] Deprecation of allowing remote urls in config's
Posted by julio cesar sanchez <jc...@gmail.com>.
I have not tested, but supposedly you can point to a local html error file.
Whenever a navigation error occurs, it should navigate to that local page.
<preference name="ErrorUrl" value="myErrorPage.html"/>
Anyway, I see no point in limiting the content tag, people can still
navigate to remote sites by using javascript as long as the remote url is
whitelisted with the appropriate allow-navigation tag. They just need a
window.location = 'https://remoteurl.com';
El mar., 22 oct. 2019 a las 18:56, Norman Breau (<no...@normanbreau.com>)
escribió:
> There are some things I definitely disagree with in your list of
> responses. I do think
> the enterprise setup is enough of a reason to not add any kind of
> deprecation notice as I originally proposed. So I concede on the idea of
> deprecating this usage of the feature.
>
> I however do still think, a note on this should be documented in the
> config.xml docs as I think many users are not building enterprise apps,
> but still use remote urls for production apps.
>
> #1 is definitely TOS breaking. Code from a remote source must not be a
> requirement for the app, read: "Apps may contain or run code that is not
> embedded in the binary (e.g. HTML5-based games, bots, etc.), as long as
> code distribution isn’t the main purpose of the app"
>
> Code that isn't bundled with the app can only use capabilities available
> in the standard webkit view. Read "(2) only uses capabilities available
> in a standard WebKit view (e.g. it must open and run natively in Safari
> without modifications or additional software)". Google Play also has
> similar text in their policies.
>
> I also fail to understand how a developer can use a remote html page for
> their app index page and still avoid a blank page due to the device not
> having a data connection.
>
> So for these reasons, I think it still should be documented as bad
> practice for production apps at the very least. Of course, it can made
> clear that this note only applies to apps intended to be distributed to
> the app stores.
>
> On 2019-10-22 1:24 p.m., Jesse wrote:
> > Also, please keep in mind that there are other ways to distribute apps.
> > A company/developer with an enterprise license can build apps for
> > company/employee use and distribute them as they see fit.
> >
> >
> > On Tue, Oct 22, 2019 at 9:20 AM Jesse <pu...@gmail.com> wrote:
> >
> >> This is a crucial feature for development tools, and a valid production
> >> use case.
> >>
> >> 1. This is NOT breaking TOS with Apple, unless the developer decides to
> >> significantly change their app, which is bad practice anyway.
> >> 2. Care should be taken in what you deliver to your app, this is not
> >> cordova's concern.
> >> 3. Apps should provide 'some' offline experience, and not show a 404 of
> >> course, but that is up to the developer.
> >> 4. Yes, developers should be aware of this.
> >> 5. This is not 'repacking a website' you are missing the point, this is:
> >> 'making a purpose built web-app that you can make minor tweaks to
> without
> >> having to submit to app stores repeatedly, and to do some heavy lifting
> on
> >> the server.' Some notable apps that are examples of this: Amazon,
> Walmart,
> >> Apple Music, Apple App Store, ...
> >>
> >>
> >>
> >>
> >> On Tue, Oct 22, 2019 at 9:05 AM julio cesar sanchez <
> >> jcesarmobile@gmail.com> wrote:
> >>
> >>> The content tag is also used for pointing to local development servers
> and
> >>> benefit from live reloading, so how do you plan to deprecate it only
> for
> >>> remote urls?
> >>>
> >>> El mar., 22 oct. 2019 a las 17:46, Norman Breau (<
> norman@normanbreau.com
> >>>> )
> >>> escribió:
> >>>
> >>>> This is an extension of the issue I raised for adding warnings to the
> >>>> documentation which can be found at
> >>>> https://github.com/apache/cordova-docs/issues/1022
> >>>>
> >>>> In my opinion there are several reasons why using a remote url (such
> as
> >>>> https://myserver.com/) to host a cordova app is bad practice.
> >>>>
> >>>> 1. If your app uses native APIs, you're breaking the terms of service
> of
> >>>> the Apple and Google Play app stores. See Section 2.5.2 Software
> >>>> Requirements of apples guidelines.[1]
> >>>>
> >>>> 2. Extending onto #1, it makes the app must more easier to become
> >>>> vulnerable to exploits, because any other
> >>>> third party code loaded onto the website may have access to the
> cordova
> >>>> APIs.
> >>>>
> >>>> 3. Apple & Google expects your app to be able to launch and "work"
> >>>> without a data connection. If your index file is
> >>>> remote, then your app cannot load to provide the user proper feedback
> >>>> that they require an internet connection. (See section 2.1 App
> >>>> Completeness & 4.2 Minimum Functionality apple guidelines)[1].
> >>>>
> >>>> 4. Using a remote URL generally causes a lot of CORs related issues
> when
> >>>> using non-standard protocols such as cdvfile:// (see
> >>>> https://github.com/apache/cordova-plugin-file/issues/352)
> >>>>
> >>>> 5. Even if your app does not use native APIs, and it's just
> repackaging
> >>>> a website, this goes against section 4.2 on apples policy[1].
> >>>>
> >>>> I don't exactly know how popular using <content src="remoteurl" /> is,
> >>>> but I do see it frequent enough on reported issues. This is kind of
> >>>> frightening.
> >>>>
> >>>> So given the reasons I listed above, I think allowing remote sources
> in
> >>>> the <content> tag should be deprecated, and eventually removed in the
> >>>> future, of course allowing time for developers to refactor their app
> to
> >>>> bundle their code within the app.
> >>>>
> >>>> Sources:
> >>>> [1] https://developer.apple.com/app-store/review/guidelines/#design
> >>>>
> >>>>
> >>>> ---------------------------------------------------------------------
> >>>> To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> >>>> For additional commands, e-mail: dev-help@cordova.apache.org
> >>>>
> >>>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> For additional commands, e-mail: dev-help@cordova.apache.org
>
>
Re: [DISCUSS] Deprecation of allowing remote urls in config's
Posted by Norman Breau <no...@normanbreau.com>.
There are some things I definitely disagree with in your list of
responses. I do think
the enterprise setup is enough of a reason to not add any kind of
deprecation notice as I originally proposed. So I concede on the idea of
deprecating this usage of the feature.
I however do still think, a note on this should be documented in the
config.xml docs as I think many users are not building enterprise apps,
but still use remote urls for production apps.
#1 is definitely TOS breaking. Code from a remote source must not be a
requirement for the app, read: "Apps may contain or run code that is not
embedded in the binary (e.g. HTML5-based games, bots, etc.), as long as
code distribution isn’t the main purpose of the app"
Code that isn't bundled with the app can only use capabilities available
in the standard webkit view. Read "(2) only uses capabilities available
in a standard WebKit view (e.g. it must open and run natively in Safari
without modifications or additional software)". Google Play also has
similar text in their policies.
I also fail to understand how a developer can use a remote html page for
their app index page and still avoid a blank page due to the device not
having a data connection.
So for these reasons, I think it still should be documented as bad
practice for production apps at the very least. Of course, it can made
clear that this note only applies to apps intended to be distributed to
the app stores.
On 2019-10-22 1:24 p.m., Jesse wrote:
> Also, please keep in mind that there are other ways to distribute apps.
> A company/developer with an enterprise license can build apps for
> company/employee use and distribute them as they see fit.
>
>
> On Tue, Oct 22, 2019 at 9:20 AM Jesse <pu...@gmail.com> wrote:
>
>> This is a crucial feature for development tools, and a valid production
>> use case.
>>
>> 1. This is NOT breaking TOS with Apple, unless the developer decides to
>> significantly change their app, which is bad practice anyway.
>> 2. Care should be taken in what you deliver to your app, this is not
>> cordova's concern.
>> 3. Apps should provide 'some' offline experience, and not show a 404 of
>> course, but that is up to the developer.
>> 4. Yes, developers should be aware of this.
>> 5. This is not 'repacking a website' you are missing the point, this is:
>> 'making a purpose built web-app that you can make minor tweaks to without
>> having to submit to app stores repeatedly, and to do some heavy lifting on
>> the server.' Some notable apps that are examples of this: Amazon, Walmart,
>> Apple Music, Apple App Store, ...
>>
>>
>>
>>
>> On Tue, Oct 22, 2019 at 9:05 AM julio cesar sanchez <
>> jcesarmobile@gmail.com> wrote:
>>
>>> The content tag is also used for pointing to local development servers and
>>> benefit from live reloading, so how do you plan to deprecate it only for
>>> remote urls?
>>>
>>> El mar., 22 oct. 2019 a las 17:46, Norman Breau (<norman@normanbreau.com
>>>> )
>>> escribió:
>>>
>>>> This is an extension of the issue I raised for adding warnings to the
>>>> documentation which can be found at
>>>> https://github.com/apache/cordova-docs/issues/1022
>>>>
>>>> In my opinion there are several reasons why using a remote url (such as
>>>> https://myserver.com/) to host a cordova app is bad practice.
>>>>
>>>> 1. If your app uses native APIs, you're breaking the terms of service of
>>>> the Apple and Google Play app stores. See Section 2.5.2 Software
>>>> Requirements of apples guidelines.[1]
>>>>
>>>> 2. Extending onto #1, it makes the app must more easier to become
>>>> vulnerable to exploits, because any other
>>>> third party code loaded onto the website may have access to the cordova
>>>> APIs.
>>>>
>>>> 3. Apple & Google expects your app to be able to launch and "work"
>>>> without a data connection. If your index file is
>>>> remote, then your app cannot load to provide the user proper feedback
>>>> that they require an internet connection. (See section 2.1 App
>>>> Completeness & 4.2 Minimum Functionality apple guidelines)[1].
>>>>
>>>> 4. Using a remote URL generally causes a lot of CORs related issues when
>>>> using non-standard protocols such as cdvfile:// (see
>>>> https://github.com/apache/cordova-plugin-file/issues/352)
>>>>
>>>> 5. Even if your app does not use native APIs, and it's just repackaging
>>>> a website, this goes against section 4.2 on apples policy[1].
>>>>
>>>> I don't exactly know how popular using <content src="remoteurl" /> is,
>>>> but I do see it frequent enough on reported issues. This is kind of
>>>> frightening.
>>>>
>>>> So given the reasons I listed above, I think allowing remote sources in
>>>> the <content> tag should be deprecated, and eventually removed in the
>>>> future, of course allowing time for developers to refactor their app to
>>>> bundle their code within the app.
>>>>
>>>> Sources:
>>>> [1] https://developer.apple.com/app-store/review/guidelines/#design
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
>>>> For additional commands, e-mail: dev-help@cordova.apache.org
>>>>
>>>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
For additional commands, e-mail: dev-help@cordova.apache.org
Re: [DISCUSS] Deprecation of allowing remote urls in config's
Posted by Jesse <pu...@gmail.com>.
Also, please keep in mind that there are other ways to distribute apps.
A company/developer with an enterprise license can build apps for
company/employee use and distribute them as they see fit.
On Tue, Oct 22, 2019 at 9:20 AM Jesse <pu...@gmail.com> wrote:
> This is a crucial feature for development tools, and a valid production
> use case.
>
> 1. This is NOT breaking TOS with Apple, unless the developer decides to
> significantly change their app, which is bad practice anyway.
> 2. Care should be taken in what you deliver to your app, this is not
> cordova's concern.
> 3. Apps should provide 'some' offline experience, and not show a 404 of
> course, but that is up to the developer.
> 4. Yes, developers should be aware of this.
> 5. This is not 'repacking a website' you are missing the point, this is:
> 'making a purpose built web-app that you can make minor tweaks to without
> having to submit to app stores repeatedly, and to do some heavy lifting on
> the server.' Some notable apps that are examples of this: Amazon, Walmart,
> Apple Music, Apple App Store, ...
>
>
>
>
> On Tue, Oct 22, 2019 at 9:05 AM julio cesar sanchez <
> jcesarmobile@gmail.com> wrote:
>
>> The content tag is also used for pointing to local development servers and
>> benefit from live reloading, so how do you plan to deprecate it only for
>> remote urls?
>>
>> El mar., 22 oct. 2019 a las 17:46, Norman Breau (<norman@normanbreau.com
>> >)
>> escribió:
>>
>> > This is an extension of the issue I raised for adding warnings to the
>> > documentation which can be found at
>> > https://github.com/apache/cordova-docs/issues/1022
>> >
>> > In my opinion there are several reasons why using a remote url (such as
>> > https://myserver.com/) to host a cordova app is bad practice.
>> >
>> > 1. If your app uses native APIs, you're breaking the terms of service of
>> > the Apple and Google Play app stores. See Section 2.5.2 Software
>> > Requirements of apples guidelines.[1]
>> >
>> > 2. Extending onto #1, it makes the app must more easier to become
>> > vulnerable to exploits, because any other
>> > third party code loaded onto the website may have access to the cordova
>> > APIs.
>> >
>> > 3. Apple & Google expects your app to be able to launch and "work"
>> > without a data connection. If your index file is
>> > remote, then your app cannot load to provide the user proper feedback
>> > that they require an internet connection. (See section 2.1 App
>> > Completeness & 4.2 Minimum Functionality apple guidelines)[1].
>> >
>> > 4. Using a remote URL generally causes a lot of CORs related issues when
>> > using non-standard protocols such as cdvfile:// (see
>> > https://github.com/apache/cordova-plugin-file/issues/352)
>> >
>> > 5. Even if your app does not use native APIs, and it's just repackaging
>> > a website, this goes against section 4.2 on apples policy[1].
>> >
>> > I don't exactly know how popular using <content src="remoteurl" /> is,
>> > but I do see it frequent enough on reported issues. This is kind of
>> > frightening.
>> >
>> > So given the reasons I listed above, I think allowing remote sources in
>> > the <content> tag should be deprecated, and eventually removed in the
>> > future, of course allowing time for developers to refactor their app to
>> > bundle their code within the app.
>> >
>> > Sources:
>> > [1] https://developer.apple.com/app-store/review/guidelines/#design
>> >
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
>> > For additional commands, e-mail: dev-help@cordova.apache.org
>> >
>> >
>>
>
Re: [DISCUSS] Deprecation of allowing remote urls in config's
Posted by Jesse <pu...@gmail.com>.
This is a crucial feature for development tools, and a valid production use
case.
1. This is NOT breaking TOS with Apple, unless the developer decides to
significantly change their app, which is bad practice anyway.
2. Care should be taken in what you deliver to your app, this is not
cordova's concern.
3. Apps should provide 'some' offline experience, and not show a 404 of
course, but that is up to the developer.
4. Yes, developers should be aware of this.
5. This is not 'repacking a website' you are missing the point, this is:
'making a purpose built web-app that you can make minor tweaks to without
having to submit to app stores repeatedly, and to do some heavy lifting on
the server.' Some notable apps that are examples of this: Amazon, Walmart,
Apple Music, Apple App Store, ...
On Tue, Oct 22, 2019 at 9:05 AM julio cesar sanchez <jc...@gmail.com>
wrote:
> The content tag is also used for pointing to local development servers and
> benefit from live reloading, so how do you plan to deprecate it only for
> remote urls?
>
> El mar., 22 oct. 2019 a las 17:46, Norman Breau (<no...@normanbreau.com>)
> escribió:
>
> > This is an extension of the issue I raised for adding warnings to the
> > documentation which can be found at
> > https://github.com/apache/cordova-docs/issues/1022
> >
> > In my opinion there are several reasons why using a remote url (such as
> > https://myserver.com/) to host a cordova app is bad practice.
> >
> > 1. If your app uses native APIs, you're breaking the terms of service of
> > the Apple and Google Play app stores. See Section 2.5.2 Software
> > Requirements of apples guidelines.[1]
> >
> > 2. Extending onto #1, it makes the app must more easier to become
> > vulnerable to exploits, because any other
> > third party code loaded onto the website may have access to the cordova
> > APIs.
> >
> > 3. Apple & Google expects your app to be able to launch and "work"
> > without a data connection. If your index file is
> > remote, then your app cannot load to provide the user proper feedback
> > that they require an internet connection. (See section 2.1 App
> > Completeness & 4.2 Minimum Functionality apple guidelines)[1].
> >
> > 4. Using a remote URL generally causes a lot of CORs related issues when
> > using non-standard protocols such as cdvfile:// (see
> > https://github.com/apache/cordova-plugin-file/issues/352)
> >
> > 5. Even if your app does not use native APIs, and it's just repackaging
> > a website, this goes against section 4.2 on apples policy[1].
> >
> > I don't exactly know how popular using <content src="remoteurl" /> is,
> > but I do see it frequent enough on reported issues. This is kind of
> > frightening.
> >
> > So given the reasons I listed above, I think allowing remote sources in
> > the <content> tag should be deprecated, and eventually removed in the
> > future, of course allowing time for developers to refactor their app to
> > bundle their code within the app.
> >
> > Sources:
> > [1] https://developer.apple.com/app-store/review/guidelines/#design
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> > For additional commands, e-mail: dev-help@cordova.apache.org
> >
> >
>
Re: [DISCUSS] Deprecation of allowing remote urls in config's
Posted by Norman Breau <no...@normanbreau.com>.
Good point julio. Local development for live reloading is a valid reason
to use remote urls. I still think it's not valid
if the --release flag is present. So my initial reaction is to allow
usage while in debug mode, by disallow in release mode.
Or at very least provide a scary warning if a remote url is used in
release mode.
On 2019-10-22 1:05 p.m., julio cesar sanchez wrote:
> The content tag is also used for pointing to local development servers and
> benefit from live reloading, so how do you plan to deprecate it only for
> remote urls?
>
> El mar., 22 oct. 2019 a las 17:46, Norman Breau (<no...@normanbreau.com>)
> escribió:
>
>> This is an extension of the issue I raised for adding warnings to the
>> documentation which can be found at
>> https://github.com/apache/cordova-docs/issues/1022
>>
>> In my opinion there are several reasons why using a remote url (such as
>> https://myserver.com/) to host a cordova app is bad practice.
>>
>> 1. If your app uses native APIs, you're breaking the terms of service of
>> the Apple and Google Play app stores. See Section 2.5.2 Software
>> Requirements of apples guidelines.[1]
>>
>> 2. Extending onto #1, it makes the app must more easier to become
>> vulnerable to exploits, because any other
>> third party code loaded onto the website may have access to the cordova
>> APIs.
>>
>> 3. Apple & Google expects your app to be able to launch and "work"
>> without a data connection. If your index file is
>> remote, then your app cannot load to provide the user proper feedback
>> that they require an internet connection. (See section 2.1 App
>> Completeness & 4.2 Minimum Functionality apple guidelines)[1].
>>
>> 4. Using a remote URL generally causes a lot of CORs related issues when
>> using non-standard protocols such as cdvfile:// (see
>> https://github.com/apache/cordova-plugin-file/issues/352)
>>
>> 5. Even if your app does not use native APIs, and it's just repackaging
>> a website, this goes against section 4.2 on apples policy[1].
>>
>> I don't exactly know how popular using <content src="remoteurl" /> is,
>> but I do see it frequent enough on reported issues. This is kind of
>> frightening.
>>
>> So given the reasons I listed above, I think allowing remote sources in
>> the <content> tag should be deprecated, and eventually removed in the
>> future, of course allowing time for developers to refactor their app to
>> bundle their code within the app.
>>
>> Sources:
>> [1] https://developer.apple.com/app-store/review/guidelines/#design
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
>> For additional commands, e-mail: dev-help@cordova.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
For additional commands, e-mail: dev-help@cordova.apache.org
Re: [DISCUSS] Deprecation of allowing remote urls in config's
Posted by julio cesar sanchez <jc...@gmail.com>.
The content tag is also used for pointing to local development servers and
benefit from live reloading, so how do you plan to deprecate it only for
remote urls?
El mar., 22 oct. 2019 a las 17:46, Norman Breau (<no...@normanbreau.com>)
escribió:
> This is an extension of the issue I raised for adding warnings to the
> documentation which can be found at
> https://github.com/apache/cordova-docs/issues/1022
>
> In my opinion there are several reasons why using a remote url (such as
> https://myserver.com/) to host a cordova app is bad practice.
>
> 1. If your app uses native APIs, you're breaking the terms of service of
> the Apple and Google Play app stores. See Section 2.5.2 Software
> Requirements of apples guidelines.[1]
>
> 2. Extending onto #1, it makes the app must more easier to become
> vulnerable to exploits, because any other
> third party code loaded onto the website may have access to the cordova
> APIs.
>
> 3. Apple & Google expects your app to be able to launch and "work"
> without a data connection. If your index file is
> remote, then your app cannot load to provide the user proper feedback
> that they require an internet connection. (See section 2.1 App
> Completeness & 4.2 Minimum Functionality apple guidelines)[1].
>
> 4. Using a remote URL generally causes a lot of CORs related issues when
> using non-standard protocols such as cdvfile:// (see
> https://github.com/apache/cordova-plugin-file/issues/352)
>
> 5. Even if your app does not use native APIs, and it's just repackaging
> a website, this goes against section 4.2 on apples policy[1].
>
> I don't exactly know how popular using <content src="remoteurl" /> is,
> but I do see it frequent enough on reported issues. This is kind of
> frightening.
>
> So given the reasons I listed above, I think allowing remote sources in
> the <content> tag should be deprecated, and eventually removed in the
> future, of course allowing time for developers to refactor their app to
> bundle their code within the app.
>
> Sources:
> [1] https://developer.apple.com/app-store/review/guidelines/#design
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> For additional commands, e-mail: dev-help@cordova.apache.org
>
>