952696 - Allow launch_path to be external

Status: RESOLVED WONTFIX

(Core Graveyard :: DOM: Apps, defect)

Description

[Christopher Van Wiemeersch [:cvan]]

Although we have a new manifest spec coming (https://w3c.github.io/manifest/), I think we should allow manifests to specify external `launch_path`s. Currently, we require a `launch_path` to be relative to the domain on which the manifest is hosted.

Below are transcripts from a mailing-list thread:

On 10/31/2013 23:37, Chris Van Wiemeersch wrote:
> Chrome already lets you point to an external URL (see http://developer.chrome.com/extensions/manifest.html for more):
>
>     {
>          ...
>          "app": {
>              "launch": {
>                  "container": "panel",
>                  "web_url": "http://cvan.github.io/HexGL/" }
>          },
>      }
> 
> Firefox doesn't let you point to an external URL; it must be relative:
> 
>      {
>          ...
>          "launch_path": "/index.html",
>          ...
>      }
> 
> But you could create a file that does a `window.location` to redirect to
> your external URL:
> 
>      {
>          ...
>          "launch_path":
>          "/index.html?redirect= http://cvan.github.io/HexGL/ ",
>          ...
>      }
> 
> The Firefox Marketplace (or any other marketplace) could create a synthetic
> manifest on the fly (using the hacky approach above). Ideally, we change
> Firefox to accept this format:
> 
>      {
>          ...
>          "launch_path": "http://cvan.github.io/HexGL/" ,
>          ...
>      }
> 
> The idea is that ALL the metadata gets submitted to the Marketplace. The
> developer would no longer need to handwrite JSON! We would provide a form
> that collects Firefox-pertinent information (e.g., App URL, Name, Icons,
> Developer Name, Web Activities, Orientation) and then Marketplace-specific
> information (e.g., Categories, Privacy Policy, Screenshots). This allows
> the information to be updated in ONE place — the manifest — and updates
> are immediate.
> 
> I like the idea of asking the developer for an app URL and the associated
> metadata. That's it. No hosting of a manifest.webapp file. No custom
> Content-Type to serve. Sure, this doesn't solve the problem of app
> ownership, but I think that is something we can police in other ways (like
> adding a separate verification mechanism post submission or rely on abuse
> reports).
> 
> I've talked to UX about the ability to "preview" apps before
> installing/purchasing. We could iframe simple hosted apps (app URL =
> origin + launch_path in the manifest) if they're not setting the
> `X-Frame-Options: DENY` header.
> 
> (I also thought about W3C Widgets — http://www.w3.org/TR/widgets/ — the
> standard for packaged apps, but the browsers aren't there yet.)
> 
> If anyone has additional ideas, let's hear it. It's a problem I've wanted
> to solve to help get our app developers up and running quicker and help
> make the ecosystem less Firefox-centric.

...

> On 11/1/13 9:33 AM, David Bialer wrote: 
>>I am for allowing external launch paths.  It doesn't change the criteria that we don't want wrapped websites, but does remove a barrier by allowing the manifest to be synthesized and pushed to a hosted Marketplace location.  It allows devs to easily update metadata without having to first download a synthesized manifest, upload it to their website and then submit for review.  This is a convenience to the developer though could risk burdening a review team with wrapped websites.  I don't think we should yet design for the case of minimizing slush submissions, though understand the concern.

...

> On 11/01/2013 09:45 AM, Nick Desaulniers:
>> I really don't like manifests. Getting partners to serve it on a same  origin with a specific MIME type is like pulling teeth. Many large  companies just are not flexible enough to implement such policies.
>>
>> It sounds like describing apps via meta tags have their own set of issues given the discussion below. 

...

> On 11/01/2013 11:52 AM, Andrew Williamson wrote:
>>
>> Possible future (1) for me - its the one that allows multiple 
marketplaces without lots of typing into forms over, and over again. 
And allows the developer to update the meta data on their server without 
having to jump through authentication and UX hoops each time.
>>
>> I'm happy to loose the developers who can't handle writing JSON given 
its the same language as the apps themselves are written in.  That said, 
a manifest file generator is a really good idea for first time app 
developers.
>>
>> The prohibition on external launch_paths must stay - its a simple and 
effective hurdle in preventing random apps wrapping websites.  I don't 
want that change reversed.
>>
>> Andrew Williamson
>> App Review Technical Lead @ Marketplace.Firefox.com

...

> On 11/01/2013 06:49 PM, Travis Choma wrote:
>> Given we currently have manifest files, being able to auto-generate them based on app submission meta data seems like it would eliminate a lot of pain that cvan and Nick were describing, i.e. editing JSON manually for first time devs, dealing with the mime-type being set properly on servers etc.
>> 
>> I think cvan's 2nd proposal of having an external launch path is worth considering. 
>>
>> 1. It means that it doesn't have to be one way or the other. Developers can choose to auto-gen the manifest file based on their submission data, or they can make their own manifest. This also means that in the multi-appstore case you could still choose to submit a manifest file and skip all the custom steps needed to auto-gen one.
>> 
>> 2. Re Andrew's comment on external launch path's preventing unauthorized wrapping of sites. Definitely something we should guard against, but launch path restrictions is not the only way we can prevent that. During marketplace submission we can verify ownership in more traditional ways, i.e. adding a temp meta-tag to your html, or adding a txt dns record, and I can imagine that there are even more that may have less friction.

Comment 1

[Christopher Van Wiemeersch [:cvan]]

It's worth noting that Google’s manifest format allows developers to reference external URLs <https://developers.google.com/chrome/apps/docs/developers_guide#live>.

Comment 2

[Christopher Van Wiemeersch [:cvan]]

Can we do this? It looks like it should be reverting the work done in bug 786710.

Comment 3

[Bill Maggs (bmaggs)]

+1

Comment 4

[Christopher Van Wiemeersch [:cvan]]

Can we do this sometime soon? Please?

Comment 5

[Sylvestre Ledru [:Sylvestre]]

Core Graveyard / DOM: Apps is inactive. Closing all bugs in this component.