[asymmetric]

Is it possible to completely/selectively prevent websites from knowing I have IPFS running in my browser?

Or does this extensions have the same issues as Metamask[0], which means there's no way to hide the fact that one has the extension installed?

This is a pretty important privacy feature, because I'm pretty sure the presence of such an extension massively increases the accuracy of targeting.

[kybernetikos]

I agree, and looking at their site, they don't seem to have taken steps to avoid this problem.

I wonder if we could have a standard api, like window.requestAPI('ipfs' or 'eth' or whatever) returns a Promise, and the user gets a 'page is requesting' bar like we do with location requests.

That way, you wouldn't be leaking information about your browser capabilities to pages that you don't wish to use those capabilities on.

[diggan]

The reason why window.ipfs is so great is that it opens up for a very easy migration path for when IPFS is embedded directly in the browsers.

So as a application developer, you would check if window.ipfs exists on the page, and if it doesn't, load js-ipfs and then the rest of the page can function the same way, no matter how ipfs was loaded on the page.

Unless we can be sure that when browsers implement IPFS, window.requestAPI('ipfs') would be the API, going the route we're taking now is the safest bet, unfortunately.

(Disclaimer: I work on IPFS)

[kybernetikos]

It's a pity that people aren't more concerned about the problems of leaking information to potentially hostile websites and polluting the window object with their project specific objects.

As the earlier poster mentioned, Metamask had this exact problem and it's been widely commented on. Of course the metamask problem is worse than the IPFS problem, as it marks a user as a potential target, whereas IPFS by itself probably doesn't do more than mark them as someone interested in the distributed web.

Your argument for why you do it seems to be a non-sequitur. Whatever you choose for how IPFS Companion exposes the api can be exactly the same as how the future browser exposes it. In fact as an early mover, you have an opportunity to do something positive and set a good direction for the built in functionality that comes later.

It's not a problem that there is consensus on how to solve yet, but I believe a standard solution built into browsers for exposing apis with capabilities we may not wish some sites to observe is needed. Polluting the window object with a host of api objects is likely to be a bad idea long term.

[diggan]

This is a interesting point and I agree, pretty important privacy feature that we should discuss more.

Off the top of my head, there could be some things we could do to help this, but the async/sync nature of `window.ipfs` makes it harder. If variable access was async, we could prompt before exposing it, but since we want to enable the browser extension to be a migration path to having native IPFS support in the browser, it becomes harder.

lide went ahead and opened a issue (https://github.com/ipfs-shipyard/ipfs-companion/issues/451), so if you're reading this and have ideas, we'd love to hear from you! We care deeply about this issue but was not required for the initial prototype we have now.

(Disclaimer: I work on IPFS)

[ghthor]

Thank you for bringing this up. I have a sticky task on my wall for this feature to bearded to metamask for this exact reason. Right now you're only protected by obscurity, the user needs to be able to whitelist domains or accept domain/dapp public keys.