The Unclear Impact

So @ramboxapp@twitter.com is not mantained anymore, I need to switch to another app as I don't want to use a web services...

@mastodon I was thinking of that one but it was heavy years ago compared to rambox.. I will check with calm...

@mte90 latest rambox version was released yesterday:

https://github.com/ramboxapp/download/releases/tag/v2.0.3

are u sure is not maintained anymore? 🤔

@mastodon yes it is written in the page and the repo was archived https://github.com/ramboxapp/community-edition

As rambox community edition is the original that they converted as a web service with a SAAS (the link you shared)

Hi @mte90, how did you solve your problem?

After using Rambox myself for a long time, I finally had a look at the new-old non-community edition. That is, until I was required to get an account.

Bye bye, Rambox. Now I'm searching for new software too.

@mastodon

@mte90 @mastodon

While I like the idea of software like that brings all those webapps into one window, I never liked the lack of control in the pre-made Electron-based solutions.

Firefox provides per-tab containers and I wondered whether the DIY-route might be a good idea too.

free software rant adjacent

@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 blobfoxannoyed

free software rant adjacent

@kristof @floppy @mastodon I translate in a single word: javascript.

free software rant adjacent

@kristof Thanks for this insightful rant!

It's a strange corner of software development in general. I'm thankful people put work into "messaging browsers" (good term), but all those projects are elaborate (respectable) workarounds that shouldn't be needed in the first place. (Fediverse spirit talking, tear down the walled gardens!)

@mastodon @mte90

free software rant adjacent

@kristof

Regarding implementing a "messaging browser" DIY with Firefox: True, it might require user agent spoofing, but that's not hard with some addon (and I'm doing that already anyway together with some fingerprinting protection).

Perks like a (unified) unread messages counter is convenient, but I happily trade that for the certainty that my browser does not call home to it's developer and that web requests are transmitted safely and privately.

@mastodon @mte90

free software rant adjacent

@kristof

Oh and thanks for the link to Ferdium, I'll have a closer look!

@mastodon @mte90

re: free software rant adjacent

@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

re: free software rant adjacent

@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)

replies
1
announces
0
likes
1

re: free software rant adjacent

@kristof
That's interesting! So in other words, Electron-based solutions scale badly regarding extensibility. Do you know how many extensions run in background by default?

I currently don't go above eight active tabs/apps with my (outdated) Rambox, for memory reasons. I have some less frequently used apps configured, but disabled. It works, but it's annoying.

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

https://igalic.co/thoughts/2020-05-30-social-apps-in-firefox.html

@mastodon @mte90

re: free software rant adjacent

@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

re: free software rant adjacent

@kristof

Whoa, thanks for the clarification, this is very interesting! 🙏

You mention manifest v3. Do you have more information on added possibilities and constraints/requirements?

I'm not too embedded in this context, but a "custom add-on mechanism" sounds a bit like re-inventing the wheel? (Although that seems to have a tradition especially in web-related technology. *rant*)

(1/3)

@mastodon @mte90

re: free software rant adjacent

@kristof

Thank you for the remarks on the necessity of resource-heavy containers for security reasons. I'm aware and I do support this solution (sandboxing), I just do not support the problem at all.

That is that so many clients for important things like messaging require that many resources _and_ that virtually every developer does it and the number of apps a person needs to use just seems to increase boundlessly.

(2/3)

@mastodon @mte90

re: free software rant adjacent

@kristof

I saw Ferdi/um's feature of automatically loading and unloading. I think that's a fair compromise. This might be a solution mostly for the performance-oriented users, but these are probably the ones interested in such a feature anyway.

Do you have an intuition on how PWAs compare to sandboxed services in Electron in terms of resources? I'll check out Slack's mini version, that sounds like an interesting approach!

(3/3)

@mastodon @mte90

re: free software rant adjacent

@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 blobcatshrug

re: free software rant adjacent

@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/

re: free software rant adjacent

@kristof @floppy @mastodon in my opinion is better a native client app but I remember that slack code is not optimized with react in debug mode and considering that is creating this issues on Firefox because saves a lot of data https://bugzilla.mozilla.org/show_bug.cgi?id=1741865 ....

Hey @kristof, thanks for getting back at this!

I'm not sure what to think of the browser-integrated adblock attempts. Somebody once called it an arms race between advertisers and ad blockers, which is basically neverending game of two parties trying to outsmart each other.

Structural change is needed instead of trying to hit back harder. But more pragmatically I guess those measures are sadly needed in this world we live in, at least for now.

@mastodon @mte90

@kristof

I'm not sure whether Brave provides such structural change by their suggested ad model. It's great there is some development at all and that it inspires discourse. But as you pointed out, not sure whether their specific route is reaaally that great.

If Manifest V3 will really inhibit ad blocking, then this might actually motivate people to switch back to Firefox. 🤞 If the Fox is not dead by then. 😢

@mastodon @mte90

@kristof

Thank you for the explanation on PWA vs. sandboxes! That makes a lot of sense. And thanks for the links to details on "slim slack", I will dig into that!

@mastodon @mte90