adam/ipfs-blog
1
0
Fork 0
mirror of https://github.com/ipfs/ipfs-blog.git synced 2026-08-09 10:22:56 +02:00
Code Issues Packages Projects Releases Wiki Activity

Update src/_blog/2023-05-multi-gateway-browser-client.md

Browse Source 
Co-authored-by: Marcin Rataj <lidel@lidel.org>
This commit is contained in:
John Turpish
2023-05-22 14:21:38 -04:00
committed by GitHub
parent 078dcc88a9
commit 3c6ba66c7e
1 changed files with 1 additions and 1 deletions
Download Patch File Download Diff File Expand all files Collapse all files
src/_blog/2023-05-multi-gateway-browser-client.md
+1 -1
View File
@@ -71,7 +71,7 @@ Including HTTP-client-only IPFS capabilities in a Chromium-based browser doesn't
### Security (vs. single public gateway)
Content-addressed networking involves a validation step to make sure that the data you received matches the [hash](https://docs.ipfs.tech/concepts/glossary/#hash) requested (it's a part of the CID). When you're requesting a file from an HTTP gateway, the verification of the content is delegated to the node running the gateway. Further, if you receive the file in its final form as a response to a single request, naively using just an HTTP client, it's no longer possible to verify locally.
Content-addressed networking involves a validation step to make sure that the data you received matches the [hash](https://docs.ipfs.tech/concepts/glossary/#hash) requested (it's a part of the CID). When you're requesting a file from an HTTP gateway, by default, the verification of the content is delegated to the node running the gateway. Further, if you receive the file in its final deserialized form as a response to a single request, naively using just an HTTP client, it's no longer possible to verify locally.
This is probably fine if the gateway you're talking to is one you're running locally. Presumably you trust that software as much as you trust your own browser.