Thoughts about the ipfs for web sites tutorial

Hi there, enjoying learning IPFS - a very cool and much needed project. The examples are great and few going thoughts come to mind after completing the excellent the ipfs for web sites tutorial that I think are useful to share with the community - in our day in age, for this web-apps deployment strategy to be practical and secure, tls/https must be employed and web apps should only be served from a domain authenticated via tls, so only code from this domain can access the user’s local browser store which may hold private user date, credentials, etc… In other words, thinking that server-less web apps will be used by users from localhost is native as all locally running web apps can access the same user data (there’s no per-domain protection to user private data). Also, using a gateway as the domain for the app is a bad idea because any other web app using this strategy will have access to the user’s private data from any other such apps. There is no useful web app I can think of that doesn’t hold private user date in local browser store. e.g. session tokens, private keys, preferences, etc…

Running from a custom domain mapped to an IPFS html-5 app repo is a better solution but this can only work if this mapping fully supports tls/https. Otherwise, any MIM can inject JS code into responses from the IPFS gateway and easily read user private data from local storage, send data to another web service, modify the data, etc…

The only example of a hosted web apps provider that got it right is Google Firebase (Even Google App Engine doesn’t support https on custom domains) - While Firebase was mainly designed to support data and apis for mobile native apps, it includes a free static website hosting service with full support to https and a custom domain. I’m not sure exactly how they have implemented this but this just shows the technical possibility.

So, bottom line - to make IPFS a serious option for deploying real-world HTML5 Apps - official gateway(s) should support flows with custom domains with https and not just using http like it works today. To make this clearer this site: http://site.immersiveos.com/ which I created following the tutorial, should be served from https://site.immersiveos.com/ and all data transferred from the gateway should be encrypted on the wire.

Is there a way or a path to achieve this?

2 Likes

Yeah, the thing is, IPFS is not a hosted web apps provider per se…

Hosting costs money, SSL certificates used to cost money and so on… If you want your own https site you need to run your own ipfs gateway under your own domain/certificates. The official ipfs-gateways serve multiple purposes (hosting content, easen migration, provide a living example), but they are not a free hosting service with custom domain SSL support.

Note, additionally, that IPFS has no point if everything is centralized in the official gateways. Therefore I would encourage you to run your own ipfs gateway(s).

1 Like

Makes sense but I think that this should be clarified a bit in the multiple places the ipfs docs where they refer to ipfs as a decentralized mechanism for distributing server-less html5 apps that run via local host. I don’t think this scenario is viable nor secure without full support for TLS and it is not clear that one will need to deploy a custom ipfs gateway with ssl support to properly deploy such a web app.

1 Like

Well, the goal of ipfs is to keep files around even when the original source goes down. If everyone has their own gateways and the original gateway/custom domain goes offline… how do you know where to get the files ?

Sounds to me what you’d want something like this:

  1. make sure as much as possible in your HTML5-webapp is static files with file hashes, preferable all of it ( see: http://unhosted.org/ )
  2. make a list and sign it
  3. publish the signed list.

That way, people know the files people get from ipfs are the files as intended by the person with the certificate (because the hashes are verified).

Obviously, eventually the certificate will expire, but at least if people know what the hash of the signed list was, it will remain valid.

AFAIK no protocol exists for that right now ?

Maybe something like:

html-file on your website:

<!doctype html5>

1 Like

This is a good topic, though a little over my head. I’ve been experimenting with creating my own web pages and adding to IPFS. I share my links through Telegram. I’ve never studied web-design or internet protocols or certificates. I notice a lot of mention in this tread about hosting security. Does this only relate to webapps with databases?

This is my site
https://ipfs.io/ipns/QmfQ1YxZTCRw63DXhsMKGzHqncWaEwJBX6rFxcn1Rf5bmT/
Is there anything wrong with the way I’m going about it?