Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Should IPFS paths at different gateways share the same ipfs.files chroot? #453

Closed
lidel opened this issue Apr 13, 2018 · 3 comments
Closed
Labels
area/window-ipfs Issues related to IPFS API exposed on every page status/deferred Conscious decision to pause or backlog topic/security Work related to security

Comments

@lidel
Copy link
Member

lidel commented Apr 13, 2018

It gets really interesting when accessing ipfs.files via window.ipfs at IPNS site.

ipfs.files.write('/test-from-' + window.location.host, Buffer.from('ehlo'), { create: true }).then(() => console.log('done'))

I've run the snippet above at /ipns/ipfs.io and:

  • when executed at Public Gateway https://ipfs.io/ipns/ipfs.io/
    creates /dapps/https/ipfs.io/ipns/ipfs.io/test-from-ipfs.io
  • when executed at Local Gateway http://127.0.0.1:8080/ipns/ipfs.io/
    creates /dapps/http/127.0.0.1%3A8080/ipns/ipfs.io/test-from-127.0.0.1:8080

Do we want to merge IPFS scopes (/ipns/ and /ipfs/) by removing HTTP component so that both above URLs will have access to the same ipfs.files root at /dapps/ipns/ipfs.io/ ?

Pros:

  • makes dapps gateway-agnostic, developers can use ipfs.files API and do not worry about the way user loads the dapp, no reports of "missing user data" if someone switches between gateways

Cons:

  • It effectively breaks the Origin perimeter of the HTTP-based web. Is that a problem?
    • Short answer: probably not?
    • Longer: in theory someone could try MITM by establishing fake gateway by hosting modified JS app from 'a valid IPFS path' of another app. Assuming user allows access to ipfs.files via ACL for this new gateway, it still won't work. window.ipfs is added by the extension, and the same extension automatically detects requests to IPFS Paths and replaces them with requests to either custom or public gateway defined in Preferences. This means malicious JS will never get loaded, as we use 'trusted' gateway instead, even when embedded js-ipfs is used.
@lidel lidel added topic/security Work related to security area/window-ipfs Issues related to IPFS API exposed on every page labels Apr 13, 2018
@olizilla
Copy link
Member

I'm in favour of this. A DNSLINK ipns name is only as secure as the DNS layer, but https currently has the same issue.

More generally I'm working on the theory that a CID is usefully equivalent to an Origin as it provides a built in mechanism to detect and fail on MITM style attacks... this snippet from the Origin spec is helpful

Two actors in the Web platform that share an origin are assumed to trust each other and to have the same authority. Actors with differing origins are considered potentially hostile versus each other, and are isolated from each other to varying degrees.
https://html.spec.whatwg.org/multipage/origin.html#origin

@lidel
Copy link
Member Author

lidel commented Sep 21, 2018

Note to self: we should park this until #593 lands.

@lidel lidel added the status/deferred Conscious decision to pause or backlog label Sep 22, 2018
@lidel
Copy link
Member Author

lidel commented Oct 19, 2020

Closing due to #589 (comment)

@lidel lidel closed this as completed Oct 19, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/window-ipfs Issues related to IPFS API exposed on every page status/deferred Conscious decision to pause or backlog topic/security Work related to security
Projects
None yet
Development

No branches or pull requests

2 participants