consider blocking non-IPFS subresources on IPFS pages

[cmoog]

Description

Sites loaded with ipfs:// and ipns:// DO load HTTP sub resources even when "Shields UP for this site". As is indicated in the documentation, my expectation as a user is that only IPFS resources are resolved when viewing a page hosted on IPFS. Either the implementation doesn't properly match the spec or the spec is misleading (or I'm otherwise confused).

Steps to Reproduce

1. Load an IPFS html file with http(s) sub resources, using the Local Node resolution method.
2. Observe that the sub resources are loaded into the browser context.
3. Verify that "Shields UP for this site"

Some examples sites:

• ipfs://bafybeif2nqot44skgrerafdu7dn27fcwlgc5udwaojajchg4lppj6dkv6u/
• ipfs://bafybeig4ahvgjr7oardin6vbfaqg5v33ibvm4hcbzzwftebnm75oezglgi/

Actual result:

The browser loads HTTP(S) resources without blocking them.

Expected result:

No HTTP(S) sub resources should be resolved when accessing an IPFS/IPNS site.

Reproduces how often:

100%.

Brave version (brave://version info)

Brave: 1.34.80 Chromium: 97.0.4692.71 (Official Build) (x86_64)
Revision: adefa7837d02a07a604c1e6eff0b3a09422ab88d-refs/branch-heads/4692@{#1247}
OS: macOS Version 12.1 (Build 21C52)

Miscellaneous Information:

Related:

• HTTP subresources on ipfs are blocked even when Shields are disabled #14147
• Fix shield availability on ipfs pages brave-core#8106
• https://brave.com/ipfs-support/#:~:text=Additionally%2C%20Brave%20only%20allows%20subresources%20to%20be%20loaded%20over%20IPFS%20when%20the%20main%20page%20is%20loaded%20from%20IPFS.

When loading sites over IPFS, Brave instead uses the CID as the origin boundary. Additionally, Brave only allows subresources to be loaded over IPFS when the main page is loaded from IPFS.

[kjozwiak]

CCing @stephendonner 👍

[stephendonner]

cc @lidel and @spylogsster

[diracdeltas]

I think this is due to a misunderstanding of:

Additionally, Brave only allows subresources to be loaded over IPFS when the main page is loaded from IPFS.

What we meant by this is that an HTTP(S) page is not allowed to load IPFS resources, not to prevent an IPFS page from loading HTTP(S) resources.

Are there any security/privacy risks associated with the other way around?

[cmoog]

I think this is due to a misunderstanding of:

Ah, I see. Thank you for the clarification @diracdeltas.

Are there any security/privacy risks associated with the other way around?

Yes, absolutely. The principle value proposition of IPFS is that content is immutable and permanent. When sub-resources are loaded over http(s), both of these properties cease to hold. In particular, this behavior is non-obvious to the user unless they manually verify that the page has no http(s) dependencies.

What use is an "immutable" IPFS html file if all of its style/script/image dependencies are accessed over http(s) and mutable by whoever controls the http(s) host??

I can understand if the default behavior still allows http(s), but I think Brave should at least include an opt-in configuration option for blocking non-IPFS sub-resources.

[lidel]

Two interlinked topics here (or four, if we look at ipfs:// and ipns:// separately):

1. HTML on ipfs:// or ipns:// loading subresources over HTTP(S) (<script>, <style>, <img>, <video>, <iframe> etc)
2. JS on ipfs:// or ipns:// executing fetch('https://.. calls to talk to web2 service endpoints

👍 I think it is sensible for Brave to "detect use of HTTP on ipfs:// and ipns:// origins"
and show a warning about page using "mixed protocols" + Shields UP option to block them as opt-in.

❓ But we need to be mindful about the default behavior and its impact on existing websites. Areas of concern:

• Blocking (1) on ipfs:// sounds sensible, it will force people to "do the right thing" and publish all necessary subresources on IPFS, but if we start blocking all "mutable" things here, should we also block ipns://?
• Blocking (2) on ipns:// will break all DNSLink websites where third party JS is talking to some web2 style HTTP endpoint.
  • Full backend replacements based on CRDT+pubsub are (imo) not mature enough to fill the gap here. By being overly strict here we may be breaking dynamic websites that require web2-style backend, which over time will force people to remove DNSLink from these websites.