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

Minimize use of custom protocol handler #7

Closed
lidel opened this issue Mar 25, 2015 · 4 comments
Closed

Minimize use of custom protocol handler #7

lidel opened this issue Mar 25, 2015 · 4 comments
Labels
kind/bug A bug in existing code (including security flaws)
Milestone

Comments

@lidel
Copy link
Member

lidel commented Mar 25, 2015

While having thesupport for 'virtual' URI like ipfs:QmTkzDwWqPbnAh5YiV5VwcTLnGdwSNsNTn2aDxdXBFca7D is handy and provides us with nice abstraction, we should always redirect from virtual protocol to real URI from a HTTP gateway.

Gist is this: always display real URI in address bar (but also provide an easy way of obtaining IPFS links).

@lidel lidel added the kind/bug A bug in existing code (including security flaws) label Mar 25, 2015
@lidel lidel added this to the v1.0.0 milestone Mar 25, 2015
@lidel lidel closed this as completed in 1d04228 Mar 25, 2015
lidel added a commit that referenced this issue Mar 25, 2015
@lidel lidel modified the milestones: v0.2.0, v1.0.0 Mar 25, 2015
@the8472
Copy link
Contributor

the8472 commented Dec 14, 2015

could you elaborate on the security problems that lead to this change?

It would be nice if we could find a way around them.

@lidel
Copy link
Member Author

lidel commented Dec 15, 2015

I think my rationale back then was that we should not "fake" /ipfs/ URLs in address bar.

As of today, Firefox does not provide native IPFS support by itself nor via addon.
We use HTTP gateway and user should see gateway host name when looking at the address bar.

When things like js-ipfs are mature enough, we could provide native IPFS support via addon and then we could legitimately display raw IPFS paths like /ipfs/QmTAsnXoWmLZQEpvyZscrReFzqxP3pvULfGVgpJuayrp1w in the address bar.

@the8472
Copy link
Contributor

the8472 commented Dec 15, 2015

Hrm, issue #3 made it sound like there were some security issues.

I'd like "fake" ipfs:// in the url bar when running a custom gateway. From my POV it's basically just shifting the loading from firefox to an external process under my control.

Would it be reasonable to make this optional behavior?

@lidel
Copy link
Member Author

lidel commented Dec 15, 2015

#3 was a false-positive security error that was a result of mixing assets using "fake" and "real" URLs. It should be possible to fix it by having "fake" URLs everywhere, but I was not motivated enough to pursue this charade at the time :-)

FYI some time after #3 IPFS community had rather long discussions about "canonical" and "legacy" IPFS addressees here and here which can be summarized by this quote from #16 about path-like "canonical ones" (by jbenet):

[..] "ipfs links" should be exactly the same in both the Web, and UNIX. meaning: /ipfs/<hash>/<path>, NOT ipfs://<hash>/<path> (explicitly disobeying the scheme that the W3C insists on).

(we also support "legacy" ones in form of ipfs:[/]* and fs:[/]*).

So to keep this short:

  • I am okay with someone (not me :-^-) ) implementing "fake" URL (probably best is to use native /ipfs/<hash>) in the address bar as an optional behaviour (enabled via checkbox on the preferences screen).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/bug A bug in existing code (including security flaws)
Projects
None yet
Development

No branches or pull requests

2 participants