Gateways and Content-Security-Policy

[lidel]

This is related to #157 and Origin isolation story in general.

Let's discuss if it makes sense to improve Gateway specs (path, subdomain) to include a default Content Security Policy (CSP),
and if so, what would be a sane default. Please comment below.

About CSP

The HTTP Content-Security-Policy response header allows web site administrators to control resources the user agent is allowed to load for a given page.

– https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy

IPFS use

@Gozala suggested Csetting SP to limit the utility of a gateway in phishing campaigns:

Gateways could set Content-Security-Policy which would preventing accessing any external content (Any URLs outside of gateway domain), rendering phishing attacks ineffective, since it would be impossible to steal a victims data.

– https://gozala.io/workspace/#/page/ipfs%20content-security-policy

Prior art

nftstorage.link

Value set by nftstorage.link team (nftstorage/nftstorage.link#172 (comment), cc @vasco-santos) :

Content-Security-Policy: default-src 'self' 'unsafe-inline' blob: data: ; form-action 'self' ; navigate-to 'self'

[Gozala]

@lidel we have identified some of problems with bunch of content that links to stuff outside of ipfs realm as those links get blocked by CSPs. While it is a sticky problem I feel like it is a good idea to recognize and communicate with ecosystem what linking out from IPFS to HTTP(S) may entail:

1. Guarantees of content addressing become somewhat unreliable if you link outside of IPFS. Specifically navigating to the same CID may load a very different page if you link to resources on HTTP(S) as those could point to different resources or simply become unavailable.
2. I highly doubt there will be a mixed protocol future supported by mainstream browsers. That is to say when ipfs:// protocol is natively supported by mainstream browsers it is very likely that it will not be able to embed resource from other protocols. I have gone through implementation exercise with libdweb and came to conclusion that by fusing two different security models you end up with worst of both not best of both. I think we as a ecosystem should aim for the better future that doesn't inherit all the pitfalls from the http(s) model which enables all kind of tracking which becomes possible when you allow dialing "places" (even through image / css embeds) as opposed linking to "content" (which user can specify "place" to grab from).

I realize that simply cutting off all the HTTP(S) links today may be impractical & can prevent IPFS from getting wider adoption. I do think there is a middleground however where we encourage use of only IPFS links by default, but provide way to opt-out which would incur some security prompts warnings to the end user. I described this idea in the context of nft.storage here nftstorage/nft.storage#2143 (comment) but I think it can be generalized across all gateways. Providing copy of that message below for convenience:

I have created change to whitelist those hosts as a stop gap solution until we develop something more sophisticated. In long term I would not like us to be in the position of whitelisting certain hosts across all of the NFTs as the list of things can grow beyond HTTP header limits.

Instead I think we should:

1. Have a default CSP header that prevents loading content from third party hosts.

2. Have a way to override default CSP header. In fact in HTML you can specify CSPs via <meta http-equiv="Content-Security-Policy", which we could use as a hint to override default CSP directives.

3. Have review mechanism for content that overrides default CSP header that can ensure it's not an attack vector.

4. Gate not yet reviewed content with a user warning that allows user to proceed with caution (explaining what hosts content may communicate with).

5. Create a review automation for trusted hosts like https://polygon-rpc.com/, github etc... to reduce unecessary inconvenience.

As side note we don't necessarily need to go into html parsing business on gateways, instead we could just define a custom block format for content with CSP overrides, that way regular content will load with default CSPs, but same content could be wrapped with the custom block to define different CSPs allowing gateways to intercept those without having to do any HTML parsing.

[RangerMauve]

Personally, I've been wanting to make IPFS more privileged than other protocols and give it the ability to bypass CSP so that p2p web apps can talk to HTTP servers without needing to be on the same origin. e.g. to enable aggressive interoperability. 🤷

It would be nice if somebody could create a p2p frontend for something like discord or soundcloud without needing to turn it into a separate native app.

[Gozala]

@RangerMauve to be clear I'm not opposed to granting more privileges, but I think those need to be deliberate hatches that user agent can intercept to actually provide agency to the user. That is if specific application needs access to everything everywhere it could set CSPs to * but that SHOULD incur making a user aware of consequences and allowing user to decide whether to grant full access, limit it to specific domain or what.

It would be nice if somebody could create a p2p frontend for something like discord or soundcloud without needing to turn it into a separate native app.

I don't think what I've described would prevent any of this, but it would allow user to choose to grant said apps to communicate with with https://discord.com/ and not https://adtracker.io/.