Allow IPFS in private windows

[bbondy]

I think we could allow IPFS in private windows in the future by keeping a separate configuration and cache that gets automatically cleared when the session ends.

cc @diracdeltas for thoughts

[diracdeltas]

is it possible to just disable IPFS caching for the private window? if i'm visiting something in a private window, i probably don't want to announce to the world that i'm looking at it until the session ends.

[bbondy]

cc @lidel

[lidel]

[..] i probably don't want to announce to the world that i'm looking at it until the session ends

@diracdeltas this is a bit futile: it is impossible to fetch something from IPFS unless you announce to the world that you want to read it (traverse DHT, leaking your intent to DHT nodes) or by manually connecting to a node that you know has the data you want (but this requires off-band exchange of addresses). We are researching a "blinded DHT" where CIDs are double-hashed, but afaik we are not there yet.

However, it should be possible to run an ephemeral, disposable IPFS node in "leech" mode by disabling reproviding
(setting Reprovider.Interval to 0)

Pros:

• each private session would get unique PeerID, making it impossible to track user over time
• your node will never announce your IPs on DHT as a provider for blocks in local datastore (cache)
• you could remove datastore from disk after private window is closed

Downsides:

• you need to run separate go-ipfs process with different IPFS_PATH and set different ports for that read-only instance
• with reproviding disabled, you won't be able to publish anything (but i guess it would be acceptable for private window)

cc @autonome

[diracdeltas]

this is a bit futile: it is impossible to fetch something from IPFS unless you announce to the world that you want to read it

understood that the right way to use IPFS fundamentally goes against what most users expect from private browsing mode, so if we do enable in private browsing we should have some kind of interstitial page making sure the user is ok with this.

[da2x]

Visiting a DNSLink-enabled page in a private window currently redirects to IPFS and stores the page and its resources in the local IPFS cache. This is probably not intended.

Brave should garbage collect IPFS after closing a private window that has accessed IPFS content.

[MicahZoltu]

I'm not a fan of the solution that was implemented in #14147. By completely disabling IPFS access in private windows it makes it so I cannot leverage the features private browsing offers like clearing cookies after the session ends. I recognize the desire to protect against IPFS caching files in private browsing, but it would be nice if there was a solution that could both allow users to benefit from cookie/storage clearance of private windows while also protecting against the cache.

As a user, I tend to do most browsing in private windows because I don't like tracking and it helps keep my browser history clean, and as more and more sites get deployed to IPFS using ENS/IPNS I am now forced to choose whether I want cookie clearance or the ability to browse the web in a decentralized way.

---

understood that the right way to use IPFS fundamentally goes against what most users expect from private browsing mode, so if we do enable in private browsing we should have some kind of interstitial page making sure the user is ok with this.

I don't think what was said is any different than DNS. When you navigate to a site on DNS you are "announcing to the world" that you are accessing that site. If you do so through a VPN or Tor you are announcing to your VPN provider. If you use IPFS (without a VPN) you are announcing to a random set of peers, and if you use IPFS with a VPN you are announcing to your VPN provider. I don't think for the file lookup it is necessary to do anything special. However, I do agree that the IPFS cache is problematic for private browsing mode.