@mdh worse, browser's complexity and the complexity of all Web APIs they implement (and that are required by software built on top of them) means they are hard-to-impossible to do a new independent implementation.

This means we effectively end up in a monoculture, and monocultures are prone to be vulnerable. As the whole WebP kerfuffle shows.

So instead of betting the farm on Google-controlled monoculture in a higher abstraction layer, it seems to me better idea to try fix stuff in the lower.

sandboxing is the most practical and effective solutions I think we have right now.

Operating system designs in use today are many decades behind where the research is at and to make the same argument you have for the browser… how many new ones do you see of those?

Fuchsia is the only real one I’m aware of.

@mdh QubesOS and GNU/Hurd and SpectrumOS are also interesting approaches, at different levels of usefulness obviously.

But my point is: instead of claiming "moving to web will fix this", we need to *actually* fix this, and to fix this we need to fix it at the OS level. Otherwise we're basically slapping lipstick on a pig and pretending it's pretty.

So I want *more research* and *more resources* to go into that, instead of into increasingly breaking the abstraction that the browser used to be…

I guess I’m with you in a theoretical sense.. I wish we weren’t in the state we are in, I wish we tackled this many years ago when we decided to network the entire world together but time is clearly a factor here.

What timeline do you have in mind here?

What looks good to you in the next five years?

I guess these are the constraints I had in mind here, those things can happen as well and I think largely are but if you look at probably the one main operating system that did go more or less all in on the web and sandboxing (ChromeOS) I would say for the vast vast vast majority of organisations out there today they would be an infinitely better position if they could run their workloads in a browser that ran inside of ChromeOS. Entire classes of problems would cease to exist

@mdh and entire classes of problems would just move to a different layer. Instead of Microsoft monopoly they would end up in Google monopoly.

There are no easy answers. I am not offering a roadmap to fix all of this.

I am merely ranting that we're all doing it wrong and it will all end in tears — so that when it inevitably does, we won't get to claim we didn't know. 🤷‍♀️

ok but I mean any of us can point out the problems or imagine utopian alternatives.

It’s one of the things I quite like about security. Shit is constantly on fire, you don’t have the tools you want but standing still isn’t an option. That’s fun to me and presumably you too.

How do you find the best bang for your buck right now but I think that’s where some of the confusion is coming from because I don’t think that was at all the conversation you were having but I’d be keen to hear your thoughts if you have some

@mdh at this point I am all out of thoughts, honestly. Short-term needs trump long-term sanity in all sorts of ways.

I don't consider working on improving OS security "utopian", though. 🤷‍♀️

just as it took a long way to get "there" with browsers. We could used this time and these resources to improve the OS instead, but we chose not to.

And that's the thing, it's our choices, it's the misaligned incentives, it's the short-term view, available resources, and so on and so forth. And none of this gets fixed unless people are shouting from the rooftops that shit is broken, yo.

So I shout from a rooftop.

@mirth indeed you're right I never thought about it this way — there are no alternatives to Electron and the Web!

Programmers writing desktop apps in any other framework have long passed away. Only Telegram exists as an example of such ancient technology, long forgotten and rightfully ridiculed.

🙄

@mirth at which point the only thing we need to run our Markdown text editor without frame drops is 64GiB of RAM, 16-core CPU, and two M.2 drives in RAID1.

That's okay, hardware is cheap and energy is plentiful!

is it true though? the java eclipse-based LDAP browser i'm using frequently is not less power hungry that vs code, has not seen a major upgrade in years, and can't handle tls1.3 properly (a bug known for three years!). and neither it nor the vs code, not even the javascript window manager and compositor is the primary resource consumer on my company-provided second-hand thinkpad – the browser is.

hell, the flatpak of electron-wrapped third party packaging of microsoft teams eats less resources than the in-browser teams.

@mirth

@mawhrin the fact that you can find an example of a resource-hungry piece of software that is not based on Electron does not mean that Electron apps are somehow not resource-hungry, nor that there are no less resource-hungry alternatives to Electron apps.

@mirth

these sure.

my point, probably badly conveyed, is not that electron is a good framework, but that it offers good enough portable results with minimal friction.

you can't get that in qt without writing c++ (you can argue for using python or other languages that have qt bindings and rich library resources, but that doesn't solve the problem of bundling runtime environments for these languages, which electron apps don't have).

and, security-wise, non-electron apps also need to handle their dependencies somehow. it's an old problem of third-party apps, and there is no easy solution to that.

also, i think you're overstating the resource usage in order to make a more compelling point.

@mirth

@mawhrin

> it offers good enough portable results with minimal friction.

Good enough by whose standards? Minimal friction for whom?

Answers: "developers', developers."

That's a problem, because as a user, Electron apps give me absolutely dismal performance.

And then we get stuff like these CVEs and I need to scramble to update each of these apps separately because apparently these libraries are embedded in them and OS updates don't help.

Far from "good enough", "minimal friction".

@mirth

have you considered that you might not be a typical user of those applications? it's a typical failure of highly technical users: the inability to see that their experience is generally highly atypical.

for starters, you're using linux, and expect third party application to come in distribution packages.

@mirth

@mawhrin I have, in fact, considered that.

The dismal performance and high resource usage is a pretty universal complaint about Electron apps. Including from very much "regular users".

The update thing? Sure, that's a bit more specific. But if you can cherry-pick and scope-down your claims to developers, why can't I cherry-pick and scope mine down to "linux users"?

Not to mention there's also quite a lot of non-techie Linux users, as much as you might find that surprising.

@mirth

@mawhrin point is: your post took the perspective of the developers — that Electron provides "good enough portable" framework with "minimal friction" — and made it look as if that's a universal thing.

It is not. Anyone with a 4GiB RAM laptop (plenty of those around) will tell you that.

@mirth