> The gateway could potentially also lie about the content it is serving you. In the future, Brave plans to verify content retrieved through gateways by using its CID.
Does anyone know why this was omitted? Verifying a hash is straightforward. Both the old simple MerkleDAG format [0] and the new complicated IPLD format [1] allow fetching and verifying individual files inside a CID-addressed bundle.
> Both requests you make and content you serve are observable by network peers.
That is a deceptive way to say, "if you click the 'Enable IPFS' button then your computer will continually publish your browsing history to the world." And they make it too easy to enable. It's just a button below the address bar [0]. And the button has a deceptive name, "Enable IPFS". The browser can use IPFS through a gateway, so IPFS is already enabled.
There are many important projects to improve privacy and reduce tracking and monitoring of user behavior on the network: DNS over HTTPS, TLS Encrypted SNI, blocking third-party cookies, proxy services (incorrectly called VPNs), anti-fingerprinting work in browsers, and mobile privacy features. Is there any work on making IPFS resistant to tracking? Right now, IPFS seems like a step backward for privacy.
> By default, Brave will load the URI being requested via a public HTTP gateway
> If IPFS is not yet configured, the user will have the IPFS page loaded through the gateway https://dweb.link. [2]
Fortunately, Brave shows the gateway URL in the browser address bar. This lets users know which company is tracking them. For Brave users (dweb.link users), this is Protocol Labs https://protocol.ai , a VC-funded company in California.
> Does anyone know why this was omitted? Verifying a hash is straightforward.
A CID for a file is not a simple hash, it represents the root of a merkledag of a file tree and chunks of the file. Getting the dag metadata requires a p2p connection under normal circumstances. A public HTTP gateway, given the CID, returns file content, not the file tree or merkledag the CID is a hash over.
It's doable, but totally reasonable that they didn't include this in 1.0.
Does anyone know why this was omitted? Verifying a hash is straightforward. Both the old simple MerkleDAG format [0] and the new complicated IPLD format [1] allow fetching and verifying individual files inside a CID-addressed bundle.
> Both requests you make and content you serve are observable by network peers.
That is a deceptive way to say, "if you click the 'Enable IPFS' button then your computer will continually publish your browsing history to the world." And they make it too easy to enable. It's just a button below the address bar [0]. And the button has a deceptive name, "Enable IPFS". The browser can use IPFS through a gateway, so IPFS is already enabled.
There are many important projects to improve privacy and reduce tracking and monitoring of user behavior on the network: DNS over HTTPS, TLS Encrypted SNI, blocking third-party cookies, proxy services (incorrectly called VPNs), anti-fingerprinting work in browsers, and mobile privacy features. Is there any work on making IPFS resistant to tracking? Right now, IPFS seems like a step backward for privacy.
> By default, Brave will load the URI being requested via a public HTTP gateway
> If IPFS is not yet configured, the user will have the IPFS page loaded through the gateway https://dweb.link. [2]
Fortunately, Brave shows the gateway URL in the browser address bar. This lets users know which company is tracking them. For Brave users (dweb.link users), this is Protocol Labs https://protocol.ai , a VC-funded company in California.
[0] https://github.com/ipfs-inactive/papers/blob/master/ipfs-cap...
[1] https://github.com/ipld/specs/
[2] https://github.com/brave/brave-browser/issues/10220