The Unclear Impact

@floppy @mte90 @mastodon the “messaging browser” space seems awfully fragmented, and projects often implode (go proprietary, or just unmaintained)

i think the latest development is the ferdi maintainer (already itself a fork of franz) kicking everyone off that project, which led to the creation of https://ferdium.org/ (disclaimer: i was a ferdi contributon, and got invited to ferdium)

i don’t quite understand while this area of free software has a higher than average rate of developer burnout (or maybe it hasn’t, just the area is a bit niche)

annoyingly, some webapps have nonsensical limitations when run outside of chrome (probably just user agent sniffing / fingerprinting nowadays), so going DIY with firefox containers would require spoofing user agents and other browser APIs. so starting from something already on chromium (i.e., electron) might be the most sensible option, even if electron development (while maintaining any semblance of security and sandboxing) is a lot of pain

@floppy @mastodon @mte90 yeah, it’s fighting fire (overengineered web platforms and javascript fingerprinting) with more fire (overengineered javascript workarounds). i’d consider it a ‘harm reduction’ measure, mostly: folks are often forced to use webapps by employers/schools, and having a single client still beats installing a bunch of proprietary apps that could spy on them

@floppy @mastodon @mte90 in fact, firefox might even have and edge here, because extensions have a single background page that can communicate with any container. chromium afaik (or at least electron) can install extensions per persistent partition (~container), so each extension needs a separate background page per partition, leading to higher resource use

(somewhat foolishly, one of my side projects is implementing an electron ‘messaging browser’ from scratch, with ‘modern’ electron security practices. realizing that i can’t really have browser extensions with any semblance of efficiency was quite a disappointment)

@floppy @mastodon @mte90

So in other words, Electron-based solutions scale badly regarding extensibility

not necessarily. you could offload some processing into the electron main process (risky from a sandboxing pov), into a background page for all services (a single renderer process), or even many background pages for different kinds of processing with a single origin (afaik still a single renderer process, but more strict isolation than a single background page). but it’s a pain to implement

Do you know how many extensions run in background by default?

i don’t think any extensions would be loaded by default – the heavy resource usage might come from having a renderer process for each service (but that’s just process isolation for origins, which is also the default in firefox since quantum) or, more likely, from having a whole different persistent partition per service (this is where firefox could be more lightweight). but the issue is worsened if a ‘messaging browser’ wants to support webextensions (they use background pages for processing and data that is shared between tabs, like a filter list trie in adblock)

not that you’d really want webextensions if manifest v3 hits – a custom add-on mechanism could get around this an direct all IPC requests to a single background page from all partition (but again, pain to implement)

I have some less frequently used apps configured, but disabled.

the main issue here is that process isolation and separate persistent partitions need a lot of resources for loaded pages, but are crucial for proper security (and messaging apps are likely to be higher-value targets than just browsing, so disabling security features is probably a bad idea)

one way to solve this is to move most services into a single partition (i.e., container). cross-origin isolation can still isolate most of the cookies, but multiple instances of the same webapp (with different accounts) still have to live in different partitions. i think wavebox started to push this approach after they went proprietary (they also forked chromium instead of building on electron)

the other way is to just unload most of the webpages and just load them on demand, or maybe periodically to check for new messages. ferdi(um) implements this, but obviously, there is some delay for the notifications

the last option would be to unload the webpages, then implement ‘mini’ versions (the slack electron app calls them like this in their blog) that are much lighter weight than a full webpage. unfortunately, for proprietary webapps, this requires reverse engineering, and may even lead to a banned account if the official client is not properly impersonated

Btw, fyi, this is one good DIY guide for Firefox.

thanks! this looks really cool

@floppy @mastodon @mte90 (sorry for the late reply, i had a bunch of stuff to deal with at uni)

manifest v3 is likely to change the extension API in a way that makes, e.g., ad blocking less effective: https://adblockplus.org/blog/we-are-proud-to-support-the-blocking-community-s-feedback-to-chromium-s-manifest-v3

afaik currently chromium can still load v2 extensions, and firefox has indicated that they wish to maintain support for ad blocking (https://blog.mozilla.org/addons/2021/05/27/manifest-v3-update/ ), but the situation might change in the future

in that case, going the route that brave went (erhm, minus the questionable choices about crypto and affiliate links) might be feasible: a library like https://github.com/brave/adblock-rust or https://github.com/ghostery/adblocker or https://www.npmjs.com/package/@gorhill/ubo-core could be integrated natively into an electron-based app (without any chromium webextension API involved)

‘messaging browsers’ kinda have their own extension API, anyways (‘recipes’ and user scripts), so the wheel seems to be at least partially already reinvented

@floppy @mastodon @mte90 i suppose a PWA runs in the same chromium profile as the webpages you visit, so it at least shares a bunch of background processes (network service and GPU process at least) with the main browser

sandboxes services run in separate chromium ‘profiles’ (persistent partitions), but still shared the network and GPU processes with the host electron app. so there’s one kind of overhead (vs PWA) due to running a second browser, and another kind due to the multiple partitions (but not as severe as running a separate browser / electron app for each service)

here’s the blog post from slack about the ‘slim-slack’ they implemented in their electron app: https://slack.engineering/reducing-slacks-memory-footprint/

looks like the architecture has changed somewhat recently and they moved the slim-slack into the main process: https://slack.engineering/growing-pains-migrating-slacks-desktop-app-to-browserview/