Enable more permissive CSP / CORS for *.ipfs.w3s.link origins

[cdata]

Hello, I have the following use case for loading content from w3s.link (and IPFS gateways in general):

I have a web application that is designed to be loaded up in an IPFS gateway. After it is loaded, it receives a CIDv1 as part of its input. The CID refers to a DAG of blocks, and the app procedes to incrementally load a subtree of the DAG through the same gateway that the web app itself was loaded from.

If I try to load the web app through w3s.link, it fails to load additional blocks because of the CSP configuration. I get the following error:

Refused to connect to '$SOME_CID.ipfs.w3s.link/' because it violates the following Content Security Policy directive: "connect-src 'self' blob: data:"

At the time of filing this issue, you can see an example of the behavior here: https://bafybeie6mblmk4ei2tqko5nkutsnv52gd4pqyb5pt57aqwazlpprssxapa.ipfs.w3s.link/?id=did%3Akey%3Az6Mkq8Y52E9Rf62hp2geWZZFKEDcmmfTU9ifwQmYJits3PNm&version=bafy2bzacecdfrl2e2nizzgxo3cnirdy7txmi67izs5cj7sljrf6y3ulmbvnks&slug=foo

After speaking with @gozala , they suggested that it might be possible for the related CSP settings to be relaxed so that *.ipfs.w3s.link can fetch content from each other.

Would this be possible?

[vasco-santos]

Hi @cdata Thanks for reaching out. I am submitting a PR for this

[Gozala]

@vasco-santos it might be a good idea to include ipfs.io/ipfs/ and dweb.link along with them

[vasco-santos]

@Gozala added them as well as nftstorage.link to https://github.com/web3-storage/w3link/pull/28 . Can you review this? I will propagate to nftstorage.link as well once we conclude it

[awmuncy]

We'd like to use w3s.link to host application that allow users to link the wallet on their mobile phone. These are often connected via a websocket server. Examples include, Rainbow wallet, MetaMask, Coinbase wallet, WalletConnect wallets and those each have different origins the app might reach out to. Here's the list of origins I've found:

• https://cloudflare-eth.com/
• wss://*.bridge.walletconnect.org
• wss://www.walletlink.org/rpc

I say *.bridge.walletconnect.org because it reached out to several different sub-subdomains of bridge.walletconnect.org.

We also have gateways to the Tableland network.

• tableland.network
• testnet.tableland.network
• testnets.tableland.network

[cdata]

@awmuncy I don't speak for Web3.storage, but I feel obligated to point out that your suggestion presents a security risk to users. One of the reasons why these CSP and CORS restrictions are in place is to prevent arbitrary content loaded through an IPFS gateway from (for example) opening up a wallet transaction prompt in an attempt to trick a user to sign something.

The proposed change in #28 is justified because none of the origins that are whitelisted have exploitable user state associated with them (in theory they are all stateless content gateways; in practice, some nuance is called for when identifying meaningful statefulness on the hypertext web).

[Gozala]

@awmuncy here is my take on the subject https://github.com/nftstorage/nft.storage/issues/2143#issuecomment-1223247526, in summary I don't want us to be in a position to decide which hosts are ok and which aren't, not to mention that at some point we'll run out of space trying to put all the host in the CSP header.

Long term I would like to enable content to override the CSPs as they see fit, but when they do allow users to make a call if they want to proceed with caution or abort.

Other than that I believe there are plans to offer private gateway feature to the users so they can configure CSPs to fit their use cases, which might be a good fit for your use case.

[Gozala]

It is also worth highlighting how original proposal in the issue here is different. If browser supports ipfs:// URLs natively it is reasonable to expect that content would be able to load any other content under the same protocol unless explicitly forbidden by the content CSPs.

That is not the case for the cross protocol content however as it would be subject to mixed content security policies and it requires careful consideration and work to outline how that would play out across ipfs:// x https://. While it seems reasonable to go from https:// to ipfs:// it is much less so other way round because all of the content addressing guarantees fall out of window if you can embed content that is mutable.

In other words I think we should explore app use cases separately from content use cases.

[cdata]

Hey folks, looks like the CSP changes in #28 are in production. Unfortunately, we're still finding ourselves in violation of the policy.

Here is a more mature version of the demo app I originally shared for your consideration so that you can see how we are using the gateway to request blocks: https://bafybeida5q4ewi7yrardkjaphuhrbwbyhdolda2r6hrwcoc2nsmuzlvwla.ipfs.w3s.link/?id=did:key:z6Mkw5d3acoQqn97UjRcGit7J7uWunixxxDKTgkr58CFHLfo&version=bafy2bzacecsjls67zqx25dcvbu6p4z4rsdkm2k6hanhd5qowrvwmhtov2sjpo

[vasco-santos]

Thanks for reporting this @cdata . Looks like @Gozala fixed the issue, just released new version of gateway and looking in console there are no more policy errors and content seems to be loading fine

[awmuncy]

@Gozala @cdata I'm peaceful with this. I really like the idea of respecting the CSP set in an HTML doc. That is to say, if the CSP isn't set in a meta tag in the doc, default to the strict policy. But if a doc does contain such a header, parse it and use that CSP instead of the default. This would give me (creator if the app/content in the ipfs file) control of outside connections without opening everyone else up to my whims.

[Gozala]

But if a doc does contain such a header, parse it and use that CSP instead of the default. This would give me (creator if the app/content in the ipfs file) control of outside connections without opening everyone else up to my whims.

Exactly! There’s a nuance however, we’d want such content to be behind some prompt so user can make a conscious decision to proceed. I imagine we’d redirect to a page that explains what app will be able to do. If user chooses to proceed it will set a cookie and navigate back to original page with appropriate CSP headers this time.

Maybe something slightly different implementation details, but roughly same direction

[dchoi27]

hey folks, just want to make sure everyone has what they need here. i think @cdata and @awmuncy had separate requests for exceptions to CSPs - not sure if the PRs merged were intended to take care of both sets of requests, or just @cdata's?

[cdata]

Hey @dchoi27 my original feature request has been satisfied. It might make sense for @awmuncy to file a separate issue to cover their request.

[vasco-santos]

We handled everything here and also in #34

Closing this. Feel free to reopen if there is still something we should address