Fetch API with IPFS url's are blocked by cross-site tracking prevention

[markg85]

Hi,

What i'm trying to do is download a file via javascript from IPFS.
In my Brave browser i have a local node enabled and put the local gateway to that node. So i'm not running the brave build in IPFS node!

Now when you access a IPFS file the URL will be translated to a localhost one for the local gateway that is setup. This triggers the "Cross-site tracking" prevention shield and subsequently blocks the URL.

I am using the Fetch API here but i suppose using XMLHttpRequest would show the same issue. I haven't tried that.

In your browser console (F12 -> console tab) type this:

let res = await fetch("https://ipfs.io/ipfs/bafkreidp3bolj5revf34mugbvmuir4k4lt6n2oys6mbu7piknyucktaonu")

You might need to wait a few seconds but it will eventually come back with this exact error:

VM340:1 GET http://localhost:8080/ipfs/bafkreidp3bolj5revf34mugbvmuir4k4lt6n2oys6mbu7piknyucktaonu net::ERR_BLOCKED_BY_CLIENT
(anonymous) @ VM340:1
Uncaught TypeError: Failed to fetch

Now if we try the exact same IPFS resource but with the IPFS protocol handles then it (weirdly...) works:

let res = await fetch("ipfs://bafkreidp3bolj5revf34mugbvmuir4k4lt6n2oys6mbu7piknyucktaonu")

This throws no error and works just fine. Which is ironic because this is likely internally translated to the very same localhost URL.

I suppose a fix would be to ignore localhost for the cross-site tracking prevention.
Let me know if more information is needed, i'd be happy to help!

[da2x]

Which is ironic because this is likely internally translated to the very same localhost URL.
[…] I suppose a fix would be to ignore localhost for the cross-site tracking prevention.

But you didn’t link to loclahost. You linked to https://ipfs.io/ and was surprised a different origin was treated as a different origin.

[markg85]

Which is ironic because this is likely internally translated to the very same localhost URL.
[…] I suppose a fix would be to ignore localhost for the cross-site tracking prevention.

But you didn’t link to loclahost. You linked to https://ipfs.io/ and was surprised a different origin was treated as a different origin.

Exactly.
One should probably not link to localhost for public sites, it kinda tends to not work unless everyone in the world uses IPFS nodes. We're not in that ideal world yet so i linked to the one accessible by everyone (thushttps://ipfs.io/).

Your reply does make me wonder a bit as to what you mean? I can't quite figure out if you agree with me that it's a bug or if you think that i should've used localhost instead (the later would be wrong in my opinion).

[lidel]

@markg85 are you doing that successful await fetch("ipfs://baf..") on a page loaded over ipfs:// or ipns:// ?

My understanding is Brave decided that fetch from ipfs:// should only be possible when top-level document is loaded over IPFS scheme. This makes it explicit and does not impact how security model of server-driven HTTP websites work.

You could do a test request for ipfs://{cid} to detect native support, and if it fails, just use some public gateway that has cross-origin requests safelisted.

[markg85]

Hi @lidel

I did say it in my original post but i'll summarize it again.
Go to any url loaded over a local IPFS gateway. So your url starts with http://.

Open a developer console and type:

let res = await fetch("ipfs://bafkreidp3bolj5revf34mugbvmuir4k4lt6n2oys6mbu7piknyucktaonu")

This works.

Now type:

let res = await fetch("https://ipfs.io/ipfs/bafkreidp3bolj5revf34mugbvmuir4k4lt6n2oys6mbu7piknyucktaonu")

This fails

In my opinion these results make no logical sense at all. The site is loaded on http://. I'm expecting either both to work or both to fail. In this case the ipfs:// one works and the https:// one fails. I don't get why, it's not logical at all.

Now if we compare this to what @da2x said then both should fail. Clearly the ipfs:// one doesn't so something is wrong.
Also, please, again, note that you can test this in your browser on every ipfs site that runs on the local gateway.

I don't know how i can explain this any more clear. Please specifically ask what you want me to show or demonstrate if this isn't clear.

[branfts]

Any update on this? Workarounds?

If the goal is for more adoption of web3... this certainly stands to be a hinderance. I've just spent time reading about the somewhat similar case of blocking https from ipfs loaded sites (and it makes sense)... however blocking ipfs from https loaded sites does not seem to fit the same threat model?! And certainly, this seems to be a bug rather than a feature add...

I'm currently working on a web3 app which is (still) loaded via https and yet fetches ipfs images and other content. I have failover (ipfs fails then use an ipfs gateway link) built in, however it's rather frustrating to see...

Loading the entire site over ipfs is not an option at this time.

[webel]

Also wondering how to get around this, don't fancy the gateway solution but I guess that's the way to go.

[vadimstruts]

The IPFS local node and scheme has been deprecated