Manifest: Should manifest be HTTPS only?

[aarongustafson]

This came up in https://github.com/web-platform-tests/wpt/pull/23816

If it should be HTML only, what should be returned in non-secure contexts?

[mgiuca]

I think it's OK for HTTP pages to download and apply pieces of the manifest, but the actual ability to install an app (which creates permanent state on the user's machine) should be restricted to HTTPS. Can we make that distinction?

We currently mention it non-normatively in installability signals. We could make that a normative requirement of installation (but note that all of the normative text around installation was recently removed from the spec).

[marcoscaceres]

I think it's OK for HTTP pages to download and apply pieces of the manifest, but the actual ability to install an app (which creates permanent state on the user's machine) should be restricted to HTTPS. Can we make that distinction?

We can. But I think it would be good to make it a normative requirement to restrict obtaining a manifest to HTTPS. The community is trying to deprecate HTTP anyway, so I'd be happy to just force a https check on obtaining.

[mgiuca]

I don't think Chrome (at least) uses the manifest outside of installation, so it wouldn't break us if we restricted obtaining to secure contexts.

Edit: Actually @dominickng points out that in Chrome, if you manually create a shortcut for an HTTP page, we will still fetch the icons from the manifest to get a nice icon. I don't think there's any harm in doing that, so I think we should still be allowed to obtain a manifest for HTTP.

The secure contexts requirement should be limited to installation.

[dominickng]

I don't see a compelling security-related reason to restrict fetching a manifest and using the metadata in it to HTTPS - any more so than any other piece of declarative content served over HTTP. It feels like an arbitrary restriction ("because we can") rather than a meaningful one. For instance, a browser might wish to fetch the web app manifest to display higher quality icon tiles on its New Tab Page.

As Matt said, installation itself has non-normative requirements of HTTPS, and that feels sufficient to me (it would be nice to have not deleted all the installation bits in the spec; that would have been the perfect place to put the HTTPS requirement).

[marcoscaceres]

I don't see a compelling security-related reason to restrict fetching a manifest and using the metadata in it to HTTPS - any more so than any other piece of declarative content served over HTTP. It feels like an arbitrary restriction ("because we can") rather than a meaningful one.

Agree - although we could make that case that if no one reads the manifest except over HTTPS, then the spec would match reality.

One could also make a case that it protect sites from having third-party proxies inject random manifests or manipulate manifests on the wire?

For instance, a browser might wish to fetch the web app manifest to display higher quality icon tiles on its New Tab Page.

Again, agree... but as above... motivating incentive to be HTTPS if you want to show up on the new tab page?

As Matt said, installation itself has non-normative requirements of HTTPS, and that feels sufficient to me

ok... um... I'm actually thinking we should also drop the "insatiability signals" from the spec. Will open a different bug for that.

(it would be nice to have not deleted all the installation bits in the spec; that would have been the perfect place to put the HTTPS requirement).

We can still just short-circuit it when obtaining that manifest. That would match how it's implemented (resolve the link relationship, check if it's https... if yes, abort).

[marcoscaceres]

Checked Safari... it will happily process manifests on "http".

[mgiuca]

Agree - although we could make that case that if no one reads the manifest except over HTTPS, then the spec would match reality.

See above edit: Chrome reads manifest over HTTP if the user explicitly installs the app.

There are other possible uses of the manifest besides new tab page, just to get higher quality assets for a website, and if there are no explicit security reasons to ban it, I would like to permit it. "motivating incentive to be HTTPS" isn't a strong enough reason; you could apply that to anything.

So I think we should keep this as an installation requirement (either explicit in the spec, or just enforced by browsers), not a requirement for fetching.

[marcoscaceres]

Ok, cool. I think we have consensus to leave it as HTTP.

@aarongustafson, we can remove ".https." from the WPT.