Closed Bug 968570 Opened 6 years ago Closed 4 years ago

Ability to track pre-load apps needed (vs apps downloaded from Marketplace)

Categories

(Firefox OS Graveyard :: Gaia::Homescreen, defect)

x86_64
Windows 7
defect
Not set

Tracking

(Not tracked)

RESOLVED WONTFIX

People

(Reporter: kward, Unassigned)

References

Details

Use Cases

Carrier X has a revenue share agreement with The Weather App (TWA).
TWA needs to be able to track where it got installed from. They are currently asking to be preloaded with a referral attached to the manifest.webapp URL (like twapp.com/manifest.webapp?referral=carrierX). The manifest.webapp is generated dynamically and the referral is attached to the `launch_path`. Downside here is that the manifest URLs are used to identify app installations, users are able to install a second TWC app from the Marketplace.

Carrier Y gives 2 months free premium service to pre-installed The Music App (TMA)
As users get 1 month free music streaming (Carrier Z paid extra to get 2 months premium service), the app needs to check the carrier agreement. Checking for country isn’t enough, as users that didn’t get the app preloaded and just got it from Marketplace don’t get the extra.

Solution

The platform stores `installOrigin` for an app which the app can use to read out where it got installed from. For apps installed from Marketplace this is set to `https://marketplace.firefox.com`. Awkwardly this is also set to Marketplace for preloaded apps, which is probably due to historical reasons and because there are no better alternatives.

The preload process can set `installOrigin` to the country specific carrier URL (like http://www.telefonica.com.uy or http://www.vivo.com.br) so apps know which preloaded them. They can get the `installOrigin` from the app instance received via `navigator.mozApps.getSelf`.

Risks

I don’t see any risks other than giving preloaded apps the privilege to detect their preload origin, which seems to be the intended use for the `installOrigin`.

———

This is a pressing issue and reoccurring. Not fixing it at the preload level will cause more referral tagged manifest URLs and therefor the risk of confused users ending up with 2 apps.
We need a resolution as to whether this proposal will work or not no later than Feb 10 to allow it to be used on first V1.3 pre-load devices.
(In reply to Karen Ward [:kward] from comment #1)
> We need a resolution as to whether this proposal will work or not no later
> than Feb 10 to allow it to be used on first V1.3 pre-load devices.

This is not a committed feature for 1.3 - way too late to consider this for that release.
Assignee: yurenju.mozilla → nobody
Can you clarify Jason? This is nothing that has to land on B2G, this only affects the preloading process.
Flags: needinfo?(jsmith)
(In reply to Harald Kirschner :digitarald from comment #3)
> Can you clarify Jason? This is nothing that has to land on B2G, this only
> affects the preloading process.

Does that imply changes to the build system or the customization itself?
Flags: needinfo?(jsmith)
installOrigin is configured in variant.json during customization.

What to set set installOrigin to is documented for hosted [1] and packaged apps [2]. This guidelines needs to be fine-tuned according to the use cases.

[1]: https://wiki.mozilla.org/B2G/MarketCustomizations#hosted_webapp
[2]: https://wiki.mozilla.org/B2G/MarketCustomizations#packaged_webapp
(In reply to Harald Kirschner :digitarald from comment #5)
> installOrigin is configured in variant.json during customization.
> 
> What to set set installOrigin to is documented for hosted [1] and packaged
> apps [2]. This guidelines needs to be fine-tuned according to the use cases.
> 
> [1]: https://wiki.mozilla.org/B2G/MarketCustomizations#hosted_webapp
> [2]: https://wiki.mozilla.org/B2G/MarketCustomizations#packaged_webapp

Then update the docs directly.
The purpose of this bug is to collect feedback and concerns first. I don't know all about the preloading process so I don't want to make a decision. This would also need to be communicated as strict requirement to the preloading stakeholders as preloading agreements with partners depend on it.

Karen recommended Yuren as the stakeholder on our side.
Flags: needinfo?(yurenju.mozilla)
Flags: needinfo?(yurenju.mozilla)
Yuren's email for reference:

---
we set all installOrigin for preload apps to marketplace because user can find same app and install it from marketplace
you can reference this bug[1]

if this is acceptable we can set to specific carrier URL, but as I know preload apps shoud be handled by OEM and carrier after 1.0.1, so you need to file a bug to telefonica issue tracker on github[2]

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=859688
[2] https://github.com/telefonicaid/firefoxos-gaia-spain
---

Is the firefoxos-gaia-spain repo really the source of truth for all TEF preloads and the flashing tool used by all preload teams?
Albert, do you know that on comment 8?
Flags: needinfo?(acperez)
Created https://github.com/yurenju/gaia-preload-app/issues/69 to track it in our part of the preload script, a part of the chain we can control.
(In reply to Harald Kirschner :digitarald from comment #8)
> Yuren's email for reference:
> 
> ---
> we set all installOrigin for preload apps to marketplace because user can
> find same app and install it from marketplace
> you can reference this bug[1]
> 
> if this is acceptable we can set to specific carrier URL, but as I know
> preload apps shoud be handled by OEM and carrier after 1.0.1, so you need to
> file a bug to telefonica issue tracker on github[2]
> 
> [1] https://bugzilla.mozilla.org/show_bug.cgi?id=859688
> [2] https://github.com/telefonicaid/firefoxos-gaia-spain
> ---
> 
> Is the firefoxos-gaia-spain repo really the source of truth for all TEF
> preloads and the flashing tool used by all preload teams?

The firefoxos-gaia-spain repo is obsolete, we have as a template the repo at https://github.com/telefonicaid/firefoxos-gaia-testsbuild
Flags: needinfo?(acperez)
:albert, any input on the new requirement discussed above? Should we track it in your github repo?
Flags: needinfo?(acperez)
(In reply to Harald Kirschner :digitarald from comment #12)
> :albert, any input on the new requirement discussed above? Should we track
> it in your github repo?

Yes please, open an issue in telefonica's repo.
https://github.com/telefonicaid/firefoxos-gaia-testsbuild

Regarding to the requirement discussed I would like to point a possible risk with the fact that installOrigin is used to determine if an application can be installed according to 'installs_allowed_from' parameter in the manifest. See https://mxr.mozilla.org/mozilla-central/source/dom/apps/src/Webapps.jsm#1738
Flags: needinfo?(acperez)
(In reply to Albert [:albert] from comment #13)
> Regarding to the requirement discussed I would like to point a possible risk
> with the fact that installOrigin is used to determine if an application can
> be installed according to 'installs_allowed_from' parameter in the manifest.
> See
> https://mxr.mozilla.org/mozilla-central/source/dom/apps/src/Webapps.jsm#1738

But would that affect the preloading process?
(In reply to Harald Kirschner :digitarald from comment #14)
> (In reply to Albert [:albert] from comment #13)
> > Regarding to the requirement discussed I would like to point a possible risk
> > with the fact that installOrigin is used to determine if an application can
> > be installed according to 'installs_allowed_from' parameter in the manifest.
> > See
> > https://mxr.mozilla.org/mozilla-central/source/dom/apps/src/Webapps.jsm#1738
> 
> But would that affect the preloading process?

The installOrigin can't be modified for privileged apps because it is used to check the signature of the app. Are you planning to install the app as a single variant application? If so, do you want to create two apps with different mcc/mnc and each one having different installOrigin?
(In reply to Albert [:albert] from comment #15)
> The installOrigin can't be modified for privileged apps because it is used
> to check the signature of the app. Are you planning to install the app as a
> single variant application? If so, do you want to create two apps with
> different mcc/mnc and each one having different installOrigin?

Is that also true for the preload process or would it affect the updates?
Flags: needinfo?(acperez)
+:fabrice, who wrote the code to add more insights on the impact of setting installOrigin.
Flags: needinfo?(fabrice)
(In reply to Harald Kirschner :digitarald from comment #16)
> (In reply to Albert [:albert] from comment #15)
> > The installOrigin can't be modified for privileged apps because it is used
> > to check the signature of the app. Are you planning to install the app as a
> > single variant application? If so, do you want to create two apps with
> > different mcc/mnc and each one having different installOrigin?
> 
> Is that also true for the preload process or would it affect the updates?

The preload process (for single variant apps) won't have problems and the app is going to be installed. But I think that updates will fail because installOrigin is checked, however Fabrice can confirm problems with update process.
Flags: needinfo?(acperez)
(In reply to Harald Kirschner :digitarald from comment #14)
> (In reply to Albert [:albert] from comment #13)
> > Regarding to the requirement discussed I would like to point a possible risk
> > with the fact that installOrigin is used to determine if an application can
> > be installed according to 'installs_allowed_from' parameter in the manifest.
> > See
> > https://mxr.mozilla.org/mozilla-central/source/dom/apps/src/Webapps.jsm#1738
> 
> But would that affect the preloading process?

If the app is installed as a single variant app (that is, if it's installed or not depending of the MCC/MNC of the SIM card present at boot time) then the apps are installed almost as any other app. And that means that they must follow the same guidelines.

To be clear, currently a single variant app cannot have a installorigin that is not set on the installs_allowed_from field of the manifest (if the installs_allowed_from field exists). If you want to use
https://operatorOne.url.com as installOrigin, then either https://operatorOne.url.com have to be added to the installs_allowed_from field, or the installs_allowed_from field cannot be present.

Once the application is installed, though, the update should work correctly so long as the manifestURL field is set to the right value.

There's another validation that uses installOrigin, to check if the app comes from a valid signer domain, but that validation is relaxed when the app is installed from a local file instead of being downloaded from the network (that is, for single variant app installations).
(In reply to Harald Kirschner :digitarald from comment #17)
> +:fabrice, who wrote the code to add more insights on the impact of setting
> installOrigin.

I think that should work, but I'm not 100% sure about how that impacts the store ID checks that we do. Carmen, any idea on this?
Flags: needinfo?(fabrice) → needinfo?(cjc)
Hmm... at first run time, for privileged/signed apps that don't have a storeID on the package we set a 'pending' storeID that includes the app installorigin (to ensure it's unique per install origin). But that installorigin is not checked at update time, the only check that's done is that either the store id of the new package is the same than the existing one, or that the store id prefix is STORE_ID_PENDING_PREFIX.

For preinstalled (global) apps, that is, apps that are *not* configured at run time as part of the single variant, this approach would work, I think (and in any case it's easy to test). And the problem for single variant apps, as I said previously, will not be the update as much as the installation (because it checks that installOrigin is on install_allowed_from if install_allowed_from is defined).
Flags: needinfo?(cjc)
Seems like the only limitation we have is that apps can't set install_allowed_from, which makes sense. Does that mitigate your concerns, :albert?

We have preloaded partners that want to implement the installOrigin check to track preload agreements. Can we go ahead with this?
Flags: needinfo?(acperez)
(In reply to Harald Kirschner :digitarald from comment #22)
> Seems like the only limitation we have is that apps can't set
> install_allowed_from, which makes sense. Does that mitigate your concerns,
> :albert?
> 
> We have preloaded partners that want to implement the installOrigin check to
> track preload agreements. Can we go ahead with this?

Given the comments from Carmen and Fabrice seems that your proposal can work. However the best way to confirm it is doing some testing, so I think you can go ahead.
Flags: needinfo?(acperez)
What are the next steps here to get this in for the preloads. We have a few apps that have preload agreements and need to get a installOrigin that can defer the carrier and country from.
Flags: needinfo?(kward)
Thomas, do you have suggestions on who we should work with first on this?   Accuweather, Here Maps, The Weather Channel?
Flags: needinfo?(telin)
A few quick questions to help determine the most ideal candidate.

What will be needed from the Partner? How involved will they need to be in the process?
Flags: needinfo?(telin)
Let's move forward with the WeatherChannel.  Since Mozilla will have zero insight into the counts / activity tracking provided by this solution we need their participation via reporting.  I believe this is part of their contractual obligation already.
TWC have installed the code snippet on their end. They know ask:

"I believe we have recommended code update implemented on our side and are ready for testing.  Harald/Dees - what do you need from us in order to begin testing?"
Flags: needinfo?(hkirschner)
(In reply to Harald Kirschner :digitarald from comment #24)
> What are the next steps here to get this in for the preloads. We have a few
> apps that have preload agreements and need to get a installOrigin that can
> defer the carrier and country from.

TWC is first candidate.  Please note that this solution only allows the Developer to gather data about pre-loaded apps.  It does not provide info directly to Mozilla.
Flags: needinfo?(kward)
Karen, the partner is ready to go. Could you or whoever is responsible update bug that tracks preloads so the right installOrigin gets preloaded for the partner? This is a new requirement for preloads so we need to make sure that everybody is on the same page.
Flags: needinfo?(hkirschner) → needinfo?(kward)
This is going to be the tricky part.  We have a good number of 'unknown' partners now.  I will be implementing an online reference by end of June, but will communicate this out to known partners as well.Please confirm what is / where I can find the correct Manifest URL for TWC.
Flags: needinfo?(kward)
Mass update: Resolve wontfix all issues with legacy homescreens.

As of 2.6 we have a new homescreen and having these issues open is confusing. All issues will block bug 1231115 so we can use that to re-visit any of these if needed.
Blocks: 1231115
Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.