Skip to content

Instantly share code, notes, and snippets.

@Shados

Shados/Browserhunt.md

Last active August 8, 2019 00:44
Show Gist options
  • Star 1 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save Shados/e89a1752f97f7007595ca189b0fbbd67 to your computer and use it in GitHub Desktop.
Save Shados/e89a1752f97f7007595ca189b0fbbd67 to your computer and use it in GitHub Desktop.
Download ZIP
The Great Browser Hunt, 2018/2019 Edition
Raw
Browserhunt.md

Browser Hunt

Baseline requirements:

  • Open source
  • Runs on Linux (Windows and OS X would be nice too, but I don't fucking care that much)
  • Extensible (Even "has no plugin system, but really clean source and a maintainer who is very open to PRs" is good enough for me)
    • WebExtensions do not fucking count. They are only interesting to me if the browser implements a far wider and more powerful set of WebExtension APIs than is typical -- and even then, I don't like JS
  • Does not have an incomprehensibly fucked build process
    • This includes not having a makefile that downloads random binaries and/or dependency sources off of the internet, compiles them, then builds against those
    • Basically, it needs to not be literally insane to package it in a Nix expression
  • Not based on webkit1-gtk
  • Ideally not based on webkit2-gtk either
    • Doesn't performantly support any kind of proxy-per-tab setup
    • From briefly investigating, changing it to do so likely wouldn't be too hard to do so, it is more a limitation in webkit2-gtk than webkit2 itself, and in the worst case it could be kind of hacked into it by implementing PAC support, but it is probably more time spent digging around in webkit2-gtk code than I really want

Engines

  • WebKit:
    • WebKit1 is a hard 'no' due to security issues
    • WebKit2 is ok, but:
    • I have some concerns as to the sanity of the devs...
    • It horribly abuses virtual memory / overcommit as a really derp hardening measure called the 'gigacage'
    • This obviously does not work if you have overcommit disabled
    • There's a patch to automatically disable the gigagage on-allocation-failure in Linux, which would let it at least "work" when overcommit is disabled
    • Except: The patch doesn't actually do that, because it disables one check but leaves others later in the flow of control. Net effect: It prints an error complaining that the gigacage is disabled but shouldn't be, and then crashes webkit. Most applications that use/embed webkit, including I think all webkit2-gtk applications, then immediately restart the webkit process, entering a crash loop. Better yet, it appears that when webkit crashes itself this way, it does so uncleanly and leaks a little bit of memory, so this crash loop will then eat all of your RAM after a while.
    • You can avoid this behaviour by setting an environment variable GIGACAGE_ENALBED=no, in which case it won't even try to use it to start with, and will disable the "check-and-crash" routine, but... what the actual fuck? And note: WebKit behaves somewhat less reliably without the gigacage enabled.
    • As per these comments [1, 2] on the webkit issue tracker thread, it is possible to implement the gigacage in a way that works on systems without memory overcommit, and doing so would make it trivial to provide an additional feature: a segfault handler that catches OOB memory accesses in the gigacage and logs them, which would be kather useful both for debugging and for malware/exploit analysis
    • Instead, it was decided not to do so due to speculative performance concerns
  • QtWebEngine: This engine is parts of Blink embedded in Qt, basically.
    • I did some digging and I think you can sanely do proxy-per-tab with QtWebEngine, although I'll need to confirm that later
    • Confirmed: can do proxy-per-tab, either by doing custom QNetworkProxy stuff, or by using its inbuilt support for PAC files. Set an environment variable named auto_proxy to a URL that returns a PAC file, and use the PAC file to do your host-specific proxying etc.

Candidate Browsers

  • Falkon (nee QupZilla):
    • QtWebEngine
    • Python plugins
    • QML plugins, some psuedo-WebExtension APIs are supported
      • Intended to provide sanboxed/restricted plugins, as opposed to unrestricted C++ and Python plugins
      • Is meant to provide APIs 'similar' to WebExtension APIs to ease porting, but does not look like directly supporting WebExtensions in this form is a goal
    • Using it kinda feels like using old Opera
    • Need to try out their plugin dev
  • LuaKit
    • Either one of the shipped LuaKit modules or webkit has a memory leak
    • Rather than "extensible in Lua" it's more that most of the "normal browser functionality" is written in Lua -- there's no explicit extension/plugin system per se, although you could easily roll your own
    • I rather like the free-form development style that offers, though
  • qutebrowser
    • Can use either QtWebKit or QtWebEngine under the hood, so that's a plus
    • vim-like navigation
    • Extensible in Python 3
    • Tried it out briefly, but need to spend some more time with it before I make any real judgements... I don't like its default binds though

To-Test

  • Basilisk:
    • A... more recent Firefox fork (~FF52) by the Pale Moon team
    • Both it and Pale Moon will continue to be developed
    • Essential differences from Pale Moon:
      • Australis-based UI
      • Support for WASM, WebRTC, DRM, and NPAPI plugins
      • Experimental WebExtension support
  • Pale Moon:
    • Forked off of Firefox back in 2009
    • I've previously had various site compatibility issues with Pale Moon (ones not fixed by faking the UA), but that was several years back, so I'll give it another shot
    • Has historically had issues with media playbook, especially re. MSE
    • Still sticking with single-process mode; honestly not the worst decision from my perspective, at least in theory, but I have no idea how sane their tab sandboxing is
  • Viper Browser:
    • Native userscript and adblock filter list support
    • Has a 'tab hibernation' feature, although it looks like at this point you have to manually manage suspend/resume of tabs
    • Has some kind of extension system, I need to look into it more, non-zero chance it is non-functional at this point
    • QtWebEngine based
    • Obscure
  • vimb webkit2-gtk
  • webkitten:
    • Written in Rust
    • Less of a browser, and more of a framework or toolkit for embedding a browser engine in one or more Rust-managed windows, and scripting that with Lua (I think)
    • Kinda like LuaKit in that regard, but not tied to WebKit specifically
    • Obscure, no visible activity in the past two years, seems likely the dev has stopped using it?
    • Despite this, and despite not having a working build to test, I'm strangely tempted to get it working... just the combination of Rust and cute name maybe?

Excluded Browsers

Notable Excluded Candidates

  • Dillo:
    • Bespoke browser engine
    • Not useful for general purpose browsing so much, because it deliberately has no JS support
    • Potentially very useful for embedding HTML rendering into other applications, especially if you don't necessarily trust the input -- e.g. for rendering HTML emails
    • Smol
    • Fast
  • Midori:
    • Midori 6 release was very recent (October 31) and involves some major changes
    • webkit2
    • GTK+3
    • (Re)Written in Vala
      • Maybe Vala's documentation, tooling, and community have improved since I was trying it out several years back, otherwise I'd count that as a negative point
    • Extensions in either Vala or Python
      • Can't find any documentation on either, nor any examples of the latter
      • Quite possible that Python extensions are just done via Vala/PyGobj bindings?
      • On looking into it further, I was partly right: Plugin support is provided by the "libpeas" project, which provides a generic GObject plugin framework, with "on demand" plugin loading for plugins written in C (or Vala, as it compiles to C), Python, and Lua
      • Currently only the C and Python loaders are being used, it appears
      • Not sure on the relevant technical details yet for Python and Lua (e.g. one interpreter/vm per extension? Can you use PyPy or LuaJIT? Python 2 or 3?)
    • Claims native userscript, userstyle, and adblock filter list support
      • In practice, looks like it only has adblock filters right now
      • Not sure what "customizable side panels" are meant to be, either, can't see any sign of them after poking through the UI
    • Extremely early days for this (rewritten) version
    • Source link
  • NetSurf
    • Bespoke browser engine
    • Support for some rather obscure OS
    • Smol
    • Fast
    • No javascript support at this point, it's being worked on however
  • Otter Browser:
    • Not extensible, would be interesting otherwise
    • Has plans to support WebExtensions at some point in the future...
  • Sandcat:
    • Written in Delphi/Pascal... Getting someone to poke with questions might be hard as I only know a single Dephi dev, although she does write it professionally
    • CEF-based
    • Extensible in Lua, UI extensible in Sciter's TIScript or Lua
    • Intended for use by penetration testers
    • Actually pretty interesting if I ever want to do some penetration testing, but otherwise probably not that usable
  • Sciter
    • Not open source (!), the licenses don't look too bad…
    • Bespoke browser engine, but primarily intended for rendering application UIs rather than browsing sites
    • Custom extended ECMAScript variant (TIScript) rather than JS per se, the additions are rather nice
    • Ludicrously responsive devs, and they seem pretty competent
    • Primary author is a literal rocket scientist
    • Smol
    • Fast
  • Waterfox:
    • Basically attempts to forward-port legacy Firefox extension and UI functionality into post-Quantum firefox
    • Partly successful at this
    • Future is unclear at best, will be interesting to see if they manage to release an FF 60.x-based version as intended
    • I've been using it as an interim measure, but it is showing its age

Failed Baseline

  • dwb:
    • webkit1
    • ancient, unmaintained
  • Crusta:
    • What the hell are "split tabs"? Tiling tabs within a window? I think old Opera did that...
    • QtWebEngine
    • Not extensible at this point, WebExtensions are planned
  • Dooble
    • QtWebEngine based
    • Did some digging in the source, does not appear to be extensible
  • Fiber:
    • in-development KDE browser by Ken Vermette
    • pre-alpha vaporware
    • "everything is a (web?)extension"
  • jumanji:
    • webkit1
    • From the same people as zathura, a rather nice vim-like front-end to various document viewers (notably including mupdf)
  • Seamonkey:
    • Gecko-based
    • Just not sure there's any real advantage to Seamonkey over PaleMoon or Basilisk, at least for my usage...
  • surf:
    • I've tried the whole "handle tabs outside the browser" thing previously with Uzbl, it really doesn't work that well
    • You do generally want "tabs" to be a first-class citizen within the browser, so that they can be manipulated at the right level of abstraction
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment