Invalid ipfs:// links are redirected to dweb.link

[MicahZoltu]

Describe the bug When I try to navigate to ipfs://example in Firefox with IPFS Companion installed, I am sent to https://dweb.link/ipfs/example rather than my local gateway.

To Reproduce Steps to reproduce the behavior:

1. Install Firefox
2. Install IPFS Desktop
3. Install IPFS Companion
4. In IPFS companion settings remove all references to dweb.link, set a local gateway, and disable automatic mode.
5. Type ipfs://example in your address bar and press enter
6. Notice that you are redirected to dweb.link

Expected behavior When I tell IPFS companion to use my local gateway or a specific gateway, it doesn't sometimes use a public gateway.

Desktop (please complete the following information):

• OS: Windows
• Browser: Firefox
• Version: 2.20.1

Additional context This is also a privacy problem as it is sending information about what I am trying to lookup on IPFS to dweb.link. If I configure IPFS Companion to use my local gateway, this may be for privacy reasons and that is negated by this bug.

[whizzzkid]

Thanks for creating this issue @MicahZoltu, this indeed sounds like a serious concern. I tried reproducing this issue on both firefox and chrome and got redirected to my local node as per the steps described.

To investigate further can you please:

• share versions of firefox, ipfs-desktop and ipfs-companion that you have installed on your machine.
• validate your localgateway online and connected? one simple way is to visit webui at :/webui#/, which for a ipfs-desktop node look something like: http://127.0.0.1:5001/webui#/
• validate ipfs-companion has permissions, you can go to about:addons in firefox, click ipfs companion and see under the permissions tab.
• share other relevant info that you think might be useful to reproduce this.

[MicahZoltu]

Important Note: This redirect does not occur when I put in a valid IPFS hash for the URL. It only happens if I use an invalid IPFS hash (like example).

Firefox: 108.0.2 (64-bit) IPFS Desktop: 0.24.0 Kubo: 0.15.0 IPFS Companion: 2.20.1

Local gateway is on and working, and if I navigate to a valid ipfs://<cidv1> url everything works as expected.

All permission checkmarks are green in about:addons > IPFS Companion.

I have a personal non-local gateway configured in IPFS Companion as the Default Public Gateway and Default Public Subdomain Gateway. The configured non-local gateway doesn't actually support subdomains, I configured it mainly because I didn't want any untrusted URLs configured.

dweb.link does not appear anywhere in IPFS Companion or IPFS Desktop settings.

I do not have any other add-ons installed other than a password manager (unlikely to be registered as an ipfs scheme handler). In an InPrivate browser window with only IPFS Companion enabled for private browsing (so password manager is disabled), the same issue occurs.

[MicahZoltu]

I think I located the source of the problem:

It appears that IPFS Companion has setup a protocol handler that points at dweb.link (perhaps on install?) and it didn't remove it when I removed dweb.link.

[MicahZoltu]

Note: I'll leave these set for now in case there is value in debugging them. I'm also not sure if I delete them if they will just come back on the next update or something.

[whizzzkid]

@MicahZoltu thanks for more context, I am not seeing the same behaviour. I have the same protocol handler registered on my FF, but the action is selected to be ipfs-desktop it still redirects to my ipfs-desktop which opens the url in my default browser which loads the right path on my local node. If I change this to IPFS Companion, the behaviour changes and it automatically redirects to the localnode:

What's the action selected in your settings?

example: ipfs://bafybeictaik66c4r7ymn5g5zburzhedqafv6na2upkh5c6ukoojphu5qra/ -> IPFS-Desktop -> http://127.0.0.1:8081/ipfs/bafybeictaik66c4r7ymn5g5zburzhedqafv6na2upkh5c6ukoojphu5qra/

[MicahZoltu]

Use IPFS Companion: IPFS Protocol Handler is selected for all of them except dweb and web+dweb, same as yours. I don't have IPFS Desktop registered it seems, but Brave does appear to be registered as the default handler instead. When I go to ipfs:// scheme URIs, Brave doesn't open so I am assuming that handler isn't actually the one hit and instead it is the IPFS companion handler. I don't see a way to change the (default), though it appears that the selected one is what is actually used, not the (default) one.

If I switch the handler to Always ask and then try to navigate to ipfs://example I am presented with this prompt: Note that the IPFS Companion handler shows dweb.link below it, and selecting that handler results in redirecting to https://dweb.link/ipfs/example.

If you click on application details for the selected item in your screenshot, do you have dweb.link listed like I do or something else?

example: ipfs://bafybeictaik66c4r7ymn5g5zburzhedqafv6na2upkh5c6ukoojphu5qra/ -> IPFS-Desktop -> http://127.0.0.1:8081/ipfs/bafybeictaik66c4r7ymn5g5zburzhedqafv6na2upkh5c6ukoojphu5qra/

This takes me to http://bafybeictaik66c4r7ymn5g5zburzhedqafv6na2upkh5c6ukoojphu5qra.ipfs.localhost:8080/ as expected. The redirect to dweb.link only occurs when you put in an invalid CID (like ipfs://example)

[lidel]

The way protocol_handlers are registered in Firefox is static.

When a valid content address is passed to ?uri= then a redirect to a gateway URL is returned, and that is picked up by Companion. When you pass invalid value, there is no redirect, and you see error from dweb.link.

@whizzzkid iiuc the fix here is to detect and special-case requests to https://dweb.link/ip*s/?uri=%s and redirect them to custom gateway from Companion's preferences (for default it would be http://localhost:8080/ip*s/?uri=%s) , so they never hit dweb.link and work 100% locally.

[MicahZoltu]

In case anyone finds this issue and wants to understand more or help make this not so hacky: https://github.com/ipfs/devgrants/blob/master/targeted-grants/protocol-handler-api-for-browser-extensions.md

[MicahZoltu]

What is the reason why the protocol handler isn't dynamically registered? Dynamic registration would presumably allow IPFS Companion to switch the registration based on IPFS Companion configuration?

[lidel]

@MicahZoltu the devgrant you linked is from 2020, since then, we've been working with Igalia for the past two years to improve web APIs around this and other problems.

What is the reason why the protocol handler isn't dynamically registered?

This is what Firefox-specific API provides 🤷 Better than nothing (e.g., situation in Chromium).

For Chromium, which provides no protocol_handlers API, the best we can today do is asking the user to manually approve registerProtocolHandler call from extension's background page. Was not possible 2 years ago, small win.

This is not the best, as can't be automatic, requires user action every time. More details here.

[Martinligabue]

on brave it gets a similar issue with https://github.com/ipfs/kubo/ (anything that starts with this) that redirects to ipfs://kubo/releases/tag/v0.18.1 not sure if it's the same problem

[github-actions[bot]]

Oops, seems like we needed more information for this issue, please comment with more details or this issue will be closed in 7 days.

[MicahZoltu]

I believe that this is incorrectly tagged as needing author input and is just waiting on a fix like the one suggested by lidel above.

[github-actions[bot]]

Oops, seems like we needed more information for this issue, please comment with more details or this issue will be closed in 7 days.

[MicahZoltu]

Bump, cc @whizzzkid since you are the one who added the "needs author input" label but I don't think that is the case anymore.

[github-actions[bot]]

Oops, seems like we needed more information for this issue, please comment with more details or this issue will be closed in 7 days.