brave-browser: IPFS origins report wrong document.location.origin

Description

Brave returns an unexpected document location.origin when browsing on pages through the ipfs: and ipns: protocol schemes. Other properties in the location object (e.g. .protocol) are effected too.

Steps to Reproduce

  1. Open any ipfs://hashhash or ipns://hashhash
  2. Open the developer tools console
  3. Execute document.location.origin

Expected result:

The function should return ipfs://hashhash.

Actual result:

It returns http://hashhash.ipfs.localhost:12345/

Reproduces how often:

Every time.

Brave version (brave://version info)

1.19.67

Version/Channel Information:

Beta only feature.

Miscellaneous Information:

This bug makes it more difficult to develop mixed HTTPS/IPFS websites as its more difficult to determine correctly what protocol scheme is being used. This might have unexpected security issues. The Chromium Extension API return the expected origin. However, some extensions get very confused when the tab.url and its document.location don’t match.

About this issue

  • Original URL
  • State: open
  • Created 4 years ago
  • Comments: 15 (4 by maintainers)

Most upvoted comments

cc @yrliou @bbondy

i think it’s fine to have the apparent origin be ipfs:// as long as domain isolation is preserved (https://github.com/brave/brave-browser/issues/12367). ex: ipfs://foo and ipfs://bar should be treated as third parties according to the same rules as http://a.com and http://b.com.

re: what web features are accessible to an ipfs:// page, options are:

  1. treat it like remote HTTP, which means no access to web features which require a secure context (https://developer.mozilla.org/en-US/docs/Web/Security/Secure_Contexts/features_restricted_to_secure_contexts)
  2. treat it like local HTTP, which counts as a secure context (https://w3c.github.io/webappsec-secure-contexts/#is-origin-trustworthy)
  3. treat it like HTTPS, which also counts as a secure context but may have some unintended side effects, such as HTTP mixed content being blocked.

i think 2 makes the most sense since IPFS documents are served locally.