search

brave / brave-browser

Brave browser for Android, iOS, Linux, macOS, Windows.
https://brave.com
Mozilla Public License 2.0
17.84k stars 2.33k forks source link

consider blocking non-IPFS subresources on IPFS pages #20522

Open cmoog opened 2 years ago

cmoog commented 2 years ago

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:

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:

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 commented 2 years ago

CCing @stephendonner 👍

stephendonner commented 2 years ago

cc @lidel and @spylogsster

diracdeltas commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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

:+1: 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.

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