Re: [w3c/manifest] Should manifest be HTTPS only? (#887)

> 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). 


-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/manifest/issues/887#issuecomment-636627558