Packaged app origins and Marketplace

[Rob Hudson]

Hi,

There have been a few bugs filed:

Marketplace origin cannot change for 1.1
https://bugzilla.mozilla.org/show_bug.cgi?id=962524

Cannot set app_domain for webapp that originally had no app_domain
https://bugzilla.mozilla.org/show_bug.cgi?id=1063149

Relax app origin validation to be less domain oriented
https://bugzilla.mozilla.org/show_bug.cgi?id=1065181

App validation is successful even there's no origin specified in the manifest file
https://bugzilla.mozilla.org/show_bug.cgi?id=1065328


Here’s what I know:

Prior to FxOS 1.1 the platform (FxOS) didn’t look at the “origin” defined in the manifest and during install generated one for the app. I believe this origin looks like ‘app://<UUID>’.

If you are a packaged app developer and you change your “origin” defined in the manifest, you break upgrades to your app. The platform does not allow origin changes so the end-user sees an error. Unfortunately the end-user will also continue to get update notifications that they can’t install.

On Marketplace we currently do not enforce either having an origin or not changing the origin. We verify an origin if one exists but require it to look like a domain.


To fix the bugs I propose the following:

Require the “origin” to be defined for packaged apps. If the app wants to ever do server-less payments the “origin” will be important. Alternatively we could strongly suggest that an origin exists and explain why.

Do not allow “origin” changes between packaged app versions as they break upgrades. Alternatively we could allow origin changes but explain that it will break app upgrades — users will have to uninstall and re-install their app.

Allow the “origin” to look like something other than a domain. E.g. “app://facebook”.

Unfortunately I don’t think there’s any fix for a pre-installed packaged app that changes the origin in an upgrade (bug 962524).


Any thoughts/concerns/objections to the proposed fixes?


Thanks,
Rob

[Kumar McMillan]

On Sep 10, 2014, at 2:39 PM, Rob Hudson <chu...@mozilla.com> wrote:

> Hi,
>
> There have been a few bugs filed:
>
> Marketplace origin cannot change for 1.1
> https://bugzilla.mozilla.org/show_bug.cgi?id=962524
>
> Cannot set app_domain for webapp that originally had no app_domain
> https://bugzilla.mozilla.org/show_bug.cgi?id=1063149
>
> Relax app origin validation to be less domain oriented
> https://bugzilla.mozilla.org/show_bug.cgi?id=1065181
>
> App validation is successful even there's no origin specified in the manifest file
> https://bugzilla.mozilla.org/show_bug.cgi?id=1065328
>
>
> Here’s what I know:
>
> Prior to FxOS 1.1 the platform (FxOS) didn’t look at the “origin” defined in the manifest and during install generated one for the app. I believe this origin looks like ‘app://<UUID>’.
>
> If you are a packaged app developer and you change your “origin” defined in the manifest, you break upgrades to your app. The platform does not allow origin changes so the end-user sees an error. Unfortunately the end-user will also continue to get update notifications that they can’t install.
>
> On Marketplace we currently do not enforce either having an origin or not changing the origin. We verify an origin if one exists but require it to look like a domain.
>
>
> To fix the bugs I propose the following:
>
> Require the “origin” to be defined for packaged apps. If the app wants to ever do server-less payments the “origin” will be important. Alternatively we could strongly suggest that an origin exists and explain why.
>
> Do not allow “origin” changes between packaged app versions as they break upgrades. Alternatively we could allow origin changes but explain that it will break app upgrades — users will have to uninstall and re-install their app.

I say we require origins for packaged apps. It will make things simpler.

>
> Allow the “origin” to look like something other than a domain. E.g. “app://facebook”.

I think this is a good idea. Editors are better equipped to detect spoofs. I actually filed for this based on the last discussion: https://bugzilla.mozilla.org/show_bug.cgi?id=1065181

>
> Unfortunately I don’t think there’s any fix for a pre-installed packaged app that changes the origin in an upgrade (bug 962524).
>
>
> Any thoughts/concerns/objections to the proposed fixes?
>
>
> Thanks,
> Rob

> _______________________________________________
> dev-marketplace mailing list
> dev-mar...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-marketplace

[Paul Theriault]

I am concerned about this proposal and it sounds like there is a disconnect between FxOS and Marketplace on the security constraints of app origin fields.

On 11 Sep 2014, at 5:39 am, Rob Hudson <chu...@mozilla.com> wrote:

> Hi,
>
> There have been a few bugs filed:
>
> Marketplace origin cannot change for 1.1
> https://bugzilla.mozilla.org/show_bug.cgi?id=962524
>
> Cannot set app_domain for webapp that originally had no app_domain
> https://bugzilla.mozilla.org/show_bug.cgi?id=1063149
>
> Relax app origin validation to be less domain oriented
> https://bugzilla.mozilla.org/show_bug.cgi?id=1065181
>
> App validation is successful even there's no origin specified in the manifest file
> https://bugzilla.mozilla.org/show_bug.cgi?id=1065328
>
>
> Here’s what I know:
>
> Prior to FxOS 1.1 the platform (FxOS) didn’t look at the “origin” defined in the manifest and during install generated one for the app. I believe this origin looks like ‘app://<UUID>’.
>
> If you are a packaged app developer and you change your “origin” defined in the manifest, you break upgrades to your app. The platform does not allow origin changes so the end-user sees an error. Unfortunately the end-user will also continue to get update notifications that they can’t install.
>
> On Marketplace we currently do not enforce either having an origin or not changing the origin. We verify an origin if one exists but require it to look like a domain.
>
>
> To fix the bugs I propose the following:
>
> Require the “origin” to be defined for packaged apps. If the app wants to ever do server-less payments the “origin” will be important. Alternatively we could strongly suggest that an origin exists and explain why.

Origin is ONLY safe for privileged apps and ONLY if the marketplace review team ensure thats the app is not claiming an origin which could belong to another app.

Origin is prohibited on regular packaged apps since you could use it claim another apps origin. (Noting that this packaged apps might not be installed through the marketplace). The bottom line is that origin is a hack, and one that was hoping would disappear once hosted packaged apps lands (bug 1033360), though I note this has been pushed to 2.2 so thats a while away.

If the solution is we need to give an app an origin, can I suggest that they be marketplace assigned instead. Maybe the developer can start the submission process prior to submitting the app, and have the marketplace “pre-reserve" an origin to the app, and something which could be a real domain that the marketplace controls. IE something like: app://appid1234.firefox-marketplace-apps.com. (i.e. marketplace controlled but NOT same-origin with marketplace) We should also consider if/how these can upgrade to hosted packaged (bug 1033660) apps once they land.

>
> Do not allow “origin” changes between packaged app versions as they break upgrades. Alternatively we could allow origin changes but explain that it will break app upgrades — users will have to uninstall and re-install their app.
>

> Allow the “origin” to look like something other than a domain. E.g. “app://facebook”.

Why is this needed, doesn’t it just make it harder to verify the ownership?

[Andy McKay]

> Origin is ONLY safe for privileged apps and ONLY if the marketplace review team ensure thats the app is not claiming an origin which could belong to another app.

The validator currently does this.

> Origin is prohibited on regular packaged apps since you could use it claim another apps origin. (Noting that this packaged apps might not be installed through the marketplace). The bottom line is that origin is a hack, and one that was hoping would disappear once hosted packaged apps lands (bug 1033360), though I note this has been pushed to 2.2 so thats a while away.

Thats good to know. If origins are going to go away, we might have to rethink how we use them on the marketplace in multiple places.

> If the solution is we need to give an app an origin, can I suggest that they be marketplace assigned instead. Maybe the developer can start the submission process prior to submitting the app, and have the marketplace “pre-reserve" an origin to the app, and something which could be a real domain that the marketplace controls. IE something like: app://appid1234.firefox-marketplace-apps.com. (i.e. marketplace controlled but NOT same-origin with marketplace) We should also consider if/how these can upgrade to hosted packaged (bug 1033660) apps once they land.

That seems like we are adding in an arbitrary step of requiring to ping the marketplace before starting an app. In the past we’ve wanted to do that make the entry into developing apps as easy as possible.

>
>>
>> Do not allow “origin” changes between packaged app versions as they break upgrades. Alternatively we could allow origin changes but explain that it will break app upgrades — users will have to uninstall and re-install their app.
>>
>> Allow the “origin” to look like something other than a domain. E.g. “app://facebook”.
>
> Why is this needed, doesn’t it just make it harder to verify the ownership?

There was a separate thread on this, personally a domain is clear, understandable and reasonably unique.

[Kumar McMillan]

On Sep 10, 2014, at 6:42 PM, Andy McKay <an...@mozilla.com> wrote:

>
>> Origin is ONLY safe for privileged apps and ONLY if the marketplace review team ensure thats the app is not claiming an origin which could belong to another app.
>
> The validator currently does this.
>
>> Origin is prohibited on regular packaged apps since you could use it claim another apps origin. (Noting that this packaged apps might not be installed through the marketplace). The bottom line is that origin is a hack, and one that was hoping would disappear once hosted packaged apps lands (bug 1033360), though I note this has been pushed to 2.2 so thats a while away.
>
> Thats good to know. If origins are going to go away, we might have to rethink how we use them on the marketplace in multiple places.
>
>> If the solution is we need to give an app an origin, can I suggest that they be marketplace assigned instead. Maybe the developer can start the submission process prior to submitting the app, and have the marketplace “pre-reserve" an origin to the app, and something which could be a real domain that the marketplace controls. IE something like: app://appid1234.firefox-marketplace-apps.com. (i.e. marketplace controlled but NOT same-origin with marketplace) We should also consider if/how these can upgrade to hosted packaged (bug 1033660) apps once they land.
>
> That seems like we are adding in an arbitrary step of requiring to ping the marketplace before starting an app. In the past we’ve wanted to do that make the entry into developing apps as easy as possible.

I think auto-generating an origin could probably work. We could have the validator error on foreign origins and suggest a new one (maybe with UUID4 to avoid collisions). The developer would then have to change their package and re-upload. One extra step but is it so bad?

If we go this route it would actually prepare us for the “removal” of origins. It sounds like the new plan for hosted origins will be similar to this manner of a marketplace declared URL.

Are there any use cases where apps will need to declare a custom origin? Would they be using it for oauth or something?

>
>>
>>>
>>> Do not allow “origin” changes between packaged app versions as they break upgrades. Alternatively we could allow origin changes but explain that it will break app upgrades — users will have to uninstall and re-install their app.
>>>
>>> Allow the “origin” to look like something other than a domain. E.g. “app://facebook”.
>>
>> Why is this needed, doesn’t it just make it harder to verify the ownership?
>
> There was a separate thread on this, personally a domain is clear, understandable and reasonably unique.
>

[Christopher Van]

We should look at how Chrome packaged apps are designed with respect to origins.

Chrome extensions and packaged apps both use the same Chrome manifest format:

https://developer.chrome.com/extensions/manifest

>From what I can tell, both extensions and packaged apps are assigned their own unique origin. To circumvent the same-origin policy for particular hosts, the Chrome manifest format provides a key called `permissions` which allows you to whitelist domains <https://developer.chrome.com/extensions/declare_permissions> <https://developer.chrome.com/apps/xhr#requesting-permission>, like so:

...
"permissions": [
"tabs",
"bookmarks",
"https://www.mozilla.org/",
"https://*.firefox.com/",
"unlimitedStorage"
],
...

Here is a whole page on Chrome's security model:

https://developer.chrome.com/apps/app_external

[Rob Hudson]

On Sep 10, 2014, at 4:46 PM, Kumar McMillan <kmcm...@mozilla.com> wrote:
>>> If the solution is we need to give an app an origin, can I suggest that they be marketplace assigned instead. Maybe the developer can start the submission process prior to submitting the app, and have the marketplace “pre-reserve" an origin to the app, and something which could be a real domain that the marketplace controls. IE something like: app://appid1234.firefox-marketplace-apps.com. (i.e. marketplace controlled but NOT same-origin with marketplace) We should also consider if/how these can upgrade to hosted packaged (bug 1033660) apps once they land.
>>
>> That seems like we are adding in an arbitrary step of requiring to ping the marketplace before starting an app. In the past we’ve wanted to do that make the entry into developing apps as easy as possible.
>
> I think auto-generating an origin could probably work. We could have the validator error on foreign origins and suggest a new one (maybe with UUID4 to avoid collisions). The developer would then have to change their package and re-upload. One extra step but is it so bad?
>
> If we go this route it would actually prepare us for the “removal” of origins. It sounds like the new plan for hosted origins will be similar to this manner of a marketplace declared URL.
>
> Are there any use cases where apps will need to declare a custom origin? Would they be using it for oauth or something?

If we auto-generate origins what is the path of current packaged apps that define their own origin? If we change them we break upgrades on device unless there is a platform change to deal with this. And even then they break for older devices.

We do generate a unique ID for each app on marketplace. For packaged app signing we stick this id in the .META-INF/ids.json file along with the version ID. Since this UUID is created when the app is created we could base the origin on this if we wanted to. It wouldn’t change like app slugs can.

-Rob