> Doesn't the manifest contain the list of required feature? A very old version of the spec contains a "requiredFeatures" field, but it was never fully defined and isn't supported, and no values for the field were specified.
Permissions are available in the manifest, but that doesn't cover things that the phone doesn't consider a feature. Case in point: we are adding four items to our feature profile this week to detect the different flavors of getUserMedia (audio, video, images, and screen). > I'm not sure I understand what you meant here. Do you have examples? If there's a new feature we want to add compatibility testing for that some devices might already have, we can't rely on the devices to implicitly know that they support the feature. If we decide, for instance, that we want to detect support for <input type="color">, the user agent would need to be able to say, "Oh, I know what <input type="color"> is and I do[n't] support it.". We already have this functionality in our feature profiles, so no sense in reinventing the wheel. > I do not think the marketplaces should be put in the centre of the > system because you can install hosted applications from anywhere so you > can't make the marketplaces owning the blacklist of applications. Right, and as I mentioned in my original email, a marketplace could only use this API for manifests *which it installed itself*. Relying on Mozilla to blacklist apps which were distributed by a third party who could otherwise do the blacklisting themselves seems very bad. If carriers start distributing their own branded marketplaces, making them go through us to flag and remove malware seems like a dangerous and slow process. > Isn't that a problem you have on the Web in general? If someone takes > over your domain, you are screwed. If I host a popular web page or web > service that attracts a lot of users and suddenly, I do no longer own > the domain, all my users will be in danger because they trusted me but > not the new owners. Of course, but we're in a different boat than the web at large. Our users are paying us to be able to install these apps, in some cases, and if a developer comes to us and says, "Hey, we lost our short URL because <insert completely valid and unfortunate reason here> and now the app doesn't work. Can we get you to update the manifests?" we should have the power to make that happen. Granted, that's a feature which isn't on any roadmaps, but it's something that we can't currently do that an API like this would enable for us. ----- Original Message ----- From: "Mounir Lamouri" <[email protected]> To: [email protected] Sent: Friday, May 24, 2013 3:24:03 AM Subject: Re: API for editing existing app installations On 23/05/13 16:36, Matt Basta wrote: >> How do you know that an update is incompatible? > > The marketplace currently generates a feature profile, which the marketplace > API can understand and decide whether the app is compatible with the device. > The platform/OS have no knowledge of this, and just poll whatever URL is > thrown at them for updates. In this case, the mini manifest URL is the > Marketplace API, which could decide whether to serve an update or not. Doesn't the manifest contain the list of required feature? Can't that be used by the runtime to ignore some applications? > Could this go in the manifest? Sure, but then the client needs to know about > every single feature that we sniff for, even ones that Firefox > OS/Android/Desktop don't support. I'm not sure I understand what you meant here. Do you have examples? > Also, warning a user that an app update isn't compatible is a little cruel: > they can't get the update regardless, so why taunt them about it? "Your phone > doesn't support the new version of the app. Too bad!" There's no action > there. The user can't choose to do anything differently in many cases. This is a UX issue but as a user I would like to know that I do no longer get updates because my OS/device is getting too old. A user my trying to push the developer of an app to get the latest version working on its device or even change device or switch to an alternative application. >> Hosted application have identifier based on their manifest URL so the >> runtime can take care of that. > > If the runtime is polling the Marketplace, that's a bad thing and works > against the idea of federated marketplaces, and is partly why hosted app > blocklisting doesn't exist today. Hosted app manifests don't live on > Marketplace servers, and not all apps may have been installed from the > Firefox Marketplace. I do not think the marketplaces should be put in the centre of the system because you can install hosted applications from anywhere so you can't make the marketplaces owning the blacklist of applications. As I said, having Mozilla taking care of blacklist for its runtime is probably the best solution so if a user is using another marketplace than the one from Mozilla, that user would be as safe as anyone else. This is a mechanism we use for websites and extensions. >> Can't the runtime be clever and if there is an HTTP REDIRECT when trying to >> update a manifest? > > Consider the case of Bit.ly a few years ago when there was that big scare > that Libya was going to retract all of the LY TLDs. If an app owner suddenly > lost control over their domain for legal reasons or otherwise, their app is > permanently broken on all users' devices, and potentially could be hijacked > by a third party in the future. Isn't that a problem you have on the Web in general? If someone takes over your domain, you are screwed. If I host a popular web page or web service that attracts a lot of users and suddenly, I do no longer own the domain, all my users will be in danger because they trusted me but not the new owners. Given that hosted web applications are no more than web applications with a manifest to make their integration in the runtime better, trying to solve this problem does not seem to be in scope. -- Mounir _______________________________________________ dev-webapps mailing list [email protected] https://lists.mozilla.org/listinfo/dev-webapps _______________________________________________ dev-webapps mailing list [email protected] https://lists.mozilla.org/listinfo/dev-webapps
