IPFS Browser Update

by Dietrich Ayala on 2019-10-08

Decentralization can feel slow in providing user-centric approaches to the internet’s biggest problems. Right now, software that is fully in the control of the user is often too technical, too fragile, and too time-consuming to be the default choice.

This is a companion discussion topic for the original entry at https://ipfs.io/blog/2019-10-08-ipfs-browsers-update

If browsers start participating in the IPFS P2P network automatically (or as the JS implementation gets more robust and app developers include it in their app, and it starts connecting to peers automatically upon arriving on a site), I wonder if the corporate world will put a damper on adoption? In a corporate setting, if a computer on the network suddenly starts making dozens of connections to computers around the world, that can get flagged as suspicious, since most P2P networks that behave that way are questionable for a work environment (torrenting, crypto mining, etc.).

Are there any efforts started to raise awareness for Sysadmins/IT staff that this could be a P2P network with some good corporate effects? And/or making the option within the JS and browser-based nodes to limit the number of peers they connect to (“gateways” or a known set of whitelisted nodes)?

Well, for corporate browsers who shouldnt acces internet directly you can setup a private ipfs network with only one ipfs node with acces to internet like any proxy setup

Deploy a private IPFS network in 5 steps by Sander van Laar

IPFS is a robust candidate for any CDN setup and some big players notices that already Cloudflare Distributed Web Gateway

@totedati If a website that used IPFS content pointed to one IPFS gateway (e.g. Cloudflare’s), that would act a lot like today’s standard “Web 2.0” sites, so I wouldn’t foresee raising any red flags. But what I was referring to here is not having a site contact a single gateway, but rather the site being an IPFS node itself, and connecting to dozens of IPFS nodes. When a single workstation/website reaches out to many different hosts at once, that can be a red flag to security scanners since that can be a symptom of being part of a botnet or similar.

A solution that’s halfway between these would be having not just one “gateway” being contacted, but several (in case that one gateway is down, or can’t find the peer who has that particular IPFS hash). Having a “failback” could be accomplished with JavaScript on an individual website, though it would be nice to have that implemented as a “peers whitelist” function within the IPFS JS Client implementation, such that it would still be a real IPFS node, just with a limited peer set.

I’ve had AWS EC2 instances flagged by Amazon for that exact reason. It’s not a big deal, they just send an email alerting you to suspicious activity but it can be a pain when it’s your admin people, “No, no, it’s ok. Everything’s fine.” It’s especially difficult to tell them, “And please ignore this and all future scary notices.”