Verify multihash in the browser

[lidel]

No matter if it is a public gateway or a custom one, add-on should calculate hash for received data and compare it with the one from URL.

Not sure what should happen when hash does not match. Probably HTTP Server Error Code (5xx).

Refs.

• Source of idea: https://botbot.me/freenode/ipfs/msg/36342455/
• https://github.com/jbenet/js-multihash
• https://en.wikipedia.org/wiki/List_of_HTTP_status_codes#5xx_Server_Error

[lidel]

After giving it some thought I realized that browser addon should just verify if multihash is a valid one (595b6f0) and that is all.

There are edge cases when using http-based gateway, for example we can't rehash entire 1GB video as it could be fetched via Range Requests. Even downloading big files would be troublesome: we would have to keep data in a buffer until we have all bytes, then rehash, compare with provided multihash, and then accept/throw error.

Implementing partial support (eg. rehashing asset data only below certain size) would give a false sense of security.

Closing until we can ship js-based IPFS node within addon itself (then it will be implicitly implemented).

[Kubuxu]

Maybe option to manually check the hash. This would allow user to confirm that they got the right site.

[lidel]

Possible, but I am not sure if worth the effort.
Manual check is quite easy using already existing tools:

curl -s https://ipfs.io/ipfs/QmYHNYAaYK5hm3ZhZFx5W9H6xydKDGimjdgJMrMSdnctEm | ipfs add -qn
QmYHNYAaYK5hm3ZhZFx5W9H6xydKDGimjdgJMrMSdnctEm

Not sure how UI for this functionality would look like in browser.
Right click on image / html and option to "Verify Multihash"?

[Kubuxu]

Possibly, but yeah, it might be not worth the effort. If you don't trust your gateway then nor should you trust your browser.

[ZettaScript]

This feature would be really useful for web apps, when users don't want to manually download then hash all the files. It seems the simplest solution for trusted web apps.

In case the data doesn't match with the hash, maybe a warning could be displayed, like Firefox does with bad SSL certificates. (and let the user bypass the warning if they want)

Once the hash is known correct, something like a little shield logo could be displayed somewhere (the same as for HTTPS). So if the file is too big, there is no logo.

[blavenie]

@lidel : There are edge cases when using http-based gateway, for example we can't rehash entire 1GB video as it could be fetched via Range Requests. Even downloading big files would be troublesome: we would have to keep data in a buffer until we have all bytes, then rehash, compare with provided multihash, and then accept/throw error.

For web apps hosted in IPFS, why not to check if file like manifest.json or index.html exists, then look for a specific attribute to enable the has check ?
If this attribute is present, we check the hash, and then add mark (e.g. a green checkmark icon, or a lock icon) somewhere.

Like this, any IPFS web apps can say "I am compatible for a quick hash check".

e.g. To compare to an existing W3C solution, any HTML file can have optional integrity attribute inside a <script> tag :

  <script src="..." integrity="<hash>" />

When set, the browser will check the script source hash before using it.

[lidel]

Would be great to use CID in SRI but it requires native IPFS in the browser. Extension won't make it possible, no APIs for that. Maybe one day :)

The CID itself is more than a plain hash of the file. When a file is big it is chunked into blocks and CID is a hash of the root of a DAG, and user agent is unable to verify it without learning additional metadata.

I wrote more details in ipfs/in-web-browsers#128 (let's continue there)