Re: [manifest] Update and call for review
As per our conversation in IRC, something else I'd like to highlight is the fact that in the current version of the spec any web site can host an app manifest for any web app. That means for example that I could create my own app store for web apps and provide a listing for a GMail app which users can add to their homescreen, without any involvement from Google. It would be good to hear some opinions on whether it is a good thing or a bad thing that manifests don't have to be served from the same origin as the web app itself.
Re: [manifest] Fetching restriction, Re: [manifest] Update and call for review
On Tue, May 27, 2014 at 5:11 PM, Marcos Caceres w...@marcosc.com wrote:
The only way one could do what you describe would be for my own app
store to host its own manifests. So:
http://myownappstore.com/gmail/index.html
Would contain:
link rel=manifest
href=http://myownappstore.com/gmail/manifest.json;
Which would have:
{
name: Gmail
start_url: http://gmail.com;
}
This would allow custom stores that provide tailored app experiences for
sites that lack manifests.
Where this could become a problem in the future is if manifests start
granting elevated privileges (e.g., access to specific APIs or unlimited
storage). However, the security model could then be refined so that, for
instance, only same origin manifests that are served over HTTPS get special
powers. In such a case, non-same-origin manifests could be tainted and
only the basic metadata from the manifest would be used by the user agent.
To be clear, this is the case I was talking about. The benefit is that it
makes it much easier to build a large app store of tailored app
experiences for sites that lack manifests without the involvement of app
authors themselves. For example, everything.me may have a larger catalogue
of web apps than the Firefox Marketplace because the latter requires
same-origin manifests and for app authors to submit their own apps, whereas
the former doesn't require any involvement from app authors themselves.
One risk of allowing cross-origin manifests might be that these tailored
app experiences are perceived by the actual app author and/or end users as
a fake app masquerading as the real thing. In the longer term when
additional features are added to the manifest there could be additional
risks.
That is why I'm interested in feedback on whether this is a desirable
feature or not.
Re: [manifest] Update and call for review
On Mon, May 26, 2014 at 8:18 PM, Marcos Caceres w...@marcosc.com wrote: Quick update: the Editors have closed off all V1 bugs for [manifest] and implementations in Blink and Gecko are underway. A thorough review of [manifest] by interested parties would be greatly appreciated! You can file bugs in our GitHub [bug tracker]. Nice work! FYI I expect implementation in the Firefox OS browser to be tracked here https://bugzilla.mozilla.org/show_bug.cgi?id=1003890 We now have the option to cherry-pick V2 features to either spin off into separate specs or to add to the current document. You can view the V2 features at [V2]. See also the [CSP-member], which is already in its own spec. Devs and implementers, please let us know which V2 features should be prioritized. To me the biggest issues for v2 are: URL Scope to which the manifest applies https://github.com/w3c/manifest/issues/114 Specify how navigation works https://github.com/w3c/manifest/issues/142 which I think are all part of the same issue of app scope. The specification describes a manifest whose properties can be used when bookmarking a web app and effect how that bookmark should be displayed by the user agent when it is launched (e.g. in a standalone window in landscape orientation with no navigation controls). But it does not specify the URL scope to which those properties apply. For example, what display mode the user agent should use when the browsing context is navigated away from the start_url, or away from the origin entirely to another unrelated web site. In other words, what is the scope of the app? All the specification has to say on this topic is The user agent MAY override the default display mode for security reasons (e.g., the top-level browsing context is navigated to another origin). But this doesn't include navigational reasons (e.g. getting stranded on another web site without a back button) or the case of multiple origins per app or multiple apps per origin. In Firefox OS the user can get stranded by following a hyperlink from an installed app to an off-origin web page with no back button and no indication that they have left the origin. Chrome for Android will show the new origin at the top of the screen if you navigate outside the origin in a mobile-web-app-capable homescreen bookmark, but it won't provide browser chrome. In Chrome OS if you open the Google search app as a window and click on a search result, it will navigate you to the result web page but not provide any browser chrome for the web site. I think a particular problem with having no defined scope for apps is when you want to hyperlink from one web app to another. A hyperlink with no specified target window will always open in the browsing context of the current app, regardless of whether the URL belongs to another app or web site. That means that the level of browser chrome you get when following a hyperlink (as well as the orientation of the page and the title and icon shown in the task switcher etc.) depends on where you navigated from rather than where you navigated to. I would like to see some way to define the scope to which an app manifest applies, so that the user agent knows which URLs belong to which apps and therefore what display properties to use for a given URL.
Re: [manifest] Update and call for review
On Wed, May 28, 2014 at 9:39 AM, Anne van Kesteren ann...@annevk.nl wrote:
I don't understand this. That would you mean you'd have to modify the
content of Gmail to point to this manifest. That sounds bad.
To quote Marcos:
The only way one could do what you describe would be for my own app store
to host its own manifests. So:
http://myownappstore.com/gmail/index.html
Would contain:
link rel=manifest
href=http://myownappstore.com/gmail/manifest.json;
Which would have:
{
name: Gmail
start_url: http://gmail.com;
}
This would allow custom stores that provide tailored app experiences for
sites that lack manifests.
This is the scenario I was describing. Allowing this to happen has both
benefits (easy to build huge app stores!) and risks (easy to build fake
apps).
But it sounds as though more people are arguing for the manifest URL and
start URL to be required to be same-origin as each other, which would
prevent this scenario from happening.
