-
Notifications
You must be signed in to change notification settings - Fork 324
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
Comments
could you elaborate on the security problems that lead to this change? It would be nice if we could find a way around them. |
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. 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 |
Hrm, issue #3 made it sound like there were some security issues. I'd like "fake" Would it be reasonable to make this optional behavior? |
#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):
(we also support "legacy" ones in form of So to keep this short:
|
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).
The text was updated successfully, but these errors were encountered: