
IPFS Companion 2.2.0 brings window.ipfs to your Browser - lidel
https://blog.ipfs.io/35-ipfs-companion-2-2-0/#hn2
======
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.

------
fogzen
Dat+Beaker is way ahead of IPFS in tooling, developer mindshare, consumer
friendly UI, etc. With $250 million it's pretty shocking they don't seem more
worried/focused on that.

~~~
StavrosK
Can dat be accessed without that browser? I haven't found something like the
IPFS node, and that's what made me not want to run dat.

Also, ZeroNet seems more advanced than both in terms of things that actually
work today.

~~~
carussell
Hashbase exists, and in theory most Dat web apps could do a read-only version
for legacy browsers, but since the tooling isn't there, you'd have to work out
something by hand. The Dat ecosystem has pretty bad support for polyfills and
bridging to the HTTP web right now. Many Dat demos I see today just fail hard
over HTTP, maybe with a best-viewed-in message if the dev took some effort,
but in principle it doesn't need to be that way.

------
johnhenry
I'd really love to see something like this show up as a proposal with the W3C
(or the WHATWG -- I'm not entirely sure who's the authority on this?).

~~~
diggan
Yes, this is definitely something we're planning to once we get closer to a v1
of all the parts. Today it's probably a bit too early but specifications are a
core part of our general pipeline (but we can still get better)

The goal is to end up with standardized implementations so we can have
multiple implementations and a open protocol.

(Disclaimer: I work on IPFS)

------
amq
How do I know that the embedded mode works? It says "IPFS resource loaded via
Public Gateway".

~~~
lidel
Keep in mind that HTTP gateways are provided just for convenience. Due to
WebExtension API limitations embedded node can't act as a local HTTP gateway
and extension falls back to public gateway. I imagine it was what you were
experiencing.

Use window.ipfs property to play with pure IPFS (without HTTP gateway):
window.ipfs.id(console.log)
window.ipfs.add(Buffer.from('hello')).then(console.log)
window.ipfs.cat('/ipfs/QmWfVY9y3xjsixTgbd9AorQxH7VtMpzfx2HaWtsoUYecaX').then((data)
=> console.log(new String(data))) More info: [https://github.com/ipfs-
shipyard/ipfs-companion/blob/master/...](https://github.com/ipfs-
shipyard/ipfs-companion/blob/master/docs/window.ipfs.md)

