I will attempt to explain in laymen’s lingo how blockchains such as Steem which can store and serve media files, could potentially be used to **dramatically improve and decentralize web browser security**.

This is illustrating by-example the revolutionary ecosystem applications of decentralized content storage and serving from blockchains such as Steem.

## Securing Money On The Web

https://pixabay.com/static/uploads/photo/2016/02/15/23/40/security-1202344_960_720.png

The security of our web browser is becoming critical for example when our monetarily valuable credentials (e.g. Steem or online banking passwords) are accessible to the scripts that run in the browser. Although the recent cracking of numerous Steem(it) private keys wasn’t due to a web browser vulnerability¹ (the attacker presumably partook the lowest hanging fruit first), web browser security will remain a threat since for example [the private key for posting to Steem(it) must be always accessible to the web browser](https://steemit.com/steem/@pharesim/bounty-for-completion-of-native-javascript-steem-signer#@theoretical/re-trogdor-re-pharesim-re-mrosenquist-re-pharesim-bounty-for-completion-of-native-javascript-steem-signer-20160802t003022609z) (unless the user will be prompted to type in their password every time they click anything on the site, which would be absurd).

## Centralized Web Security

Browsers are vulnerable to XSS (Cross-Site Scripting) attacks which inject the attacker’s scripts inside the site’s scripts. The first line of defense is to employ [careful, tedious programming methods](https://www.owasp.org/index.php/Cross-site_Scripting_(XSS)) to attempt to not commit mistakes which enable the attacker to inject scripts. However these mistakes can still occur, so the second line of defense² is to whitelist only trusted web addresses from which scripts can be loaded for the site; and [disable any other ways to load scripts](https://www.w3.org/TR/CSP2/#directive-script-src). However, this [Content Security Policy standard](https://developer.mozilla.org/en-US/docs/Web/Security/CSP/Introducing_Content_Security_Policy) **suffers from the weaknesses of centralization and centralized trust**, because it requires the site to [only load its scripts from a whitelist of web addresses](https://w3c.github.io/webappsec-csp/#fetch-integration) and to trust that the site is always in control over the files served from those web addresses (which can be compromised for example by a hacker or even hypothetically if the certificate authorities for those web addresses are compromised).

## Decentralized Content

The aforementioned centralization requirement of browser Content Security Policy could be debilitating for one aspect of future Steemit improvements where we would really like for all the content (including the site’s scripts) to be loadable from any node on the Steem network, so as to squelch the distributed-denial-of-service (DDoS) attacks that had caused recent site outages, to make the system impervious to government take down orders, and other resiliency, censorship-resistance, and scaling benefits. But there is no way in current Content Security Policy to implement such decentralization and insure the scripts are the authentic ones, because current Content Security Policy whitelists only web addresses and doesn’t incorporate any cryptographic signatures.

## Decentralized Web Security

The blockchain and cryptography can provide the solution. Since for example the author of Steemit can cryptographically sign the scripts that power the Steemit site and store them on the blockchain, then it should be possible to modify web browsers so they allow a whitelist of allowed scripts based on the public key of the signer of the scripts. Thus for example only the author of Steemit would be able to sign scripts which are permissioned to power the Steemit site and the web browser which loads the Steemit site (from any decentralized nodes of the blockchain) would know to only load resources signed by the author of Steemit. The epiphany is the authority for the scripts that power a site **shifts from a centralized, attackable resource (of web address, web server, and certificate authority) to a decentralized, cryptographically secure signature**.

Anne van Kesteren who is the listed author of several web standards documents such as Fetch, [wrote about](https://annevankesteren.nl/2016/07/web-computing) the importance of decentralization in web computing security.

> There are two computing models today that have mass-market appeal, are safe-by-default, are app-driven (no OS access), and provide some degree of sandboxing for their apps: Web and Store. The major difference is that Web computing has decentralized publishing (**it would be distributed if not for domain registrars and certificate authorities**) and Store computing is by definition centralized. Decentralizing Store computing is unlikely to ever succeed and I have argued before that such a system cannot reasonably exist as part of Web computing. (Arguably Web computing is a form of centralized computing. Certificate authorities are ultimately grounded in a list managed by the browser or the OS the browser runs in.) ...

---------

¹ The Steem private keys were cracked because the corresponding public keys were publicly accessible on the blockchain which enabled the attacker to run a high-speed dictionary attack, which was effective against users who had chosen a weak password since the entropy of the private keys were derived from the user chosen passwords. In other words, the attacker was able to repeatedly trial potential matches for the users’ password at perhaps millions or billions per second. Normally websites rate-limit login attempts to prevent dictionary attacks (since a human can’t sign-in millions of times per second), but this firewall isn’t possible when the public keys must be public. The only solution was to force users to use a strong password with sufficient randomized entropy.

² [HTTP access control (CORS)](https://developer.mozilla.org/en-US/docs/Web/HTTP/Access_control_CORS) is third line of defense which enables web addresses to whitelist which sites may load their scripts, which seems to be mostly impotent, [complexity smell](https://fetch.spec.whatwg.org/#main-fetch) “security theater”.