949523 - Apps downloaded from Marketplace include this parameter in manifest--> feature_profile=3efffff70736.46.3

Status: RESOLVED WONTFIX

(Marketplace Graveyard :: Consumer Pages, defect)

Description

[Beatriz Rodríguez [:brg]]

When downloading apps from Marketplace that were already pre-installed in the device, the application will not replace the current pre-installed one but will create a second entry in the main menu.

After checking the manifest(Thanks Antonio) of the preinstalled one:
   "manifestURL": "http://m.facebook.com/openwebapp/manifest.webapp",
And the second entry created:
   "manifestURL": "https://m.facebook.com/openwebapp/manifest.webapp?feature_profile=3efffff70736.46.3",

There is a new parameter added in the manifest that makes the platform not able to recognize as the same application.

We had reproduced the same isssue with Twitter app:
Pre-installed manifest:
 "manifestURL": "http://mobile.twitter.com/cache/twitter.webapp",
Downloaded manifest:
    "manifestURL": "https://mobile.twitter.com/cache/twitter.webapp?feature_profile=3efffff70736.46.3",
   
Again the same parameter feature_profile=3efffff70736.46.3 appears and thats why we think the issue is related to Marketplace app. Feel free to reasign if I am wrong.

we can reproduce this behaviour in two different devices running v1.1.

Comment 1

[Vance Chen [:vchen][skype:vance.lucida][[e-mail]]]

Hi Karen -

Could you help to point to the marketplace expert to check this problem?

Thansk

Comment 2

[Vance Chen [:vchen][skype:vance.lucida][[e-mail]]]

Hi Karen -

Could you help to point to the marketplace expert to check this problem?

Thanks

Comment 3

[Karen Ward [:kward]]

(In reply to Vance Chen [:vchen][[e-mail]] from comment #2)
> Hi Karen -
> 
> Could you help to point to the marketplace expert to check this problem?
> 
> Thanks

Added Wil to distribution.

Comment 4

[Christopher Van Wiemeersch [:cvan]]

Can you chime in and explain this again to folks?

Comment 5

[Daniel Buchner [:dbuc]]

Let's ponder this for a second:

1) The platform only allow one app per URL/path
2) If an app URL/path contains a slightly different parameter in a URL for an app it already has installed, the platform considers it a second app and tries installing a duplicate

^ The platform is apparently not playing by its own rules - and I can't imagine a scenario where the resulting behavior is desired. Why would the platform try to install an app again - as a second, duplicate copy - instead of simply updating the app that matches the path of the corresponding, pre-installed app? I'll let Basta explain why manifestURL version bumping was implemented on Marketplace - it serves a functional purpose.

Comment 6

[Matt Basta [:basta]]

We add this parameter on purpose, but we check against the unmodified manifest URL with the getInstalled() API to decide whether the user has installed it or not. We won't let you install an app if we see the un-parametered manifest already installed.

That said, based on comment #0, it looks like the issue is the HTTP/HTTPS changeover that happened with Facebook (the S in the HTTPS changes the origin, which is a different manifest). The same appears to have happened with Twitter (notice that the URL starts with HTTPS instead of HTTP).

I'd resolve this bug as duplicate of the bug where everyone was trying to move FB to HTTPS, because that seems like the true root here. The `feature_profile` parameter is a red herring.

Comment 7

[Jason Smith [:jsmith]]

(In reply to Matt Basta [:basta] from comment #6)
> We add this parameter on purpose, but we check against the unmodified
> manifest URL with the getInstalled() API to decide whether the user has
> installed it or not. We won't let you install an app if we see the
> un-parametered manifest already installed.
> 
> That said, based on comment #0, it looks like the issue is the HTTP/HTTPS
> changeover that happened with Facebook (the S in the HTTPS changes the
> origin, which is a different manifest). The same appears to have happened
> with Twitter (notice that the URL starts with HTTPS instead of HTTP).
> 
> I'd resolve this bug as duplicate of the bug where everyone was trying to
> move FB to HTTPS, because that seems like the true root here. The
> `feature_profile` parameter is a red herring.

Yup, that's right. https & http domains are considered separate origins, so they would be classified as separate apps in this case.

Comment 8

[Daniel Buchner [:dbuc]]

(In reply to Jason Smith [:jsmith] from comment #7)
> (In reply to Matt Basta [:basta] from comment #6)
> > We add this parameter on purpose, but we check against the unmodified
> > manifest URL with the getInstalled() API to decide whether the user has
> > installed it or not. We won't let you install an app if we see the
> > un-parametered manifest already installed.
> > 
> > That said, based on comment #0, it looks like the issue is the HTTP/HTTPS
> > changeover that happened with Facebook (the S in the HTTPS changes the
> > origin, which is a different manifest). The same appears to have happened
> > with Twitter (notice that the URL starts with HTTPS instead of HTTP).
> > 
> > I'd resolve this bug as duplicate of the bug where everyone was trying to
> > move FB to HTTPS, because that seems like the true root here. The
> > `feature_profile` parameter is a red herring.
> 
> Yup, that's right. https & http domains are considered separate origins, so
> they would be classified as separate apps in this case.

Agreed, the issue is rooted in the spec/platform's treatment of protocol differences for the same URL path, not the happenstance presence of a URL parameter. I'm not sure where this issue should go from here, but I don't think Marketplace can do anything about it either way.

Comment 9

[Wil Clouser [:clouserw]]

Thanks for the input folks.  I didn't notice the scheme change, but I agree this is the http/https problem which has been discussed via email lately.  I'll find a home for this bug.

Comment 10

[Jason Smith [:jsmith]]

(In reply to Wil Clouser [:clouserw] from comment #9)
> Thanks for the input folks.  I didn't notice the scheme change, but I agree
> this is the http/https problem which has been discussed via email lately. 
> I'll find a home for this bug.

It's a dupe - let me find it.

Comment 12

[Antonio Manuel Amaya Calvo (:amac)]

This has the same root cause, but the solution taken on bug 937917 won't cut it here, because it's actually a different problem. The problem bug 937917 solved was the update of a existing device with a new version. So when a user goes from 1.1 or 1.2 to 1.3, if he has Facebook installed his Facebook will migrate to https seamlessly.

But if a user has 1.1 or 1.2, and he searches for Facebook on the marketplace, it should *not* allow him to install a second Facebook (amongst other thing because it's very bad experience). And it has a simple solution, on the marketplace:

* When you check with getInstalled, if the manifest is https check also for the http version. 
* If the http version is installed, do the same as you currently do with the extra parameter (that is, change the install button to launch). 

You could also prompt the user to uninstall the unsecure version and upgrade to the new one. What we should not do is what we do now (just allow installing a second Facebook or Twitter).

Reopening because of this... feel free to reclose if you still think this should not be fixed here.

Comment 13

[Jason Smith [:jsmith]]

Back over to Marketplace per comment 12.

Comment 14

[Matt Basta [:basta]]

As I said in comment #6, the parameter has no effect on whether or not we decide to allow the user to install the app or not.

And as discussed in bug 937917, the solution in the Marketplace is to update Facebook (and any other app that performs these shenanigans) is to update the URL for the manifest in the Marketplace database and never expose the old version of the manifest. There's very little we can do beyond that since there's no API for changing manifest URLs associated with installed apps, and I don't think this is enough of an issue for us to write complicated (and hard to test) one-offs for every app that ever came pre-installed that switches from HTTP to HTTPS (or vise versa, for that matter).

Comment 15

[Antonio Manuel Amaya Calvo (:amac)]

Sorry... I might have not explain myself or maybe I don't understand the problem. I thought that the URL you already have on your database is:

https://m.facebook.com/openwebapp/manifest.webapp

while the url for the installed app is

http://m.facebook.com/openwebapp/manifest.webapp

So what I'm proposing is that: when you check if the app is already installed or not, if the URL on your database is an https URL then check for both the https AND the http version. If any of those is already installed, then either don't offer the install, or offer the user to deinstall the old one and install a new one (you cannot modify the URL for a preexisting app).

Comment 16

[Vance Chen [:vchen][skype:vance.lucida][[e-mail]]]

Hi Matt, could you comment on Antonio's feedback?

Thanks

Comment 17

[Wil Clouser [:clouserw]]

(In reply to Antonio Manuel Amaya Calvo (:amac) from comment #15)
> Sorry... I might have not explain myself or maybe I don't understand the
> problem. I thought that the URL you already have on your database is:
> 
> https://m.facebook.com/openwebapp/manifest.webapp
> 
> while the url for the installed app is
> 
> http://m.facebook.com/openwebapp/manifest.webapp
> 
> So what I'm proposing is that: when you check if the app is already
> installed or not, if the URL on your database is an https URL then check for
> both the https AND the http version. If any of those is already installed,
> then either don't offer the install, or offer the user to deinstall the old
> one and install a new one (you cannot modify the URL for a preexisting app).

Your proposal makes sense for facebook, but on a larger scale it doesn't.  Different schemes are different URLs and an app at http://domain.com may or may not be the same as https://domain.com.  You can't just make that assumption without bumping up against a fundamental assumption of the internet.

Comment 18

[Matt Basta [:basta]]

I don't believe it's a healthy pattern to add one-off checks for individual apps that do this, and I don't think we should try to match HTTPS when the app is installed as HTTP, since it is entirely possible for an app (or two apps, in this case) to have manifest URLs like that.

Since this is fixed in an update to the platform, I don't see it as a necessary fix. The worst possible scenario is that a user gets to install two copies of a free app.

As I mentioned, though, having an API like the one that dbuc and I specced out does have value and would have completely prevented this issue in the first place.

Comment 19

[Antonio Manuel Amaya Calvo (:amac)]

(In reply to Matt Basta [:basta] from comment #18)
> I don't believe it's a healthy pattern to add one-off checks for individual
> apps that do this, and I don't think we should try to match HTTPS when the
> app is installed as HTTP, since it is entirely possible for an app (or two
> apps, in this case) to have manifest URLs like that.

Well... I haven't looked at the store code, and so I don't know if you can know if it's the same app or not (because you know the manifest URL was updated at some time). You *can* know, though, if you have two different apps with the same manifestURL except for the scheme or not.

> 
> Since this is fixed in an update to the platform, I don't see it as a
> necessary fix. The worst possible scenario is that a user gets to install
> two copies of a free app.

The update to the platform, AFAIK, just does at platform level what I was requesting at the marketplace level. If the update brings an app that has the same manifest than an installed one, except from the scheme (changing from http to https) it removes the http version.

> 
> As I mentioned, though, having an API like the one that dbuc and I specced
> out does have value and would have completely prevented this issue in the
> first place.

Which API was that?

Comment 20

[Matt Basta [:basta]]

(In reply to Antonio Manuel Amaya Calvo (:amac) from comment #19)
> Well... I haven't looked at the store code, and so I don't know if you can
> know if it's the same app or not (because you know the manifest URL was
> updated at some time). You *can* know, though, if you have two different
> apps with the same manifestURL except for the scheme or not.

As mentioned in comment #17, we can't do this universally since there may be apps that rely on HTTP and HTTPS being different apps (that's how the web works). This is not an apps-specific problem.


> The update to the platform, AFAIK, just does at platform level what I was
> requesting at the marketplace level. If the update brings an app that has
> the same manifest than an installed one, except from the scheme (changing
> from http to https) it removes the http version.

So there are two options that I can see here:

1. The Marketplace adds one-off code to detect when the HTTP Facebook/Twitter manifests are installed and flips bits internally to pretend like the user already has the HTTPS versions installed. I don't like this, since this is probably going to happen again. (How many one-offs are we going to add to the Marketplace? How long to we need to keep them?) Bear in mind also that this adds a sizeable amount of code to the Marketplace, which impacts download times.

2. The Marketplace does nothing. Worst case scenario: the user can install two copies of Facebook and Twitter until they get an update.

The latter sounds like the least-bad solution, IMO.

> Which API was that?

I'll let Dan chime in if he's interested. In short, we proposed an API which would allow apps to migrate their manifest URLs so the apps could take care of this themselves.

Comment 21

[Karen Ward [:kward]]

The pre-install URL for Twitter should be: https://mobile.twitter.com/cache/twitter.webapp, so OEM should change that configuration.  The issue for FB is different though; we are in the middle of a fix to support FB moving to https so this issue will remain until  FB completes implementation of  bug 947498.  The FB fix will allow 905469 (sharing from Gallery) to be fixed.