Understanding Security Concerns around Browsers

[flyingzumwalt]

This is an endeavor that extends far beyond the IPFS project. Much of this work is already under way, with many projects, researchers, and teams working on it. It will take years to fully tackle. Treat this github issue as a reference point showing how we (the IPFS team) are approaching it -- both addressing it pragmatically in the short term and also setting the trajectory for long-term solutions.

1. In the short term (immediately), identify the basic security, safety & privacy measures that all browsers (and browser extensions) should adhere to when interacting with the decentralized web.
2. In the mid-term, Develop a Pragmatic Framework for Understanding Security Concerns for a Decentralized Web Browser, so that we can establish a roadmap and work towards browser adoption and so that that decentralized web browsers can provide as much security, safety & privacy as possible.
3. For the long term, Develop a Comprehensive Framework for Understanding Security Concerns for a Decentralized Web Browser, so that people implementing decentralized web browsers can provide security, safety & privacy assurances that surpass what's possible on the centralized web.

The established web browsers (Firefox, Chrome, Opera, etc.) are designed for the centralized web. One of their main roles in the web is to protect the user from malicious content. In order to fulfill that role on the open web, they have developed a system of security models, policies, and workarounds (Single origin policy, CORS, etc.) that are often confusing and frustrating but are nonetheless fundamentally important. Those protections allow us to browse the web with a moderate level of confidence that we can load a web pages without them crashing our computers, wiping our filesystem, stealing our banking information, or turning our machines into unwitting sleeper nodes on a botnet. [Despite our best efforts, these things do still happen, but browsers make it very hard to perform attacks like that via content in the browser.]

We're asking the browser manufacturers to expand their view to embrace the decentralized web. In essence, we're asking them to make their "centralized web" browsers also function as "decentralized web" browsers. This isn't just about allowing millions of users to benefit from the explosion of innovation around decentralized technologies. It's also about carrying accumulated knowledge from the centralized web into the decentralized we. The browser manufacturers have spent millions of human-hours figuring out how to keep the web safe and how to keep it open while the human population has spent billions of hours testing this work in real scenarios. We need to translate that accumulated knowledge into a decentralized context.

A Sampling of Security Concerns to Address

Note: A lot of these security concerns are the things preventing us from putting out a 1.0 of IPFS. We know these things need to be addressed in order for us to say "IPFS is no longer alpha". Until then, IPFS is alpha software.

Some of the Security Concerns that arise as soon as you install a Web Extension that runs an IPFS node and allows any javascript on any page to call any method on that API (this is exactly what #12, #41 and #42 would achieve if we don't add any security controls):

• What happens when someone puts malicious javascript, spyware, etc in an html page? How do we prevent that code from
  • pulling down a bunch of bad content into your repo and making you serve it
  • crashing your machine by downloading content until your hard drive is full
  • scanning through all the content you have in your local repo
  • modifying the stuff that's already in your repo (ie. deleting stuff, modifying data, etc.)
  • opening a bunch of ports, thus making you vulnerable to countless network-based exploits
  • etc
• What happens when 2 browser tabs are open and one tab is reading sensitive content? How do we prevent the second tab from accessing the sensitive content?

A sampling of Strategies for Addressing these Security Concerns

Aside: What is Dat doing about this stuff? Do they have solutions? They might have important insights, or are they just ignoring some of this stuff for now?

Some Strategies:

• Support strategies for encrypting content so that a provider can control who is able to read/decrypt a piece of content.
  • Strong candidate: implement a capabilities model that imitates TAHOE-LAFS
• Re-use the Single-origin policy
  • must be reconciled with decentralized patterns -- the SOP was designed for centralized web. In a decentralized context, the threat models are different AND you can't make the same assumptions about infrastructure (ie. if you're not relying on locations, what constitutes a domain? -- see Sort out an Address Scheme that fits with Browser Security Model #3, Contribute to the suborigin spec? #13)
• Establish decentralized equivalents of CORS, ie. IPFS-CORS, IPNS-CORS

Why We need a Cohesive Framework

cohesive: cohering or tending to cohere; well-integrated; unified [dictionary.com]

The existing browser security models have evolved iteratively over 25 years. They're deeply bound to the assumption that you're browsing through a centralized web. This makes it very hard, and ill-advised, to assume that we can merely tweak the existing solutions and attempt to map them to a decentralized context because:

1. Some of the threat vectors don't apply in a decentralized, content-addressed context
2. There are new threat vectors that don't exist in a centralized context
3. Some of the established solutions rely on centralized patterns in order to work

The way to reconcile these is to step back and take stock of the threat vectors that the browsers are attempting to address as well as the associated use cases. Based on that, we can figure out the correct path forward.

Until we do this, there won't be a clear path for making "reasonably safe" browsers for the decentralized web. Keep in mind, however, that this won't stop people from doing amazing, compelling things with decentralized technologies. Web browsers weren't safe for most of the 90s but that didn't stop the world wide web from surging into existence. The wave is happening. We just have to do our best to keep everyone safe in the process.

How to Proceed?

1. In the short term (immediately), what can we do to provide basic security, safety & privacy measures?
2. In the mid-term, how can we develop a pragmatic framework that decentralized web browsers can use to provide as much security, safety & privacy as possible?
3. For the long term, what discussions should we set in motion, revive, contribute to, etc. in order to set the decentralized web on the right path towards providing security, safety & privacy assurances that surpass what's possible on the centralized web?

[flyingzumwalt]

A starting point for such a "framework" would be a listing of

• the threat vectors
• examples of how those threat vectors manifest in a decentralized context
• explanations/examples of how those threat vectors manifest in the centralized context
• references to the solutions that browsers currently use to address (or not address) those threats
• references to the possible solutions for addressing those threats in a decentralized context

[flyingzumwalt]

How would people feel about me making a "threat vector" label in the in-web-browsers repo, so we can create a new issue for each threat vector that people call out and then gradually add the info I've described in the previous comment.

I prefer that over having issues like "reader privacy", which is a giant feature that could mean different things for different people and is an issue that extends beyond browsers.

Alternatively, we could create a "security concern" or "security feature" label in ipfs/notes and let the conversations accumulate there based on feature, like reader privacy.

Contrasting those 2 approaches: a "threat vector" issue would identify a threat vector so that we can document it and eventually tackle it. We could close that issue when the vector is covered, or if we mark it "won't fix". By contrast, a "security feature" discussion in ipfs/notes would not have a clear end-point, nor would it explicitly call out work that needs to happen.

[lidel]

For anyone interested in "reader privacy" there is an ongoing discussion at ipfs/ipfs-companion#507