| I don't know what you can do about browsers besides use Firefox. But as far as other stuff, I hope people will give distributed p2p possibilities some consideration in terms of usage or development. For example YaCy works pretty well as a p2p search engine. There are some others that I haven't tried. Back to the browser stuff. The problem is the browser has a full operating system in it at this point. There are too many APIs to compete. What could make competing browsers viable might be something like the following. Imagine a web browser that does not support JavaScript. Instead it emphasize fast rendering, has a state of the art web assembly implementation, and some kind of ABI/API for things like UI, UDP, etc. such as OpenGL (or a simpler UI system). It only allows a subset of CSS and HTML, maybe only Flexbox or something. It it could be just restricted to old-fashioned HTML rendering. But anyway it won't be able to have the scope of Firefox and Chrome. I guess the biggest problem is if you don't support the whole ginourmous HTML5 featureset (starting with JavaScript) then most websites will not work at all. They either will not load or will be totally scrambled. Maybe some kind of p2p content-centric web could become popular and have it's own streamlined and simplified browser. Or maybe there could be a new browser tailored for augmented reality that could become popular and compete with Chrome. |
The additional HTML5 suite of APIs would theoretically be supported by a plugin model, but given the depth of integration of some of the APIs, this might be a great deal more work than it sounds, and even more difficult to prevent the proliferation of questionable plugins to this backend. It would probably have to resemble something closer to the Linux distribution model; where an installed instance of the browser would come with a set of whitelisted plugins, with no real ability for the non-expert user to add plugins.
More important to me is the idea of making use of client certificates to attest identity more strongly, together with masking the use of those certificates over third-party channels. So if I went to facebook.com I would present a cert "abcd" (a self-signed certificate), and if I went to yelp.com I would present "bcde". If yelp loaded content from facebook.com, I would present "cdef". Similarly for cookie handling, at least initially.
My hope would be that websites would associate multiple client certs with a given "user" on their site, but unless the user explicitly associates a cert with an identity there's no way (outside of fingerprinting, etc.) to make that association; all third-party interactions show as incognito sessions. Eventually the goal would be that (if this technique is widely adopted) that cookies become kind of useless in favor of strongly attested server-side identity (rather than using bearer tokens in the form of cookies) that can be associated with session data.