Why are we looking at changing the browser?
In the first instance, we decided to look at the various possibilities going forwards with the browser because:
- It would be nice not to have to maintain browser code or fight against upstream changes (Beaker has been reorganised a lot since we forked it, and became much more DAT focussed).
- It would be nice not to have to reinvent the wheel, browser-wise.
- It would be nice to offer a more fully featured / better-performing browser.
- It would be nice for a codebase that offered mobile alternatives in a similar fashion.
Given those ideas we started looking at what possibilities exist:
- Chrome
- Firefox
- Brave
- A ground-up rewrite of an Electron browser.
Traditional browsers could be used. But there are many caveats:
- Need to use extension (to avoid trying to hack core code)
- Need to lockdown extensions for release / when in use (to avoid security issues)
- Large foreign codebases.
- Is the code reliable / consistent / subject to change of APIs frequently? (Might the way they implement changes lock us out at some future date? [changing licensing, implementation details etc])
The problem with extensions:
Looking further at the possibility of chrome extensions (which all three mainstream browsersā implementations are based on), there are a few things of note:
- Security. (Lack of)
- Protocol: The chrome extension setup which all three old browsers use does not allow
safe:
protocol creation. - API injection: The chrome extension setup does not allow code injection / IPC to not standard protocols.
Investigating further we found we could easily / cleanly get safe:
working in Brave, without too many core tweaks (though still some are needed).
We could easily knee-cap Brave to prevent HTTP and we can lock down extensions there.
BUT. Brave, as a fork of electron, would require us to implement a lot of changes to achieve a SAFE-API as we have it now.
Otherwise any implementation for chrome/ff would likely be purely via extensions, which would limit the protocol to be of the web+safe://
variety and also need some whitelist http
workarounds for recreating APIs. Both of which are less than ideal.
Thusly, looking at the three olde browsers, Brave emerges as a frontrunner, especially when considering itās anti-ad/tracking, pro-privacy standpoints. (Although they do want to serve targeted ads. Could we remove this easily? / Does that become a maintenance nightmare?)
A question:
All of which leads us, in roundabout fashion to a question: what de we want from a SAFE Browser?. Which has been a subject of some debate in the community.
Right now, though, Iād wager no-one is using SAFE Browser as their main browser to access clearnet.
Even given a more polished browser, would they want to?
Would that be secure?
Itās been noted that even Brave, with many devs and an anti-fingerprinting, privacy central goal can still be IDād as a browser (although Iām not sure to what extent). Is that a security risk?
Technical issues.
If we look at Brave in the least hacky fashion, providing a fork with protocol and code injection for APIs there are some technical things of note:
- We need to rework the API wrapper (safe-node-js). Braveās electron fork is not compatible with our current node implementation (which is based upon
node-ffi
, which is incompatible with Braveāsmuon
electron fork; [it cant build against the unknown version of āelectronā, it seems]). - Weād have to port to neon, or perhaps WebAssembly.
- This requires creation of a Rust API (which we donāt currently have)
Neon seems like a reasonably straightforward replacement for FFI. Though itās not been tested or benchmarked with SAFE code as yet. POCs were positive.
WebAssembly
WASM could be great (using built rust code directly in the browser would remove a layer of abstraction / unify the API interface; instead of having safe-node-app
and window.safeXXX
interfaces which are inconsistent/ more things to maintain).
It would also mean no cross compiling for different systems here. Simplifying build process and potentially removing some layers of code.
It could also mean, clearnet sites could implement some safe functionalities (via uploading webassembly files to the clearnet site, it could potentially be run in any browser). (Whether or not you think that should happen, with an OS project and the possibility of easily compiling to web assemblyā¦ it likely will happen at some juncture.)
Web Assembly Questions
Web assembly is relatively new. Our brief testing was positive although we still need to test further / more conclusively.
Given the potential for unifying APIs (and wasm is in development for node too, under experimental flags), and the potential here to compile directly from rust. Itās worth looking at more.
Back to a browser
After this wee technical sojourn, we come back to the question: āhow should we continue with a browser?ā.
Grow Your Own
Weāve learnt a lot from Beaker, and it has some great patterns, but itās also been under very active development (which is cool!), and has become much more DAT focussed (also cool!), but that limits its usefulness for our purposes.
Weāre fighting to maintain an upstream branch that is no longer super relevant, all the while complicating feature development. We should not be doing this.
So the final idea is setting up a custom SAFE Browser using electron. The benefits to doing this ourselves being a simpler/cleaner more modular UI which should let us move faster.
There are aspects of reinventing the wheel (wellā¦ thatās pretty much the whole aspect), but if we consider what is a basic browser, itās also not that complicated an endeavor. A lot of code could be lifted from the current SAFE implementations of the store etc in the browser.
to HTTP, or not to HTTP
In the end, the way forward is grounded in this question.
If we want it to be a main clearnet browserā¦ there are obstacles, but itās probably do-able with a fork of some kind. There are many workarounds needed for Brave due to their custom - undocumented - electron fork. But it should work.
But would a clearnet browser actually be used this way? And should we be doing this workaround/hack development at all? (And how much time does that take vs starting a fresh electron build?)
If we did decide to go down the Brave route, WebAssembly would be required for DOM APIs (which requires more rust work). And if we have that well, a clearnet extension could be enabled much more easily. Then users would have the choiceā¦ And we would offer only a basic, but secure option.
And if we donāt HTTPā¦ Well then we take our learnings from forking Beaker and rebuild a simpler/cleaner codebase, removing we assume unused features like HTTP and closing up the security surfaceā¦ There are some aspects of wheel reinvention, yes. But probably only as much work as updating to latest beaker would offer us, without the controlā¦ And once weāre levelā¦ Weāre free to iterate much more easily.
We could then investigate WebAssembly on the side. Taking it up when we have the capacity for implementing the required rust layer changes and incorporating it thenā¦
Waitā¦ what about mobile?
Ah yes. Well, while there are Brave/Firefox versions for mobile, it seems they are in the end, separate code-bases and so thereās no benefit of choosing a desktop browser to match.