Ladybird browser spreads its wings(lwn.net)
lwn.net
Ladybird browser spreads its wings
https://lwn.net/Articles/976822/
317 comments
One commenter who worked on Firefox made a nice blog post in response, about what it takes to make a web browser: https://robert.ocallahan.org/2024/06/browser-engine.html
For a new project I wonder how much simpler (or secure) a browser could be made if you only allowed a subset of js and browser apis.
I’d wildly guesstimate for 70% of use cases you wouldn’t even need 50% of stuff with some slight modifications. The web is just so bloated.
Edit: might as well prune down the css a little too and maybe dump wasm, webgl and canvas
I’d wildly guesstimate for 70% of use cases you wouldn’t even need 50% of stuff with some slight modifications. The web is just so bloated.
Edit: might as well prune down the css a little too and maybe dump wasm, webgl and canvas
The problem with targeting a subset is there's a ratchet effect with web APIs, once support reaches critical mass in the major browsers sites will start unconditionally relying on those features and there's no going back from there, any new browser has to also support those features or be considered broken.
I suppose anything that's gated behind a permission prompt in Chrome/Firefox/Safari could be culled without too much trouble at least.
I suppose anything that's gated behind a permission prompt in Chrome/Firefox/Safari could be culled without too much trouble at least.
> The problem with targeting a subset is there's a ratchet effect with web APIs
What about starting a new web then only for the supported subset?
Based on my current browsing experience, this may be a plus in the long run.
What about starting a new web then only for the supported subset?
Based on my current browsing experience, this may be a plus in the long run.
There is a reason that Esperanto or one of it's siblings is not the language of global understanding and we are discussing in English. The world at large generally does not care about these kinds of fancy. It's half a miracle that we agreed to whatever the Chromium engine implements to be a baseline that most folks build stuff on.
The problem is convining anyone to write a website in this. You will have like 3 sites that use only the subset.
The closest example is AMP, but you must be Google to force people to use it.
The closest example is AMP, but you must be Google to force people to use it.
> The problem is convining anyone to write a website in this
Could choose a subset that lets certain sites that do not get on everybody's nerves still run fine.
For the remainder, people who need it can run an extension that runs a Chromium converting what's possible to the target subset.
Could choose a subset that lets certain sites that do not get on everybody's nerves still run fine.
For the remainder, people who need it can run an extension that runs a Chromium converting what's possible to the target subset.
Do you want to support YouTube? You want to support YouTube, don't you? Any big FAANG site probably uses most of the possible features.
> You want to support YouTube, don't you?
Of course no. You can use a bloated browser for that.
Of course no. You can use a bloated browser for that.
Then nobody will ever use your browser. Simple as that.
I think people forget the early 2000s. Many sites only worked on IE but Firefox was the better browser. Firefox users had an extension that would open certain links in IE or open the current page in IE via the context menu.
If a lightweight browser could be significantly faster and more secure, people would tolerate using two browsers again. Although Ladybird hasn't reached that bar.
YouTube certainly could use a small set of web standards, although YT regularly breaks on Firefox. It's a video player with links and forms.
If a lightweight browser could be significantly faster and more secure, people would tolerate using two browsers again. Although Ladybird hasn't reached that bar.
YouTube certainly could use a small set of web standards, although YT regularly breaks on Firefox. It's a video player with links and forms.
> YT regularly breaks on Firefox
Source? I've never had a single problem ever, and I don't know anyone else that has either.
Source? I've never had a single problem ever, and I don't know anyone else that has either.
Sure, here's a couple mentions from just the last ten days. Loads more if you search around.
https://mapstodon.space/@hareldan/112619447620823614
https://techhub.social/@weston/112607264644039009
https://pdx.social/@crowdotblack/112604055589800602
https://social.bitwig.community/@gerotakke/11263106899010552...
https://mapstodon.space/@hareldan/112619447620823614
https://techhub.social/@weston/112607264644039009
https://pdx.social/@crowdotblack/112604055589800602
https://social.bitwig.community/@gerotakke/11263106899010552...
YouTube has a vested interest to work best on Chrome.
It doesn't need to be mainstream, that will probably ruin it anyways.
So long as I can query the site for videos of interest and spin them up under mpv or VLC we're tots fine.
A surprising number of websites work fine without js.
Websites with text content maybe, but the web is full of webapps which require JS.
Basically none of the ones I use look or work normal without it.
There are now 3 competing standards.
You really just need two to see the positive effects, but three would be fantastic.
This is more or less the idea behind projects like the Gemini protocol [1].
It's even deliberately designed to not be easily extensible, as to avoid the temptation of adding features.
[1]: https://en.wikipedia.org/wiki/Gemini_(protocol)
It's even deliberately designed to not be easily extensible, as to avoid the temptation of adding features.
[1]: https://en.wikipedia.org/wiki/Gemini_(protocol)
Given that a browser is not practically a virtual machine and/or an OS, it is not too surprising that an OS developer is not scared by the task. At the same time, it seems to me that multimedia is a whole different beast.
> For a new project I wonder how much simpler (or secure) a browser could be made if you only allowed a subset of js and browser apis
IMHO the only viable subset is the empty set. There are some surviving HTML-only browsers that are still usable for e.g. viewing documentation or browsing simple-minded websites (like HN, but they are fewer and fewer every year, unfortunately).
I really don't want to drop the all too common negative comment - in particular since I already use an alternative web browser - but the initial investment required just for an MVP seems mind-boggling to me.
I think a basic HTML browser that can automatically delegate all it cannot handle to other apps - PDF viewing to a PDF viewer, video playback to a video player, and JS-requiring things to a big browser - would be interesting (if it already exists, please let me know).
> For a new project I wonder how much simpler (or secure) a browser could be made if you only allowed a subset of js and browser apis
IMHO the only viable subset is the empty set. There are some surviving HTML-only browsers that are still usable for e.g. viewing documentation or browsing simple-minded websites (like HN, but they are fewer and fewer every year, unfortunately).
I really don't want to drop the all too common negative comment - in particular since I already use an alternative web browser - but the initial investment required just for an MVP seems mind-boggling to me.
I think a basic HTML browser that can automatically delegate all it cannot handle to other apps - PDF viewing to a PDF viewer, video playback to a video player, and JS-requiring things to a big browser - would be interesting (if it already exists, please let me know).
I've been wanting something like that, like a wrapper that hosts three or four engine, so I can use normal for every-day, upscale to FF for some or Chrome for others - all in one UI.
>IMHO the only viable subset is the empty set. There are some surviving HTML-only browsers that are still usable for e.g. viewing documentation or browsing simple-minded websites (like HN, but they are fewer and fewer every year, unfortunately).
I'm curious if throwing out DOM/js would make the task more approachable. My intuition says yes. But I'm thinking CSS would still make it super difficult. Also I've heard that HTML has some rough areas that make it hard.
That being said I find Netsurf is pretty capable even if I don't really use it very often. Yeah some pages don't render right but it's really fast. So who knows maybe we can get away with a reduced set of features or better yet go back to using separate clients instead of web apps for things like chat, email and forums.
I'm curious if throwing out DOM/js would make the task more approachable. My intuition says yes. But I'm thinking CSS would still make it super difficult. Also I've heard that HTML has some rough areas that make it hard.
That being said I find Netsurf is pretty capable even if I don't really use it very often. Yeah some pages don't render right but it's really fast. So who knows maybe we can get away with a reduced set of features or better yet go back to using separate clients instead of web apps for things like chat, email and forums.
I think this is a great point. The majority of my browsing uses text oriented sites (some think they are more, but I read them in reader mode). As I user, I rarely want more. I'd use a slim, secure browser if I could.
Sometimes I play games, or use "web apps" and using a different tool in those instances would be fine. Back in the early 2000s I remember using Firefox with an "open in IE" extension that allowed me to primarily use FF and fall back to IE when sites were broken. As websites modernized I used the extension less and less.
Also consider desktop apps that use election. Bundling a simpler browser and building the app to the capabilities of that browser could greatly reduce install size and memory usage.
Sometimes I play games, or use "web apps" and using a different tool in those instances would be fine. Back in the early 2000s I remember using Firefox with an "open in IE" extension that allowed me to primarily use FF and fall back to IE when sites were broken. As websites modernized I used the extension less and less.
Also consider desktop apps that use election. Bundling a simpler browser and building the app to the capabilities of that browser could greatly reduce install size and memory usage.
[deleted]
If it only does 70% of what a regular browser does would anyone (seriously not as an experiment) use it on a daily basis? Most people just want to get on the web and go. They don’t care how big their is on disk or how much ram it uses (within reason of course), but the first time it doesn’t render their bank page or Jira page, they will drop it. Obviously I’m not talking about beta testers here or curious web devs.
The conversation regarding restrictions on the feature set within the browser always focuses on the browser itself, but there is definitely an opportunity to rally website makers. If Google or Apple came out and said we have a reduced feature set you can use that makes our browser render your website faster it would be a good opportunity, and I think many website makers would jump at the opportunity. A sort of Google AMP, but good! Let's call it Strict HTML.
> Edit: might as well prune down the css a little too and maybe dump wasm, webgl and canvas
Alternative idea: go the other extreme and stop pretending modern browsers are anything else than virtual machines. Turn browsers into sandboxed VMs that only run Wasm, with backwards compatibility ensured by shared wasm libraries that render HTML and run JS.
Alternative idea: go the other extreme and stop pretending modern browsers are anything else than virtual machines. Turn browsers into sandboxed VMs that only run Wasm, with backwards compatibility ensured by shared wasm libraries that render HTML and run JS.
This is so wildly wrong it hurts. As soon as that one important website (to your user) breaks, they will switch browsers.
Just deciding that you don't want to implement >50% of web specs "for simplicity" and expecting that to be a winning strategy is very HN.
Just deciding that you don't want to implement >50% of web specs "for simplicity" and expecting that to be a winning strategy is very HN.
The "very HN" thing for me is assuming a "winning strategy" has to be mass adoption. There's room for a smaller web full of nerds and geeks, we had that before and maybe we can have it again.
Indeed, that's why we are discussing on HN, not on Reddit. Exclusion as a design choice.
To me it’s not wrong at all, why won’t a simpler browser with a “modern mode” rendering succeds? There is no need for that browser to support the space jam website, who really cares? Imo thinking that people need quirks mode because they need to visit old website it’s very HN.
It's not that at all. Imagine some popular website is relying on some weird quirk but it works out in modern browsers. They don't even know they are broken, or in what way, and first discovering the issue and then investing in fixing the issue for <1% of readers is a very difficult cost to justify.
In context we are in [0], is space jam website really the problem?
Old space jam website is just bunch of tables and images. It is the "modern mode" that is bloated.
[0]: https://news.ycombinator.com/item?id=40748071
[0]: https://news.ycombinator.com/item?id=40748071
This is what Sciter, Lexbor or litehtml are aiming for.
> Use a programming language that lets you write clean, fast, memory-safe, parallel data-race-free code — probably Rust.
But from the lwn article:
But from the lwn article:
It is written in C++ [..].
If I were building this, I wouldn't do that.
I would build one piece, as a well-documented Pythonic (not in Python; just in coding / documentation style) library.
The reason this is impossible is the monolithic design of these things. There are good reasons for it -- the pieces interrelate -- but I think it's possible to break it up (with a lot of work).
For example:
- A clean, documented JavaScript engine would be a good start.
- Python-style, independent, isolated JavaScript libraries would help (usable serverside or clientside where possible)
- An independent rendering engine would be nice -- again, documented and independent of the above
- Network libraries
- HTML / XML / CSS parsing libraries
... etc.
If this were in place, code could be interchangeable between serverside and clientside much more than today (and usable in other places, such as using JS as a scripting language in other systems).
Test cases for rendering (or even just making a screenshot) wouldn't need the whole browser. You would import and call into the rendering engine to make a .png without selenium.
Making a new web browser would involve mostly glue code and OS-specific code.
I would build one piece, as a well-documented Pythonic (not in Python; just in coding / documentation style) library.
The reason this is impossible is the monolithic design of these things. There are good reasons for it -- the pieces interrelate -- but I think it's possible to break it up (with a lot of work).
For example:
- A clean, documented JavaScript engine would be a good start.
- Python-style, independent, isolated JavaScript libraries would help (usable serverside or clientside where possible)
- An independent rendering engine would be nice -- again, documented and independent of the above
- Network libraries
- HTML / XML / CSS parsing libraries
... etc.
If this were in place, code could be interchangeable between serverside and clientside much more than today (and usable in other places, such as using JS as a scripting language in other systems).
Test cases for rendering (or even just making a screenshot) wouldn't need the whole browser. You would import and call into the rendering engine to make a .png without selenium.
Making a new web browser would involve mostly glue code and OS-specific code.
Andreas Kling is a great role model in the world of development I feel. The decision to step away from the Serenity OS makes a lot of sense. There are plenty of them, nice projects to do, but they'll never have an immediate impact if any at all. But the browser space, Ladybird is viable as a daily driver for people. I'm still today astounded the work that has been produced just on this.
> Somewhat ironically, it was not possible to log into Discord using Ladybird. It does a fair job of rendering pages, but speed and stability are still wanting.
Fascinating to see people expecting everything to work out of the box whilst being writter from scratch.
And as an avid rust appreciator, all the comments about "rewrite it in rust" as if that solves anything the OP spoke about is really frustrating.
Let the team cook, if you dont like the dish, help cook it. The project has been super interesting and honestly I feel we need more like this in the browser scope.
> Somewhat ironically, it was not possible to log into Discord using Ladybird. It does a fair job of rendering pages, but speed and stability are still wanting.
Fascinating to see people expecting everything to work out of the box whilst being writter from scratch.
And as an avid rust appreciator, all the comments about "rewrite it in rust" as if that solves anything the OP spoke about is really frustrating.
Let the team cook, if you dont like the dish, help cook it. The project has been super interesting and honestly I feel we need more like this in the browser scope.
I don't think casual observers understand how many new CSS features have been added to the web platform over the last few years.
468 new features have been added since 2018; 148 have been added in the past 18 months alone [1].
I applaud the effort but unless something fundamentally changes in their approach, I don't see how they can catch up.
Sure, you don't need every single spec, but even the core ones like Flexbox, Grid are large and complicated and are constantly being tweaked.
[1]: https://codepen.io/fimion/pen/WNmwJWJ
468 new features have been added since 2018; 148 have been added in the past 18 months alone [1].
I applaud the effort but unless something fundamentally changes in their approach, I don't see how they can catch up.
Sure, you don't need every single spec, but even the core ones like Flexbox, Grid are large and complicated and are constantly being tweaked.
[1]: https://codepen.io/fimion/pen/WNmwJWJ
all of them were written in a way that mostly affect the api, not the underlying implementation models tho.
it's still 500 new things to test and actually implement. but not as bad as the original 1 to 2 change.
html5 was the forever missed opportunity to do things right. but keeping the browser-side effort low was always fought for on the w3 committe.
it's still 500 new things to test and actually implement. but not as bad as the original 1 to 2 change.
html5 was the forever missed opportunity to do things right. but keeping the browser-side effort low was always fought for on the w3 committe.
> Fascinating to see people expecting everything to work out of the box whilst being writter from scratch.
(Sarcastically saying something is interesting is something I find distasteful.)
Anyway the irony is that the project chose to use a discussion platform which uses lots of modern web cruft and would be a big challenge for a new browser, when they could have chosen a (maybe less capable) simpler platform like IRC or some simple web forum which would more likely have run on Ladybird.
(Sarcastically saying something is interesting is something I find distasteful.)
Anyway the irony is that the project chose to use a discussion platform which uses lots of modern web cruft and would be a big challenge for a new browser, when they could have chosen a (maybe less capable) simpler platform like IRC or some simple web forum which would more likely have run on Ladybird.
Chosing Discord was a deliberate choice. I remember when Serenity was using IRC as the only communication channel and immediately after setting up a new Discord server the community gravitated towards it. Infact, the number of community members sky rocketed.
The fact is, Discord as a platform is more accessible compared to IRC.
The fact is, Discord as a platform is more accessible compared to IRC.
> The fact is, Discord as a platform is more accessible compared to IRC.
Guess it depends on what you mean with "accessible". In terms of accessibility for impaired users, IRC is a open protocol vs a service that disallows 3rd party clients. I'm sure there exists better options for IRC than Discord, and at the very least, IRC allows you to access it however you want, be it visual, textual, voice control or whatever.
Besides, Discord being a US company, need to prevent users from Cuba, Iran, Syria (and NK) and is also banned in a bunch of countries like China, UAE and Egypt. So in that sense, Discord seems less accessible than IRC.
Only remaining part is that Discord has a somewhat easier "getting setup" UX than IRC for younger users, as it's more similar to the type of services they're probably already use.
Guess it depends on what you mean with "accessible". In terms of accessibility for impaired users, IRC is a open protocol vs a service that disallows 3rd party clients. I'm sure there exists better options for IRC than Discord, and at the very least, IRC allows you to access it however you want, be it visual, textual, voice control or whatever.
Besides, Discord being a US company, need to prevent users from Cuba, Iran, Syria (and NK) and is also banned in a bunch of countries like China, UAE and Egypt. So in that sense, Discord seems less accessible than IRC.
Only remaining part is that Discord has a somewhat easier "getting setup" UX than IRC for younger users, as it's more similar to the type of services they're probably already use.
Sounds like someone should work on Discord-ifying IRC to make it more palatable for the modern user.
That would be Matrix.
They used to use IRC in the beginning.
I wish rust people spent their time writing software instead of going around telling other people to do the job for them. They only manage to get others annoyed with this attitude.
Truer words have not been spoken.
> But the browser space, Ladybird is viable as a daily driver for people.
From the LWM article:
> Users will need GCC 13+ or Clang 17, and Qt6 development packages to play along at home. Ladybird compiles and runs on, for example, Fedora 40 without a problem, *but it is a long way from being suitable for regular use.*
Seems distributed binaries are missing, but that's easy to "fix"/"workaround". Is there something else that makes you say it is suitable as a daily driver while LWM author does not?
From the LWM article:
> Users will need GCC 13+ or Clang 17, and Qt6 development packages to play along at home. Ladybird compiles and runs on, for example, Fedora 40 without a problem, *but it is a long way from being suitable for regular use.*
Seems distributed binaries are missing, but that's easy to "fix"/"workaround". Is there something else that makes you say it is suitable as a daily driver while LWM author does not?
> Seems distributed binaries are missing,
Even with SerenityOS they long were of the mindset that binaries/ISO/etc. should not be produced and distributed by them apparently.
Even with SerenityOS they long were of the mindset that binaries/ISO/etc. should not be produced and distributed by them apparently.
Related:
I'm forking Ladybird and stepping down as SerenityOS BDFL - https://news.ycombinator.com/item?id=40560768 - June 2024 (262 comments)
I'm forking Ladybird and stepping down as SerenityOS BDFL - https://news.ycombinator.com/item?id=40560768 - June 2024 (262 comments)
For a newbie like me who isn’t like a software eng wizard but is willing to put an hour or two every day, is a project like this a great way for me to learn and contribute? Or is it still so pre-alpha that you need deep domain knowledge to contribute and have an impact?
I think it's a great project to learn and contribute. The scope is very broad, so there are plenty of different areas to contribute to, including not-so-advanced functionality. For example, the initial find-in-page feature was introduced just a few week ago[1] and the core logic relatively simple.
Plus, the build process is well documented and works out of the box (at least on Ubuntu in my experience) and the community is nice and welcoming.
[1]https://github.com/SerenityOS/serenity/pull/24480
Plus, the build process is well documented and works out of the box (at least on Ubuntu in my experience) and the community is nice and welcoming.
[1]https://github.com/SerenityOS/serenity/pull/24480
>Plus, the build process is well documented and works out of the box
Yeah, that seems to be a huge problem with many larger FOSS projects.
Yeah, that seems to be a huge problem with many larger FOSS projects.
Even if not pre-alpha, building a browser needs deep domain knowledge. But on the other hand, after some time you will be rewarded with very, very useful knowledge of how the web actually works.
The start would be pretty rough but if your daily work lacks the challenge then I would encourage you to try contribute :)
(Not affiliated in any way)
(Not affiliated in any way)
I remember encountering this blog series of Chrome architecture articles[0] and telling myself I need to read through it (and, to date, still never have :)
Maybe it is of interest. (Just a heads up, it dates back to 2018.)
[0]: https://developer.chrome.com/blog/inside-browser-part1
Maybe it is of interest. (Just a heads up, it dates back to 2018.)
[0]: https://developer.chrome.com/blog/inside-browser-part1
Whoa, incredible resource. Thank you!
I’ll be that guy and point out that if you have to ask this question, it may not be the best personal fit. Unpaid open source contributions work the best and last the longest when they scratch your personal itch. Find a bug or a missing feature in a piece of open source software you use all the time; find an abandoned project you need and try to improve it; or build something you want but doesn’t yet exist. Forcing your way into open source through a large project that is not in any way special to you in order to learn, build your personal brand, etc. may not be the most sustainable source of motivation. But who knows, maybe that also works for some people.
> Unpaid open source contributions work the best and last the longest when they scratch your personal itch. Find a bug or a missing feature in a piece of open source software you use all the time
Most of the open source software I use are really rock solid, so I’m not sure what bug or missing feature I would be able to add. I also think as a newbie it’s perhaps useful to work where I can learn a lot in a short amount of time. Those dopamine hits can be pretty awesome :)
Most of the open source software I use are really rock solid, so I’m not sure what bug or missing feature I would be able to add. I also think as a newbie it’s perhaps useful to work where I can learn a lot in a short amount of time. Those dopamine hits can be pretty awesome :)
Although I dont like quite a few Firefox decisions. Like the floating tabs which no easy way to revert. I still think Firefox as a browser is fairly decent. And I also think that ladybird is going to have all the problems that Opera Presto had (and now Firefox has) which is going to be ignored by any small developers, and targeted to generate errors by the big companies (google/microsoft...)
I definitely would have preferred the momentum to go to SerinityOS, and perhaps, importing firefox/librewolf into Serinity OS.
I definitely would have preferred the momentum to go to SerinityOS, and perhaps, importing firefox/librewolf into Serinity OS.
If enough people use different browsers then we'll get effective and slower standards once again. I think the only way to get people on other browsers is to legally require ballots on first use of an OS/device with random order. It worked in the EU, it can work in the US too.
It's great that we're faced with an explicit choice here in the EU, but I don't think it really done much in terms of affecting Chrome's entrenched market share. Most people use whatever tools they're already familiar with. Almost everyone I know uses Chrome, including the majority of my tech circle.
I think people are only going to switch once the Firefox user experience is noticeably better for the average person. Google is on track to make that happen after they finally disable Manifest v2 extensions and as they continue their crackdown on ad blockers.
I think people are only going to switch once the Firefox user experience is noticeably better for the average person. Google is on track to make that happen after they finally disable Manifest v2 extensions and as they continue their crackdown on ad blockers.
Firefox doesn't control major web properties from which it can nag users to switch. Chrome (and similar chokepoint-holders like Safari) won't be unseated by market forces for years, maybe decades. We are on the road to technology feudalism as the web and browsers eat the world.
Unfortunately that is not how it works. The only way to get different browsers is to get absolutely every single OS project with some traction to force installation of them, to show advertisement everywhere, and to couple it with the installation of any piece of software, and to set it as default, plus import silently everything.
Anything that is not a dirty tactic will not work.
Also, the moment a user got an error they dont understand in certain browser, they blame the browser and change. How do you think firefox got out of business?
Have you tried using Firefox to request an appointment with the Spanish Drive and Vehicle License Administration? It wont work. The civil servant will tell you use chrome.
When a user get 2 or 3 use chrome to work, they will just use whatever it works. They won the browser war, adding ladybug to steal from firefox, is also not going to help either.
Anything that is not a dirty tactic will not work.
Also, the moment a user got an error they dont understand in certain browser, they blame the browser and change. How do you think firefox got out of business?
Have you tried using Firefox to request an appointment with the Spanish Drive and Vehicle License Administration? It wont work. The civil servant will tell you use chrome.
When a user get 2 or 3 use chrome to work, they will just use whatever it works. They won the browser war, adding ladybug to steal from firefox, is also not going to help either.
All of those problems can be fixed by legal means. We cannot expect the market to regulate itself into a healthy competitive balance.
Force sites to implement baseline standards and not rely on non-standard features. Disallow major web players from pushing their own browsers and from relying on their own browser's non-standard features. Permanently require browser ballots on all widely used consumer OS's. Heavily fine violators consistently. Use the money to support an independent standards body.
Naive users will get a random, standards compliant browser. This throng will help prevent sites with no concern for the law from testing against only one instead of against the standard.
Force sites to implement baseline standards and not rely on non-standard features. Disallow major web players from pushing their own browsers and from relying on their own browser's non-standard features. Permanently require browser ballots on all widely used consumer OS's. Heavily fine violators consistently. Use the money to support an independent standards body.
Naive users will get a random, standards compliant browser. This throng will help prevent sites with no concern for the law from testing against only one instead of against the standard.
There has been 30/40 years of internet, and no legal battle has manage to get anything on that regard.
I would even say, topics on the internet with a lot of lobbying, such as pirating software/media, in the same timeframe, has managed to get absolutely nothing done.
I am afraid, it would not be possible to regulate legally.
I would even say, topics on the internet with a lot of lobbying, such as pirating software/media, in the same timeframe, has managed to get absolutely nothing done.
I am afraid, it would not be possible to regulate legally.
Yet regulations have happened and continue to, just different ones of varying ... quality/purpose. Even among preservation/piracy there have been moderately successful efforts.
Apathy will not bring change. Only speech and action.
Apathy will not bring change. Only speech and action.
The only thing that resulted in a decline in piracy was an increase in convenience, simplicity, and speed brought by on demand services (cloud game downloads and subscription passes, streaming video and music services, ebook/software subscriptions through app stores). The many billions spent per year in lobbying for deep seated laws like DMCA or equivalents never brought any meaningful change to the problem because the root of the issue was not solved by more restrictions.
How did it work in the EU? Almost the entire planet uses Chrome including the EU.
In the early 2010s a ballot appeared for new users on Windows [0], though the legal requirement expired only a few years later.
It helped other browsers gain market share. Sadly it's not enough alone. Major web players can promote their own browser and sabotage others, even if only by neglecting to test them. IMO a permanent ballot law is needed alongside restrictions from major web vendors pushing their own browser's and relying on their own browsers non-standard features.
[0] https://en.m.wikipedia.org/wiki/BrowserChoice.eu
It helped other browsers gain market share. Sadly it's not enough alone. Major web players can promote their own browser and sabotage others, even if only by neglecting to test them. IMO a permanent ballot law is needed alongside restrictions from major web vendors pushing their own browser's and relying on their own browsers non-standard features.
[0] https://en.m.wikipedia.org/wiki/BrowserChoice.eu
Do you perhaps mean to argue you think it helped other browsers lose users slower than they otherwise might have? From your link:
> Competing browsers saw their traffic increase,[16] suggesting that these smaller competing developers were gaining users. However, long-term trends show browsers such as Opera and Firefox losing market share in Europe, calling into question the usefulness of the browser choice screen.[1]
Opera is the smaller competitor referred to in both halves and it lost user share in Europe while this was in effect. About the only thing the ballot can claim is a loss in users of the 1st party browser IE but that effect was already occurring prior to the ballot anyways.
> Competing browsers saw their traffic increase,[16] suggesting that these smaller competing developers were gaining users. However, long-term trends show browsers such as Opera and Firefox losing market share in Europe, calling into question the usefulness of the browser choice screen.[1]
Opera is the smaller competitor referred to in both halves and it lost user share in Europe while this was in effect. About the only thing the ballot can claim is a loss in users of the 1st party browser IE but that effect was already occurring prior to the ballot anyways.
On the whole it did only slow the tide. Yet it wasn't enough alone, limited to one OS, in one market, for only ~4 years, at a time when Google was pushing its own from some of the world's most popular services. Still, every victory is worth celebrating.
Moping every time a (modestly successful) approach is brought up isn't going to move the needle.
Dominant browsers rely on many tricks to gain and hold their position. It will take more than one approach to restore a balance.
Moping every time a (modestly successful) approach is brought up isn't going to move the needle.
Dominant browsers rely on many tricks to gain and hold their position. It will take more than one approach to restore a balance.
I appreciate you consider it key but that several others are disagreeing whether something was successful is not them simply moping it was successful but not enough :). Keep in mind this all started out with this being the only way to get people on other browsers like how it had already worked in the EU so that's going to have steered more disagreement in the conversation than you might expect.
I think the browser ballot style thing may have hurt more than it helped in the long run. E.g. users clicking things they don't understand during the initial setup of their computer (while a whole lot of other things they don't really deal with often are going on too) may have actually resulted in some extra short term download hits that immediately scared those users away from spending time trying other browsers out once they realize what their selection meant in terms of change. How many users that clicked on Maxthon and were confused/disappointed with a (then) Trident based browser that wasn't quite IE? Hard to say but the data isn't jumping out to show the opposite.
I agree it would take more than one approach to restore the balance but I disagree that means all approaches are inherently helpful to roll out, let alone inherently key. The ballot initiative didn't result in any measurable change, even against the tide when compared to other regions, and simultaneously focuses both people and discussion away from major issues like the tricks dominant players actually use to gain market share. E.g. Microsoft had IE (and later Edge) bundled as the default choice after the ballot and share continued to decline up until they used these other working tactics which have resulted in it becoming the 2nd most used desktop browser again.
I think the browser ballot style thing may have hurt more than it helped in the long run. E.g. users clicking things they don't understand during the initial setup of their computer (while a whole lot of other things they don't really deal with often are going on too) may have actually resulted in some extra short term download hits that immediately scared those users away from spending time trying other browsers out once they realize what their selection meant in terms of change. How many users that clicked on Maxthon and were confused/disappointed with a (then) Trident based browser that wasn't quite IE? Hard to say but the data isn't jumping out to show the opposite.
I agree it would take more than one approach to restore the balance but I disagree that means all approaches are inherently helpful to roll out, let alone inherently key. The ballot initiative didn't result in any measurable change, even against the tide when compared to other regions, and simultaneously focuses both people and discussion away from major issues like the tricks dominant players actually use to gain market share. E.g. Microsoft had IE (and later Edge) bundled as the default choice after the ballot and share continued to decline up until they used these other working tactics which have resulted in it becoming the 2nd most used desktop browser again.
> the floating tabs which no easy way to revert
Very easy in userChrome.css. I put mine on GitHub but it's nothing special, there are lots and lots that are available.
https://github.com/torstenvl/userChrome.css
Very easy in userChrome.css. I put mine on GitHub but it's nothing special, there are lots and lots that are available.
https://github.com/torstenvl/userChrome.css
Not what I would consider easy, that is medium.
Easy should be install a theme/extension, or toggle an option on configurations. Yours can be broken after updates, and requires to know what it is (I do, I just cant be bothered), and redownload and apply after each time an update breaks it.
I have decided to live with the awful floating tabs rather than personalising the userChrome.css, I wish someone could convert it into an extension.
Easy should be install a theme/extension, or toggle an option on configurations. Yours can be broken after updates, and requires to know what it is (I do, I just cant be bothered), and redownload and apply after each time an update breaks it.
I have decided to live with the awful floating tabs rather than personalising the userChrome.css, I wish someone could convert it into an extension.
let's all take a moment to appreciate how google managed to get the web to the state it was in 1996, when you had to develop for one browser and then go fix things in another.
/slow clap
/slow clap
I hope both Ladybird and Servo succeed in creating a new browser engine. Though I do have a slight preference for Servo as it's using Rust. Not that Rust is magical, but given how much attack surface there is in a browser, it seems picking C++ is a bit odd in 2024.
Personally if I were to attempt a project at this scale, I'd do so using a language I'm proficient in. There might be other reasons, but Rust & C++ really are different beasts.
It's debatable how many - if any - humans are truly proficient with C++.
Sounds like "Its hard, so it can't be done" to me.
There are plenty of people making good software in C++, how else would we have what we have. Sure, things get bloated and break over time, but thats not due to programmers not knowing C++, thats just what happens as a product evolves. New coders get brought in, focus shifts, understanding of the code based erodes. Its not that language, its the process.
I would say a lot but the average age is probably higher than rust by a large margin.
I’m irrationally excited for this project. The idea of a community built browser is incredibly appealing considering the current landscape where all browsers are either Chrome, Chrome in a trench coat, or Firefox
I don't understand what is wrong with Firefox. It is open-source, highly configurable and reasonably secure (if you have the time to configure). Yes, it has shortcomings, but what doesn't.
Not every open source software has spyware and ads activated by default, while marketing itself as privacy friendly.
Yes, can all be deactivated, I also use FF, but I do not trust Mozilla anymore.
Yes, can all be deactivated, I also use FF, but I do not trust Mozilla anymore.
Ikr. They're up to some questionable decisions since long.
- Acquire companies like Pocket, Anonym in multi-million dollar deals and also the millions in bonuses that the CEO likes to enjoy.
- At the same time, no significant expenditure towards developing its core software. Firefox is still ridden with bugs. They even went as far as firing the people that used to work on Servo, Rust, WASM, etc.
I think it's clear to them that there's not enough money to be made with small tricks like Pocket, VPN, Relay, etc. Firefox is still the only profitable product and contributes ~90% to Mozilla's revenue. Much of it coming from Google which is the one thing that people have been asking them to be less dependent on.
And we shouldn't be surprised if they double down on making more money off of Google and also introduce ads. Acquiring Anonym, an ads company, implies that it might have already started.
- Acquire companies like Pocket, Anonym in multi-million dollar deals and also the millions in bonuses that the CEO likes to enjoy.
- At the same time, no significant expenditure towards developing its core software. Firefox is still ridden with bugs. They even went as far as firing the people that used to work on Servo, Rust, WASM, etc.
I think it's clear to them that there's not enough money to be made with small tricks like Pocket, VPN, Relay, etc. Firefox is still the only profitable product and contributes ~90% to Mozilla's revenue. Much of it coming from Google which is the one thing that people have been asking them to be less dependent on.
And we shouldn't be surprised if they double down on making more money off of Google and also introduce ads. Acquiring Anonym, an ads company, implies that it might have already started.
"They even went as far as firing the people that used to work on Servo, Rust, WASM, etc."
And at the same time greatly raising compensation for the CEO, despite shrinking numbers.
And at the same time greatly raising compensation for the CEO, despite shrinking numbers.
Servo had so much potential as the flagship Rust project, a fast and memory safe browser engine.
Such a loss to see it jettisoned and abandoned. Myopic decisions like these are filling the cloud of pessimism that now shrouds Mozilla.
Such a loss to see it jettisoned and abandoned. Myopic decisions like these are filling the cloud of pessimism that now shrouds Mozilla.
FWIW Servo is seeing work as e.g. an Electron replacement. There is hope, even if one wishes the Mozilla Foundation CEO had used some $6M on developer salaries instead of pocketing it.
Full browser feature set is hard, but an app that bundles its own webview can choose to not trigger the edge cases, so that's a realistic path forward.
Full browser feature set is hard, but an app that bundles its own webview can choose to not trigger the edge cases, so that's a realistic path forward.
I see some nice parallels with Wikipedia. Makes me wonder if anyone's yet developed a theory of "foundation capture" where you find some marvellous free thing that is made for and by humanity at large and extract/redirect money from its market share/good will.
I think the pump-and-dump extraction of value from any brand works pretty similarly, whether a non-profit or regular business.
Lots of companies with centuries-long record of manufacturing previously durable goods have in the last decade or two switched to using e.g. inferior quality steel to increase profits. That'll destroy the brand, but in the meanwhile there's great profits to be had!
Lots of companies with centuries-long record of manufacturing previously durable goods have in the last decade or two switched to using e.g. inferior quality steel to increase profits. That'll destroy the brand, but in the meanwhile there's great profits to be had!
I guess for that we have to thank Aesop, the original corporate raider.
https://en.wikipedia.org/wiki/The_Goose_that_Laid_the_Golden...
https://en.wikipedia.org/wiki/The_Goose_that_Laid_the_Golden...
Also they stopped developing Servo :(
As in Mozilla stopped developing officially? Because I have seen active development on GitHub and monthly updates on their blog.
Mozilla stopped in 2020: https://news.ycombinator.com/item?id=24128865
The project limped along for a bit, then recently Igalia started putting resources into it: https://news.ycombinator.com/item?id=39269949
The project limped along for a bit, then recently Igalia started putting resources into it: https://news.ycombinator.com/item?id=39269949
Yes, that's correct. It was later adopted by the Linux Foundation with some industry support: https://www.linuxfoundation.org/press/press-release/open-sou...
Yes, a while ago.
But fortunately people continue. Just not with the billion dollar budget of Mozilla and with seemingly less traction. I have not heard of them in a while.
But I very much endorse both. And yes, in theory energy should be focused, but I rather have 2 smallish projects, but with potential, than one slightly bigger one, with fighting about direction all the time.
But I very much endorse both. And yes, in theory energy should be focused, but I rather have 2 smallish projects, but with potential, than one slightly bigger one, with fighting about direction all the time.
Firefox is open source, it would be far easier for the community to make a stripped down Firefox port with no telemetry, no ads and no upsells for Mozilla services.
With that said, almost all of Mozilla's revenue comes from Google, which might possibly influence what features they implement, their stance on various web standards etc.
With that said, almost all of Mozilla's revenue comes from Google, which might possibly influence what features they implement, their stance on various web standards etc.
As pointed out, these do exist. I've been using several over the decades. And chrome forks too.
They all tend to lag behind over time, until the fork is eventually too old and it's either abandoned, useful changes I was relying on are dropped, or becomes just too old compared to upstream to be fully compatible (and thus just annoying to use).
Just the burden to upkeep the upstream changes, in either firefox or chrome forks, seems to be significant enough that I'm quite pessimistic on the lifespan of these projects.
You might just as well do your own thing, and don't pretend to be a mainstream browser replacement altogether.
They all tend to lag behind over time, until the fork is eventually too old and it's either abandoned, useful changes I was relying on are dropped, or becomes just too old compared to upstream to be fully compatible (and thus just annoying to use).
Just the burden to upkeep the upstream changes, in either firefox or chrome forks, seems to be significant enough that I'm quite pessimistic on the lifespan of these projects.
You might just as well do your own thing, and don't pretend to be a mainstream browser replacement altogether.
Keeping up with an already built browser is too hard so we’ll create an entirely new browser that takes even more work?
The way I see it is "I'll have fun at something that feels interesting"
Yes and those forks exists and are a solution now.
But long term, I would much rather see a truly independent open source browser engine.
But long term, I would much rather see a truly independent open source browser engine.
> which might possibly influence what features they implement, their stance on various web standards etc.
Unless you’ve got some examples to back this up, it’s FUD. Posting hypotheticals is how rumours start, and this is just stirring the pot.
Unless you’ve got some examples to back this up, it’s FUD. Posting hypotheticals is how rumours start, and this is just stirring the pot.
Conflict of interests is a real thing to worry about. I wouldn't trust scientist working in tobacco company on cigarette harm, even if I have no evidence of wrongdoing.
Sure, there are forks such as LibreWolf. I understand the reservations regarding Mozilla Foundation, although I generally like what they've been doing. Every org has people with stupid ideas. However, the way I see it, it's unlikely that the community will be able to produce a competitive browser in a broader sense (stability, performance, security, cross-platform...), meaning that the likelihood of Firefox being still around ten years from now is significantly higher than that we build and maintain a comparable browser ourselves. Then come the evolving web standards and lobbying power...
The way things are going at Mozilla currently, I wouldn't be surprised if Firefox is just another Chromium wrapper in 10 years. Technology doesn't seem to count as much as the C-suite filling their pockets at this "new" Mozilla.
Can you elaborate on what you mean by your claims of firefox having “spyware and ads activated by default”?
Install a new version of firefox, have a look in settings under "data" (or whatever they call it in english). There you will see "studies" as activated, which is cryptic talk for ad tracking. And more recently, literal tracking for a advertisement company.
And as a bonus, those were added and activated as features via update, without telling. At least for me.
(and paid ads you have on the home screen)
And as a bonus, those were added and activated as features via update, without telling. At least for me.
(and paid ads you have on the home screen)
Studies are not ad tracking. It's worse and more like a backdoor for A/B testing of browser features. A few years back an update broke the Metamask extension and it was fixed by pushing via studies. At that point users weren't very aware the feature even existed and it caused some backlash since users realized there was a backdoor to push code into their browsers.
The backlash resulted in studies being opt-in, and I thought it still was but I don't know, I use "policies.json" to setup my browsers.
The backlash resulted in studies being opt-in, and I thought it still was but I don't know, I use "policies.json" to setup my browsers.
Am I being a total chud? These don't really seem egregious? I already accept (and expect) that Firefox receives background updates in the background.
https://i.imgur.com/S7d4ZXg.png
https://i.imgur.com/n2euIrQ.png
https://i.imgur.com/BUjukOy.png
https://i.imgur.com/S7d4ZXg.png
https://i.imgur.com/n2euIrQ.png
https://i.imgur.com/BUjukOy.png
I don't mind the feature as opt-in, just like telemetry it can be useful. But depending on the threat model it can be a big problem. I still use Firefox as my main browser.
> And as a bonus, those were added and activated as features via update, without telling. At least for me.
Ouch, they were new to me and also activated.
Ouch, they were new to me and also activated.
Yep, stuff like this makes me question many things. I mean in a sane world this should be enough to sue them into oblivion. But the general bar in that regard is so low, that apparently even open source companies can do it as default.
Why don’t you think it’s a sane enough world to “sue them into oblivion”?
Because I do not think one will have success with it. Same with Microsoft, Google and co.
This about sums it up. Plus donating to Mozilla means your money goes to all sorts of things, but hardly if at all where you want it to.
> Yes, can all be deactivated, I also use FF, but I do not trust Mozilla anymore.
And so I feel much more at home with Microsoft Edge and Google Chrome.
And so I feel much more at home with Microsoft Edge and Google Chrome.
Nothing, it’s my default browser for dev work but it’s only alive because Google keeps paying them to exist basically so I’d love an alternative.
How's that alternative funded? Shouldn't Mozilla want to replace their Google payment with that instead? Or, failing that, wouldn't it be much lower budget to fork Firefox code instead?
And then to do it in C++ when other browsers and kernels are flirting with things like Rust. How long will it take for people to trust this new C++ code? I applaud the effort but am worried it'll be in vain. Then again, with how many projects I start not because they make sense but because I enjoy them, perhaps I should see it more in that way
And then to do it in C++ when other browsers and kernels are flirting with things like Rust. How long will it take for people to trust this new C++ code? I applaud the effort but am worried it'll be in vain. Then again, with how many projects I start not because they make sense but because I enjoy them, perhaps I should see it more in that way
I think the problem is that chrome and firefox are developed for general usage, and as a result, have to deal with general usage constraints. For example, spectre and process isolation mentioned in another blog post here in the comments. I had a project in the past where I needed a browser with good JS support, but that does not make any http requests to any resources not in address bar or in the page rendered at that address. I did not find single browser based on firefox/chrome that fulfilled that requirement. Even the most privacy-focused projects still made continious requests to some mozilla resources (if i remember correctly, it was something about tls or maybe something else). So seeing someone creating an engine from scratch gives me hope that such browser might exist one day if I ever will need one again.
There's a difference between privacy and stealth. Modern browsers need to do things like captive portal sensing, ocsp checks, etc. If you want to disable all requests, you'll need to spend time cutting legitimate features. Or run it in an external sandbox which removes all networking access?
> I don't understand what is wrong with Firefox.
It's developed by Mozilla, Google's controlled opposition. I submitted a link[0] on ads coming to Firefox but HN shadowed it almost immediately (present on /newest when logged in, nowhere to be found when logged out).
[0] https://www.jwz.org/blog/2024/06/mozilla-is-an-advertising-c...
It's developed by Mozilla, Google's controlled opposition. I submitted a link[0] on ads coming to Firefox but HN shadowed it almost immediately (present on /newest when logged in, nowhere to be found when logged out).
[0] https://www.jwz.org/blog/2024/06/mozilla-is-an-advertising-c...
That might be because Jamie Zawinski's website, which that link links to, does something ... special ... when it sees HN in the "Referer" field, so anyone actually following that link from here would (unless they take special measures) get IIRC a famous obscene image rather than the actual post you were hoping to link to.
(JWZ is not a fan of Hacker News and its community.)
(JWZ is not a fan of Hacker News and its community.)
All I see is a testicle in an egg-cup. Hardly special.
(Though it might be a good idea to special-case this to ad a non-referral link at submit time.)
(Though it might be a good idea to special-case this to ad a non-referral link at submit time.)
Ah, OK. My hazy memory was that it was the goatse.cx image, which is for most people more unpalatable than a testicle in an eggcup, but I didn't check exactly what it was :-).
Ok, didn't knew that. Still a dick move on HN's part. Shadowing should be restricted to abusers.
Wouldn't the submission get user flagged anyway? Because when people clicked it, they'd see something NSFW and devoid of interesting content.
Flagged for what? In this case user - me - was unaware that submitted content gets replaced when requested with Referer header mentioning HN. There should be a 'you cannot post this' warning instead of hidden post creation. I only noticed shadowban by accident: switched to logged-in browser to submit and went back to logged-out for browsing.
> Flagged for what?
Flagged for being NSFW and devoid of interesting content. The average user, like you, is unaware that the content they are seeing is different from the content you submitted.
Flagged for being NSFW and devoid of interesting content. The average user, like you, is unaware that the content they are seeing is different from the content you submitted.
What now? I love a good JWZ rant.
Introducing Anonym: Raising the bar for privacy-preserving digital advertising https://blog.mozilla.org/en/mozilla/mozilla-anonym-raising-t...
Oh.
How Brave of them.
Introducing Anonym: Raising the bar for privacy-preserving digital advertising https://blog.mozilla.org/en/mozilla/mozilla-anonym-raising-t...
Oh.
How Brave of them.
[deleted]
Even Mozilla doesn’t seem to care about Firefox; why should anybody else?
The primary value in Firefox existing right now is that the web standards process becomes dysfunctional when there are only two major browser rendering engines, but that is fading away with Firefox’s market share. Hopefully Ladybird can gain enough momentum to matter there because it doesn’t seem like Gecko can maintain its relevance.
The primary value in Firefox existing right now is that the web standards process becomes dysfunctional when there are only two major browser rendering engines, but that is fading away with Firefox’s market share. Hopefully Ladybird can gain enough momentum to matter there because it doesn’t seem like Gecko can maintain its relevance.
We're in the current situation because Google could spend enough money on promoting Chrome. That's it. A different, or even better browser won't change that. Google can put a chrome ad everywhere again for a few months.
I feel firefox market share is mostly because they actively enshittificate their browser, and not because of google ads, or chrome being better.
I disagree, IMO the main reason they lost so much marketshare to chrome was because for a long time, chrome just was much faster and much more stable. Performance, stability, and compatibility is all that matters to most users.
Firefox (mostly) caught up with quantum and process isolation on the desktop, but by then I think it was too late. And the android version still has horrible performance, stability, and compatibility compared to Chromium browsers.
Mozilla just doesn't have the same engineering resources to poor into the browser that google does, so I'm not sure there's any way they can really maintain pace with google outside of becoming yet another chromium browser.
Firefox (mostly) caught up with quantum and process isolation on the desktop, but by then I think it was too late. And the android version still has horrible performance, stability, and compatibility compared to Chromium browsers.
Mozilla just doesn't have the same engineering resources to poor into the browser that google does, so I'm not sure there's any way they can really maintain pace with google outside of becoming yet another chromium browser.
Doubt it. Things tech people complain about (like integration of Pocket) are completely irrelevant to the masses.
On the other hand, things like performance improved drastically, and it is now competitive with Chrome. Firefox the product is in the best shape it ever was.
On the other hand, things like performance improved drastically, and it is now competitive with Chrome. Firefox the product is in the best shape it ever was.
There's barely any enshitification in Firefox. People like to complain there, because any tiny addition looks bad in comparison. But it's not even close to Chrome's default. An average user is unlikely to notice either though.
But while Chrome was growing, the ad campaign was crazy. You could not miss it - Google results, Gmail header, every Adsense anywhere. Everyone was told to install Chrome when they used internet, every day - there was no escape.
But while Chrome was growing, the ad campaign was crazy. You could not miss it - Google results, Gmail header, every Adsense anywhere. Everyone was told to install Chrome when they used internet, every day - there was no escape.
Mozilla. I like and use Firefox but I find it increasingly hard to trust Mozilla and that makes me feel insecure about the future of Firefox.
Technically nothing; the problem lies entirely in the Mozilla Foundation which takes about $500B each year from Google. Officially the motivation is to keep Google as preferred search engine, but seriously the Firefox user base is so small that I don't even think Google would be interested for much less if there weren't strings attached that very likely create a huge conflict of interest if Mozilla become dependent on that money for their own survival.
https://www.bloomberg.com/news/newsletters/2023-05-05/why-go...
https://www.bloomberg.com/news/newsletters/2023-05-05/why-go...
> $500B
I think you may have made a typo. Possibly $500M?
I think you may have made a typo. Possibly $500M?
Whoops, apologies, you're right. I completely missed it and now it's too late to correct.
*million not billion
From my limited experience of Firefox-as-a-project, coming from the side of Thunderbird:
* Firefox is effectively not a community project. It seems to be ruled with an iron fist by the commercial side of the operation.
* Firefox broke its extensibility - which was the whole rationale of the Mozilla project to begin with.
* Lots of telemetry and call-home mechanisms, so much so that it is difficult to opt out even if you want to - in Thunderbird, and I believe also in Firefox; see : https://superuser.com/q/1672309/122798 (but correct me if I'm wrong and it's an app-specific thing).
* Firefox is effectively not a community project. It seems to be ruled with an iron fist by the commercial side of the operation.
* Firefox broke its extensibility - which was the whole rationale of the Mozilla project to begin with.
* Lots of telemetry and call-home mechanisms, so much so that it is difficult to opt out even if you want to - in Thunderbird, and I believe also in Firefox; see : https://superuser.com/q/1672309/122798 (but correct me if I'm wrong and it's an app-specific thing).
Well to put it bluntly, Firefox is Google's bitch.
If we want the web to be a multi-vendor platform based on open, multi-vendor standards, as it has been for parts of its history, how much does Firefox really buy us? Do we really think that Firefox will take a hard stand against Google if their survival depends on not doing so?
I use Firefox, but I think it's no longer true to its original mission in a lot of ways, Safari's global 18% share goes a lot farther toward making the web a duopolized rather than monopolized platform than Firefox's tiny sliver does. The less -opolized it is the better for society, or need I remind you that Google is presently mired in court for its conduct in its other web-adjacent monopolies such as web search and web advertising?
If we want the web to be a multi-vendor platform based on open, multi-vendor standards, as it has been for parts of its history, how much does Firefox really buy us? Do we really think that Firefox will take a hard stand against Google if their survival depends on not doing so?
I use Firefox, but I think it's no longer true to its original mission in a lot of ways, Safari's global 18% share goes a lot farther toward making the web a duopolized rather than monopolized platform than Firefox's tiny sliver does. The less -opolized it is the better for society, or need I remind you that Google is presently mired in court for its conduct in its other web-adjacent monopolies such as web search and web advertising?
What are you talking about? Mozilla repeatedly stands up to Google on big ticket items. Flock being probably the biggest in recent history, but you can throw Manifest v2 on the pile as well and about half a dozen others.
> Flock
For the benefit of those not in the know: FLoC https://wicg.github.io/floc/
For the benefit of those not in the know: FLoC https://wicg.github.io/floc/
By coincidence, jwz just blogged on this https://www.jwz.org/blog/2024/06/mozillas-original-sin/
[deleted]
Around Firefox 4 it became a shitshow of questionable UI redesign every version. And performances where not up to Chrome.
Also Chromium is open-source, and Firefox is mainly funded by Google so it not like Firefox has a real proposition value or independence.
Also Chromium is open-source, and Firefox is mainly funded by Google so it not like Firefox has a real proposition value or independence.
Not irrational at all. It’s the first new engine in decades, started by a single person in the open with no multibillion dollar company behind. We have every right to be exited.
Why is WebKit, the second most popular web engine worldwide, a "Chrome in a trench coat"? Actually WebKit is the Blink's older brother, whose father was KHTML.
Safari is 18% of global web traffic, 7x that of Firefox.
(from a hasty scan of caniuse.com)
(from a hasty scan of caniuse.com)
I challenge those numbers. Global stats aren't important, just the stats for your target audience. My sites see 13% Firefox, 35% Safari. But keep in mind, FF users sometimes spoof the Chrome user agent because some sites break otherwise. Further, I suspect FF users have tracking blockers at a higher rate, so they don't show up.
https://indieweb.social/@robalex/112472853515037460
https://indieweb.social/@robalex/112472853515037460
> just the stats for your target audience. My sites see 13% Firefox, 35% Safari.
So your stats back up my point that Safari is a popular browser. The post I was challenging completely ignored the existence of Safari and your post backs up mine. Thanks.
So your stats back up my point that Safari is a popular browser. The post I was challenging completely ignored the existence of Safari and your post backs up mine. Thanks.
Could it be that the technical nature of your website creates a biased sample? I'd estimate that the difference between Firefox and Chrome users in spoofing their user-agent and blocking trackers is far less than the bias created by sampling HN for example.
Absolutely, but since that's my target audience, that's the number I personally look at. Statements like "no one uses FF" don't apply. How skewed each target audience is from the global average is meaningful.
What about surf?
https://surf.suckless.org/
https://surf.suckless.org/
Isn’t this based on WebKit so it’s not really a new browser?
Yes, it's based on WebKit.
[deleted]
If they want adoption, maybe a good idea to build a hybrid ladybird/firefox browser, where, if some page does not render well in ladybird, the user can switch to firefox based rendering with a simple mouse click.
What would be the point of writing a whole new browser engine from scratch if you're just gonna fall back on a different one? Ladybird isn't ready and likely won't be for a long time. Treat this more like a "we're working on a new browser" type announcement, not a "We're launching a new browser today" announcement.
These sorts of things exist for the other browsers, so eventually I think Ladybird would support it as well.
https://chromewebstore.google.com/detail/open-in-firefox-bro...
https://chromewebstore.google.com/detail/open-in-firefox-bro...
A related question:
What's the state with Servo?
Do I understand it correctly that Servo is the core of a browser but not the browser itself? How much work would it be to create a browser on top of Servo? And is there such a project?
What's the state with Servo?
Do I understand it correctly that Servo is the core of a browser but not the browser itself? How much work would it be to create a browser on top of Servo? And is there such a project?
They actually have an official blog with status updates!
https://servo.org/blog/
They do have an official “browser”, ServoShell, which is basically a minimalistic testbed. IIRC adding tabs to it is on their roadmap.
https://servo.org/blog/
They do have an official “browser”, ServoShell, which is basically a minimalistic testbed. IIRC adding tabs to it is on their roadmap.
It looks like the repository for servoshell was archived in 2019. What’s weird is if you go to their website and download the tech demo it’s basically the same thing but may actually be updated.
Servoshell is developed here: https://github.com/servo/servo/tree/main/ports/servoshell
Oh, excellent. Thank you!
There is a Qt webview using Servo engine: https://github.com/KDABLabs/cxx-qt-servo-webview
I was recently browsing their docs, and kept finding references to choosing a "browser chrome" (options including Qt and AppKit). Is this some new usage of the word "chrome" that I'm not familiar with, or does it use chrome libraries?
Google co-opted an already common term into a Proper Noun™.
https://developer.mozilla.org/en-US/docs/Glossary/Chrome
http://www.catb.org/%7Eesr/jargon/html/C/chrome.html
Netscape called it that and thus so does Mozilla. Try loading up `chrome://branding/content/about-logo.png` for an example of the chrome URI scheme in Firefox!
https://developer.mozilla.org/en-US/docs/Glossary/Chrome
http://www.catb.org/%7Eesr/jargon/html/C/chrome.html
Netscape called it that and thus so does Mozilla. Try loading up `chrome://branding/content/about-logo.png` for an example of the chrome URI scheme in Firefox!
Around the turn of the century, the "Mozilla" browser used to support themes for its chrome, written in XUL [0], which also supported inline images. The themes were available in a repository called "Chrome Zone".
Google later appropriated also the name "Chrome Zone", for a chain of retail stores in the UK. [1]
[0]. https://en.wikipedia.org/wiki/XUL
[1]. https://en.wikipedia.org/wiki/Chrome_Zone
Google later appropriated also the name "Chrome Zone", for a chain of retail stores in the UK. [1]
[0]. https://en.wikipedia.org/wiki/XUL
[1]. https://en.wikipedia.org/wiki/Chrome_Zone
Specifically google originally chose that name for chrome because one of their goals was reduction of chrome. They made a bit deal out of it when the browser was new, how it didn't have a bunch of menu bars or whatever
The Scott McCloud comic mentions this on page #24: https://www.google.com/googlebooks/chrome/big_24.html
It's a usage that predates and conceivably inspired Google-brand Chrome (and by contrast arguably Rust?), referring to the UI parts of the browser rather than, I think, rendering and javascript and stuff.
The term "window chrome" is common to describe the parts of a window that are outside the client rectangle and managed by the window system (titlebar, scroll bars, resize widgets etc..). AFAIK the term also predates "Chrome, the browser" by a long time.
The "chrome" of an app is the part surrounding the main windows, like toolbars and the such.
IIRC when Chrome appeared, the name was chosen because it was a browser without chrome (ie: it used to be just the rendering windows with the url bar on top), differently from other browsers at the time.
IIRC when Chrome appeared, the name was chosen because it was a browser without chrome (ie: it used to be just the rendering windows with the url bar on top), differently from other browsers at the time.
As per https://en.wikipedia.org/wiki/Chrome:
>User interface chrome, the borders and widgets that frame the content part of a window
>User interface chrome, the borders and widgets that frame the content part of a window
Firefox always referred to its user interface as the chrome (hence userchrome.css) and Google engineers decided that it should be funny to name their browser that.
[deleted]
>Is this some new usage of the word "chrome" that I'm not familiar with, or does it use chrome libraries?
Neither.
Neither.
That's the old usage of the word "chrome", as far as I know.
It's "chrome" as in cars and bikes.
I was very impressed by the build script. It worked flawlessly, detecting Clang and Ninja, and pulled in all the dependencies automatically. I am hopefully that this will develop into a serious competitor as there really should be more than 2 choices (KHTML-based vs Gecko-based).
From the linked site:
> In the post-Spectre world you must have site isolation. The JS for a site (roughly, eTLD+1) must have its own OS address space separate from other sites.
Wasn't the whole point of Spectre/Meltdown to read the virtual address space of a different process?
> In the post-Spectre world you must have site isolation. The JS for a site (roughly, eTLD+1) must have its own OS address space separate from other sites.
Wasn't the whole point of Spectre/Meltdown to read the virtual address space of a different process?
As I understand it:
Meltdown lets a process read from kernel memory.
There are several variations of Spectre. The first variant ("Spectre V1") lets a process read its own memory; the second variant ("Spectre V2") lets a process read another process's memory.
Web browser manufacturers seem to be focused on preventing Spectre V1, although I'm unclear on whether that's because V2 is too hard to exploit from JavaScript, is mitigated in other ways (e.g., CPU updates), etc.
Further reading: https://stackoverflow.com/q/53042230/25507, https://stackoverflow.com/q/48200753/25507, https://security.googleblog.com/2018/07/mitigating-spectre-w..., https://webkit.org/blog/8048/what-spectre-and-meltdown-mean-..., https://en.wikipedia.org/wiki/Spectre_(security_vulnerabilit...
Meltdown lets a process read from kernel memory.
There are several variations of Spectre. The first variant ("Spectre V1") lets a process read its own memory; the second variant ("Spectre V2") lets a process read another process's memory.
Web browser manufacturers seem to be focused on preventing Spectre V1, although I'm unclear on whether that's because V2 is too hard to exploit from JavaScript, is mitigated in other ways (e.g., CPU updates), etc.
Further reading: https://stackoverflow.com/q/53042230/25507, https://stackoverflow.com/q/48200753/25507, https://security.googleblog.com/2018/07/mitigating-spectre-w..., https://webkit.org/blog/8048/what-spectre-and-meltdown-mean-..., https://en.wikipedia.org/wiki/Spectre_(security_vulnerabilit...
As I understand it: Spectre/Meltdown allow reading from the address space of the same process only. If browsers put different origins in the same process - which they used to - then JS code can break the same-origin security barrier and read details of other origins directly from memory. By putting each origin in its own OS address space they are protected from this attack as JS can still only read data from its own origin even when using security flaws to read any part of the address space.
> As I understand it: Spectre/Meltdown allow reading from the address space of the same process only.
Sorry, this does not make much sense. Why would you need a timing attack to read memory from your own address space? Just a regular code execution exploit should do it.
Here, I found the relevant info (that I was too lazy to find before I posted my first comment, apparently):
https://meltdownattack.com/
> While programs are typically not permitted to read data from other programs, a malicious program can exploit Meltdown and Spectre to get hold of secrets stored in the memory of other running programs.
Sorry, this does not make much sense. Why would you need a timing attack to read memory from your own address space? Just a regular code execution exploit should do it.
Here, I found the relevant info (that I was too lazy to find before I posted my first comment, apparently):
https://meltdownattack.com/
> While programs are typically not permitted to read data from other programs, a malicious program can exploit Meltdown and Spectre to get hold of secrets stored in the memory of other running programs.
> Sorry, this does not make much sense. Why would you need a timing attack to read memory from your own address space?
If you're making a VM such that the running code can only access a particular array, Spectre allows a timing attack that can get malicious code in the VM access to the full memory space.
You're right that it's not that scary for most use cases. What it really means is that it's hopeless to make memory inaccessible to a sandbox without putting a process isolation barrier betwixt the two, as there's no real way to close out all of the timing attack possibilities. In principle, if the only thing you needed to foreclose was memory vulnerabilities, then sufficiently good programming™ would let you have the sandbox in the same process space; as a matter of practice, though, anyone looking at product security seriously would still make you put in process isolation, because that kind of good programming just doesn't exist at scale yet.
(Note that Meltdown, but not Spectre, allows timing attacks that cross process isolation domains.)
If you're making a VM such that the running code can only access a particular array, Spectre allows a timing attack that can get malicious code in the VM access to the full memory space.
You're right that it's not that scary for most use cases. What it really means is that it's hopeless to make memory inaccessible to a sandbox without putting a process isolation barrier betwixt the two, as there's no real way to close out all of the timing attack possibilities. In principle, if the only thing you needed to foreclose was memory vulnerabilities, then sufficiently good programming™ would let you have the sandbox in the same process space; as a matter of practice, though, anyone looking at product security seriously would still make you put in process isolation, because that kind of good programming just doesn't exist at scale yet.
(Note that Meltdown, but not Spectre, allows timing attacks that cross process isolation domains.)
It feels very linux-y, I wish it was easier to contribute to Firefox so those efforts would go towards stopping the google monopoly.
It is a perfect time for new browser. I long for the days of good old Opera, when each release brought something new and fresh. Multiple browser windows in tiled layout, browser gestures, disabling image loading from UI (although that was standard feature in dial-up era of internet), UI customization, integrated email client and feed reader.
I don't want to discourage the developers working on this project, but I'm curious why we're still writing applications that will almost certainly execute or process hostile content in languages that don't maintain strict memory safe contract?
Have we not learned our lesson yet, or am I misunderstanding the situation? I believe it was a Microsoft study that linked unsafe memory access to ~70% of exploit chains.
Have we not learned our lesson yet, or am I misunderstanding the situation? I believe it was a Microsoft study that linked unsafe memory access to ~70% of exploit chains.
I'll take an alternative browser engine, even if it's written in C++.
> I'm curious
Is it really curiosity though? Because the answer is straightforward, the project started as a hobby, the developer picked whatever language they were proficient in. Andreas is open with the fact that he started Serenity OS and LadyBird as a rehab project. Put too much barrier in this setting (like learning a new language and all the ecosystem) and it might not happen at all.
> I'm curious
Is it really curiosity though? Because the answer is straightforward, the project started as a hobby, the developer picked whatever language they were proficient in. Andreas is open with the fact that he started Serenity OS and LadyBird as a rehab project. Put too much barrier in this setting (like learning a new language and all the ecosystem) and it might not happen at all.
>> I'm curious
> Is it really curiosity though?
I'm kind of annoyed at this whole train of comments ("I'm curious..."). In so many occasion I see something cool and the main comment track is "why hasn't this been writte in rust?" (or some other allegedly safe/better programming language).
It's like seeing a beautiful painting being painted and arguing about the kind of paintbrush the painter has used.
It's so sad.
> Is it really curiosity though?
I'm kind of annoyed at this whole train of comments ("I'm curious..."). In so many occasion I see something cool and the main comment track is "why hasn't this been writte in rust?" (or some other allegedly safe/better programming language).
It's like seeing a beautiful painting being painted and arguing about the kind of paintbrush the painter has used.
It's so sad.
> It's like seeing a beautiful painting being painted and arguing about the kind of paintbrush the painter has used.
No it is not. You don't use your browser for its artistic value (which is in the eye of the beholder). You also don't make an announcement for a painting.
This is more like using a non-inox screw in a high-humidity environment. Yes, it will hold on for a while. But it is objectively a bad choice. Non-inox may had been the only choice 300 years back, but this is 2024.
And writing a browser from scratch is a huge undertaking. When you invest resources in such a project, you probably want it to be more weatherproof than its C/C++-based predecessors. So it is quite reasonable IMHO to ask why C++ was chosen for this project.
No it is not. You don't use your browser for its artistic value (which is in the eye of the beholder). You also don't make an announcement for a painting.
This is more like using a non-inox screw in a high-humidity environment. Yes, it will hold on for a while. But it is objectively a bad choice. Non-inox may had been the only choice 300 years back, but this is 2024.
And writing a browser from scratch is a huge undertaking. When you invest resources in such a project, you probably want it to be more weatherproof than its C/C++-based predecessors. So it is quite reasonable IMHO to ask why C++ was chosen for this project.
90% of all safety critical software is written in c/c++
There is no good safety language right now to write a browser in, except for c/c++. Rust might sound like an alternative but it's safety story is sad when compared to c/c++.
Ada might be a cool option, so is ATS.
There is no good safety language right now to write a browser in, except for c/c++. Rust might sound like an alternative but it's safety story is sad when compared to c/c++.
Ada might be a cool option, so is ATS.
That’s a pretty cynical view. It’s more like asking why a car manufacturer is developing a car without modern safety mechanisms despite knowing those mechanisms save lives.
If this is a work of art whose code is to be admired and only viewed as a creative work, fine I’m sorry I asked the question and that it was criticism of one’s vision.
However, if this is something that is intended to be “driven” by other users in the future I think it’s a perfectly acceptable question to ask why more modern safety mechanisms are not being employed. Maybe there is a rationale I’m unaware of or a reason why those mechanisms are not employed.
If this is a work of art whose code is to be admired and only viewed as a creative work, fine I’m sorry I asked the question and that it was criticism of one’s vision.
However, if this is something that is intended to be “driven” by other users in the future I think it’s a perfectly acceptable question to ask why more modern safety mechanisms are not being employed. Maybe there is a rationale I’m unaware of or a reason why those mechanisms are not employed.
It's not cynical. It's how many of us feel when we read a comment like this.
I believe you are right. But I also think that your phrasing is not very nice. It shows a lack of empathy and understanding and feels entitled.
You could convey essentially the same message but be way nicer to everyone involved, and that would be way more efficient.
If your ideal is a browser engine written in a safer language, and want to work towards that goal, phrasing things the way you did in your comment is one of the worst way to do it because you risk putting off people and they will associate this bad feeling to your idea. See how people react to comments about Rust.
Some of your options are:
- writing a browser engine yourself, in a safer language
- contributing to an existing browser engine like Servo
- convince projects to switch to a safer language, or to accept contributions in a safer language
- convince someone or a group of people to do those things
- fund such an enterprise
At this point, the world needs proof that a browser engine can practically be written in something else than C++, because it's what all three major engines are written in. There are strong evidences that Rust can be an option given the existence of Servo, but look how Ladybird is progressing so absurdly faster than Servo.
If you don't work yourself towards your goal, you can only humbly share your wish.
Lobbying is fine too, but you really need to make sure you don't make others hate your idea because of the way you communicate. Specifically in this topic, you need to take in account that many people are already annoyed by the numerous "why not Rust" comments, so you are walking on eggshells.
What's more, don't forget the global picture, and that security (although critical, we agree) is only one aspect. Security is irrelevant in a project that doesn't even exist. C++ is better than other languages for a lot of reasons in other aspects and you will need to address this, in the context of writing a browser.
Good luck in your endeavors, I hope you succeed, I believe it's a good ideal.
I believe you are right. But I also think that your phrasing is not very nice. It shows a lack of empathy and understanding and feels entitled.
You could convey essentially the same message but be way nicer to everyone involved, and that would be way more efficient.
If your ideal is a browser engine written in a safer language, and want to work towards that goal, phrasing things the way you did in your comment is one of the worst way to do it because you risk putting off people and they will associate this bad feeling to your idea. See how people react to comments about Rust.
Some of your options are:
- writing a browser engine yourself, in a safer language
- contributing to an existing browser engine like Servo
- convince projects to switch to a safer language, or to accept contributions in a safer language
- convince someone or a group of people to do those things
- fund such an enterprise
At this point, the world needs proof that a browser engine can practically be written in something else than C++, because it's what all three major engines are written in. There are strong evidences that Rust can be an option given the existence of Servo, but look how Ladybird is progressing so absurdly faster than Servo.
If you don't work yourself towards your goal, you can only humbly share your wish.
Lobbying is fine too, but you really need to make sure you don't make others hate your idea because of the way you communicate. Specifically in this topic, you need to take in account that many people are already annoyed by the numerous "why not Rust" comments, so you are walking on eggshells.
What's more, don't forget the global picture, and that security (although critical, we agree) is only one aspect. Security is irrelevant in a project that doesn't even exist. C++ is better than other languages for a lot of reasons in other aspects and you will need to address this, in the context of writing a browser.
Good luck in your endeavors, I hope you succeed, I believe it's a good ideal.
I will attempt to word my questions/thoughts in a less confrontational way in the future. I tend to write my questions in the same way they occur in my internal monologue. I understand how that comes across to some.
I’m happy there is someone out there genuinely interested in creating another alternative to the near monoculture that is web browsers. I hope that they gain traction in the open source community as well as wider adoption upon maturity.
I’ll try to follow the project development and maybe I can learn myself why other languages may not be as well suited as C++. It seems that language proficiency is the most common answer I’ve received besides earned criticism of the way I formed my question.
I’m happy there is someone out there genuinely interested in creating another alternative to the near monoculture that is web browsers. I hope that they gain traction in the open source community as well as wider adoption upon maturity.
I’ll try to follow the project development and maybe I can learn myself why other languages may not be as well suited as C++. It seems that language proficiency is the most common answer I’ve received besides earned criticism of the way I formed my question.
> It's like seeing a beautiful painting being painted and arguing about the kind of paintbrush the painter has used.
It's like seeing a beautiful painting and realizing the painter didn't use lightfast colors. In ten years the painting will not be beautiful anymore.
Yes, the painter / author put in a lot of work, and this deserves acknowledgement. But ones decision to use it or not is not only based on the amount of work put in.
It's like seeing a beautiful painting and realizing the painter didn't use lightfast colors. In ten years the painting will not be beautiful anymore.
Yes, the painter / author put in a lot of work, and this deserves acknowledgement. But ones decision to use it or not is not only based on the amount of work put in.
The question ("Why not a memory safe language?") has never been more appropriate than when we're talking about writing a web browser.
> Is it really curiosity though?
it's not - it's a stock standard way to ask a question in bad faith.
it's not - it's a stock standard way to ask a question in bad faith.
It’s curiosity because I’m involved in software security for the company I work for and I’m a software developer that primarily works with managed languages. I unfortunately lack the technical expertise to make an assessment on interpreters and virtual machines. I am, however, aware that many of the CVEs that I review involve reading/writing memory outside the intended bounds. Many of these while processing user generated content.
I appreciate that the author birthed the project as a way to direct his energies towards more productive means. I don’t think it’s relevant to the question though.
I appreciate that the author birthed the project as a way to direct his energies towards more productive means. I don’t think it’s relevant to the question though.
On the v8 engine's blog, it is claimed that most of its vulnerabilities are caused by logic issues which Rust wouldn't help with.
Perhaps it's a similar situation for Ladybird.
>Memory safety remains a relevant problem: all Chrome exploits caught in the wild in the last three years (2021 – 2023) started out with a memory corruption vulnerability in a Chrome renderer process that was exploited for remote code execution (RCE). Of these, 60% were vulnerabilities in V8.
> V8 vulnerabilities are rarely "classic" memory corruption bugs (use-after-frees, out-of-bounds accesses, etc.) but instead subtle logic issues which can in turn be exploited to corrupt memory. As such, existing memory safety solutions are, for the most part, not applicable to V8. In particular, neither switching to a memory safe language, such as Rust, nor using current or future hardware memory safety features, such as memory tagging, can help with the security challenges faced by V8 today.
See: https://v8.dev/blog/sandbox
Perhaps it's a similar situation for Ladybird.
>Memory safety remains a relevant problem: all Chrome exploits caught in the wild in the last three years (2021 – 2023) started out with a memory corruption vulnerability in a Chrome renderer process that was exploited for remote code execution (RCE). Of these, 60% were vulnerabilities in V8.
> V8 vulnerabilities are rarely "classic" memory corruption bugs (use-after-frees, out-of-bounds accesses, etc.) but instead subtle logic issues which can in turn be exploited to corrupt memory. As such, existing memory safety solutions are, for the most part, not applicable to V8. In particular, neither switching to a memory safe language, such as Rust, nor using current or future hardware memory safety features, such as memory tagging, can help with the security challenges faced by V8 today.
See: https://v8.dev/blog/sandbox
> which Rust wouldn't help with
Technically no. But if you can decrease those 40% where it could help you can than focus more on the logic issues. Maybe.
Technically no. But if you can decrease those 40% where it could help you can than focus more on the logic issues. Maybe.
40% may not be a majority, but it's still close to half of all Chrome exploits in the wild, and they could be avoided with a memory-safe toolchain. (Doesn't have to be Rust.)
As for the other 60%, they point to logic errors as the root cause, but that's true of all memory corruption bugs: they wouldn't exist if there weren't logic errors behind them. The actual difference here is that the vulnerabilities are either in the machine code generated by the JIT (e.g. type confusion), rather than V8's own code; or they're in code they insist must be memory-unsafe for performance reasons.
So the takeaway there should be that JS engines for hostile code should either not use a JIT at all, nor memory-unsafe code paths, or use stronger tools to verify the correctness of the JIT and those code paths. But hey, retaining the capability to speed up bloated web apps ever so slightly is more important that
As for the other 60%, they point to logic errors as the root cause, but that's true of all memory corruption bugs: they wouldn't exist if there weren't logic errors behind them. The actual difference here is that the vulnerabilities are either in the machine code generated by the JIT (e.g. type confusion), rather than V8's own code; or they're in code they insist must be memory-unsafe for performance reasons.
So the takeaway there should be that JS engines for hostile code should either not use a JIT at all, nor memory-unsafe code paths, or use stronger tools to verify the correctness of the JIT and those code paths. But hey, retaining the capability to speed up bloated web apps ever so slightly is more important that
I believe the fact that V8 vulnerabilities are not "classic" memory corruption can be attributed to their developers' experience and review processes.
This doesn't imply, though, that another project in C++ will share these traits.
This doesn't imply, though, that another project in C++ will share these traits.
Andreas (the author of ladybird) started a language[0] that would be memory-safe and in which he would eventually write SerenityOS (and I assume LadyBird too). He hasn't committed to it for 6 months now so not sure what the status is.
At the end of the day, LadyBird is still a hobby project, so one of the main objective is to have fun which does not always coincide with rationality (although the decision to move on from NIH[1] is a sign that this might be changing).
[0] https://github.com/SerenityOS/jakt
[1] https://en.wikipedia.org/wiki/Not_invented_here
At the end of the day, LadyBird is still a hobby project, so one of the main objective is to have fun which does not always coincide with rationality (although the decision to move on from NIH[1] is a sign that this might be changing).
[0] https://github.com/SerenityOS/jakt
[1] https://en.wikipedia.org/wiki/Not_invented_here
Ladybird is sponsored now and I seem to remember that Andreas is paid full time to work on it. I don't think Ladybird is still strictly a hobby project anymore.
But it was definitely started as a hobby project so your point still stands, mostly.
(to be clear, I'm not answering to the question of which programming language should be used to write Ladybird)
But it was definitely started as a hobby project so your point still stands, mostly.
(to be clear, I'm not answering to the question of which programming language should be used to write Ladybird)
Jakt was described more as an experiment and to potentially replace C++ in the codebase, rather than definitely. I haven't seen any official word on this but as you imply I would assume that this effort is essentially dead now. Just as with the operating system itself, the focus eventually shifted elsewhere and Jakt was left behind.
> but I'm curious why we're still writing applications
> Have we not learned our lesson yet,
"We"? Do you speak in the name of the developer? What an odd choice of pronoum.
Either way, if you are adamant about writing a new browser in your "memory-safe language" of choice, be the change you want made. Go ahead and write a new browser from scratch. Show the world how it should be done.
> Have we not learned our lesson yet,
"We"? Do you speak in the name of the developer? What an odd choice of pronoum.
Either way, if you are adamant about writing a new browser in your "memory-safe language" of choice, be the change you want made. Go ahead and write a new browser from scratch. Show the world how it should be done.
I meant we as in the collective, and I explicitly referenced the collective of those writing applications that process and/or execute user generated content. So no, I don’t think it appropriate to focus my question on the author or this project. I am wondering if C++ is a better choice for reasons I don’t understand when it comes to HTML/JS/CSS, despite potential security implications as the complexity grows.
> in languages that don't maintain strict memory safe contract?
for the same reason people still use the English language, despite being full of crazy inconsistencies and being very hard to become a native speaker, coming from another language: proficiency.
Proficiency is one of the most, if not the most, valuable metric when choosing the tool you will use to take on some complex/daunting task.
for the same reason people still use the English language, despite being full of crazy inconsistencies and being very hard to become a native speaker, coming from another language: proficiency.
Proficiency is one of the most, if not the most, valuable metric when choosing the tool you will use to take on some complex/daunting task.
The language “legalese” was invented when it turned out that being proficient in English does not protect you against malicious contract partners.
(The success of legalese is still debated, but its existence is generally accepted)
(The success of legalese is still debated, but its existence is generally accepted)
legalese is a subset of English.
BTW Rust (or any other so called "memory safe" language) is not the equivalent of legalese, it's the equivalent of using French because it's the "language of diplomacy" (that's why many English words come from French) instead of English.
If you're not proficient in French, French legalese won't save you.
BTW Rust (or any other so called "memory safe" language) is not the equivalent of legalese, it's the equivalent of using French because it's the "language of diplomacy" (that's why many English words come from French) instead of English.
If you're not proficient in French, French legalese won't save you.
Could you explain your thinking a bit more? To me the "language of diplomacy" equivalent for computers sounds more like C calling convention, HTTP and XML or JSON.
Nobody is saying there is a programming equivalent of the language of diplomacy. He said that using Rust to achieve memory safety is analogous to using French for diplomacy, in that, whatever value the language itself might bring to that goal, you are not likely to achieve it if you are not proficient.
If you are not proficient in French, you likely ought not to conduct diplomacy in French.
If you are not proficient in Rust, you likely ought not to achieve memory safety by writing everything in Rust.
If you are not proficient in French, you likely ought not to conduct diplomacy in French.
If you are not proficient in Rust, you likely ought not to achieve memory safety by writing everything in Rust.
Ok, I'll try to explain.
- French itself does not add much value to diplomacy. The reason to use is that everyone else who does diplomacy is expected to know French (and probably isn't a native speaker which makes things a bit more equal). English is probably taking over there, like it has done in other domains.
- The recent C++ versions are not actively promoting shooting yourself in the foot like older variants, but they aren't exactly trying to prevent it.
- Rust is going out of its way to prevent writing memory unsafe code. It is still possible if you know what you are doing, but just trying out stuff at random is more likely to give you a compile-time error than undefined behaviour.
- Most programmers aren't very competent, not matter what they believe about themselves. With Rust they are less likely to commit serious errors. Or get anything done, but that's a separate discussion. The French will probably point out your pronunciation mistakes too before continuing discussion, but that's also not the point here.
- French itself does not add much value to diplomacy. The reason to use is that everyone else who does diplomacy is expected to know French (and probably isn't a native speaker which makes things a bit more equal). English is probably taking over there, like it has done in other domains.
- The recent C++ versions are not actively promoting shooting yourself in the foot like older variants, but they aren't exactly trying to prevent it.
- Rust is going out of its way to prevent writing memory unsafe code. It is still possible if you know what you are doing, but just trying out stuff at random is more likely to give you a compile-time error than undefined behaviour.
- Most programmers aren't very competent, not matter what they believe about themselves. With Rust they are less likely to commit serious errors. Or get anything done, but that's a separate discussion. The French will probably point out your pronunciation mistakes too before continuing discussion, but that's also not the point here.
> - French itself does not add much value to diplomacy.
Funny, given that the word diplomacy is a French word, together with embassy, treaty, alliance, passport and protocol :)
> Rust is going out of its way to prevent writing memory unsafe code
But if someone is not proficient in Rust it will only slow them down and they'll end up fighting the language and the compiler instead of using the language.
It's a common complain among non Rust programmers.
> Most programmers aren't very competent
I strongly believe Andreas Kling is very competent.
For the rest of us who are not him, incompetence does not go well in hand with Rust, which is a very complex language.
EDIT: pretending that a very proficient C++ programmer will chose Rust because "it's 2024" it's the same thing as pretending that they will chose Haskell, which is equally memory safe and also equally complex.
Why nobody ever recommend Haskell or Smalltalk?
It doesn't seem much like a discussion about memory safety to me, but rather promoting Rust.
Funny, given that the word diplomacy is a French word, together with embassy, treaty, alliance, passport and protocol :)
> Rust is going out of its way to prevent writing memory unsafe code
But if someone is not proficient in Rust it will only slow them down and they'll end up fighting the language and the compiler instead of using the language.
It's a common complain among non Rust programmers.
> Most programmers aren't very competent
I strongly believe Andreas Kling is very competent.
For the rest of us who are not him, incompetence does not go well in hand with Rust, which is a very complex language.
EDIT: pretending that a very proficient C++ programmer will chose Rust because "it's 2024" it's the same thing as pretending that they will chose Haskell, which is equally memory safe and also equally complex.
Why nobody ever recommend Haskell or Smalltalk?
It doesn't seem much like a discussion about memory safety to me, but rather promoting Rust.
> Funny, given that the word diplomacy is a French word
This is true. But it only tells about the cultural dominance that France had at the time the convention started. If history had happened differently, Chinese, Hindi or something else could be in similar position.
> But if someone is not proficient in Rust it will only slow them down and they'll end up fighting the language and the compiler instead of using the language.
This is indeed the choice. Make it difficult to write code but more likely that the result is correct, easy to achieve high performance but risky (C++ and similar) or just accept the overhead of checking everything over at run time (JVM and CLR languages, etc). I would say there is a niche for the first.
> Why nobody ever recommend Haskell or Smalltalk?
I think at this point it's well known that the pure functional lazy evaluation model rules out too many useful data structures and makes it easy to introduce accidental complexity. As for Smalltalk, it seems (I've never actually used it) to me that most of its once unique ideas have been copied to current mainstream languages. It also seems to have a huge number of fragmented implementations and most of them seem to have a heavy runtime virtual machine.
This is true. But it only tells about the cultural dominance that France had at the time the convention started. If history had happened differently, Chinese, Hindi or something else could be in similar position.
> But if someone is not proficient in Rust it will only slow them down and they'll end up fighting the language and the compiler instead of using the language.
This is indeed the choice. Make it difficult to write code but more likely that the result is correct, easy to achieve high performance but risky (C++ and similar) or just accept the overhead of checking everything over at run time (JVM and CLR languages, etc). I would say there is a niche for the first.
> Why nobody ever recommend Haskell or Smalltalk?
I think at this point it's well known that the pure functional lazy evaluation model rules out too many useful data structures and makes it easy to introduce accidental complexity. As for Smalltalk, it seems (I've never actually used it) to me that most of its once unique ideas have been copied to current mainstream languages. It also seems to have a huge number of fragmented implementations and most of them seem to have a heavy runtime virtual machine.
> This is true. But it only tells about the cultural dominance that France
French is still very much relevant, but it took centuries to make it less relevant than before to the point where we are now.
Rust in comparison is minutes old and there's no evidence it will dominate the field of system programming in the future. See: Ruby on Rails for web development.
> This is indeed the choice. Make it difficult to write code but more likely that the result is correct
I don't buy it.
Making it hard to write code it's nobody's choice, it's accidental complexity, that any sane language designer would avoid if possible, because it severely hinders the language adoption.
The opposite is also true: code easy to write will also be more easily correct.
Elixir is easy to write and will almost automatically be correct in complex scenarios such as distributed systems.
> pure functional lazy evaluation model rules out too many useful data structures
Rust is Haskell with a different syntax though and makes it very hard to write simple linked lists.
> most of its once unique ideas have been copied to current mainstream languages
same happened to FP, ROR and it's happening with Rust
Even Java is more functional than ever, because it's a good paradigm, not because it's a fad.
Again: this seems to me more promoting Rust than a discussion about memory safety and I am really not interested in that. So I'll see myself out.
French is still very much relevant, but it took centuries to make it less relevant than before to the point where we are now.
Rust in comparison is minutes old and there's no evidence it will dominate the field of system programming in the future. See: Ruby on Rails for web development.
> This is indeed the choice. Make it difficult to write code but more likely that the result is correct
I don't buy it.
Making it hard to write code it's nobody's choice, it's accidental complexity, that any sane language designer would avoid if possible, because it severely hinders the language adoption.
The opposite is also true: code easy to write will also be more easily correct.
Elixir is easy to write and will almost automatically be correct in complex scenarios such as distributed systems.
> pure functional lazy evaluation model rules out too many useful data structures
Rust is Haskell with a different syntax though and makes it very hard to write simple linked lists.
> most of its once unique ideas have been copied to current mainstream languages
same happened to FP, ROR and it's happening with Rust
Even Java is more functional than ever, because it's a good paradigm, not because it's a fad.
Again: this seems to me more promoting Rust than a discussion about memory safety and I am really not interested in that. So I'll see myself out.
> Rust in comparison is minutes old and there's no evidence it will dominate the field of system programming in the future.
This is true (for some values of minute). It is also why I was suggesting that C calling convention, HTTP etc, not Rust, would be the computing lingua franca. Now that I think of it, a few years ago TCP/IP would have been on the list but now with HTTP/3 it's not that certain any more.
> Rust is Haskell with a different syntax though...
This is quite bold claim, but if you have a rigorous proof beyond "all Turing complete languages are the same" I would be interested in seeing it. It's a pity you left.
> ...makes it very hard to write simple linked lists.
This is interesting in the light of the beginning of the sentence, because in Haskell linked list is the easiest data structure. Simple linked lists aren't always that simple though. There is a reason why they used to be a recurring technical interview question.
> Again: this seems to me more promoting Rust than a discussion about memory safety
Funny, to me this seems more about promoting JIT and garbage collection. Nothing wrong with that, as long as you admit that there are niches where those are a problem but memory safety is still useful. And so far there haven't been other serious language candidates for that niche.
This is true (for some values of minute). It is also why I was suggesting that C calling convention, HTTP etc, not Rust, would be the computing lingua franca. Now that I think of it, a few years ago TCP/IP would have been on the list but now with HTTP/3 it's not that certain any more.
> Rust is Haskell with a different syntax though...
This is quite bold claim, but if you have a rigorous proof beyond "all Turing complete languages are the same" I would be interested in seeing it. It's a pity you left.
> ...makes it very hard to write simple linked lists.
This is interesting in the light of the beginning of the sentence, because in Haskell linked list is the easiest data structure. Simple linked lists aren't always that simple though. There is a reason why they used to be a recurring technical interview question.
> Again: this seems to me more promoting Rust than a discussion about memory safety
Funny, to me this seems more about promoting JIT and garbage collection. Nothing wrong with that, as long as you admit that there are niches where those are a problem but memory safety is still useful. And so far there haven't been other serious language candidates for that niche.
[deleted]
Don't do this. Requesting an explanation just to get an excuse to launch into a spiel is deeply dishonest. Furthermore, ideological battle is against HN Guidelines.
[deleted]
This makes the most sense and thank you for offering a genuine answer to my question. Which leads to a follow-up question.
Has the rise of these memory safe languages caused any shift in the proficiencies of the average developer?
I see a lot of younger people gush over python early in their careers but see a lot of Java/.NET in enterprise.
I personally grew up learning Delphi, PHP, and HTML. Java and .NET came later, but I rarely had a hand in initiating the projects so my language proficiency typically flowed with the job/project I was working on professionally.
Has the rise of these memory safe languages caused any shift in the proficiencies of the average developer?
I see a lot of younger people gush over python early in their careers but see a lot of Java/.NET in enterprise.
I personally grew up learning Delphi, PHP, and HTML. Java and .NET came later, but I rarely had a hand in initiating the projects so my language proficiency typically flowed with the job/project I was working on professionally.
> Has the rise of these memory safe languages caused any shift in the proficiencies of the average developer?
That's a good question, but I have no answer for it.
AFAIK the data is missing or is inconsistent.
But I can link to you the obligatory Ken Thompson's "three weeks away from an OS"
https://youtu.be/EY6q5dv_B-o?t=1360&si=Nx6dK4KigZJ3962F
That's a good question, but I have no answer for it.
AFAIK the data is missing or is inconsistent.
But I can link to you the obligatory Ken Thompson's "three weeks away from an OS"
https://youtu.be/EY6q5dv_B-o?t=1360&si=Nx6dK4KigZJ3962F
Because writing a browser in ATS or Frama-C is not possible. Or writing it in Coq and exporting it to ocaml and friends.
Ada can be used but its mediocre at best and sucks at places where frama-C shines. A lot of pointer stuff that is easier to prove in ATS or frama-C is impossible in Ada [and by extension of that, rust]
TLA+ can be used in mix with C++ just like how 90% of safety critical software is written but the development speed is very slow for it.
That leaves Rust, which is a...mediocre language if you really care about safety. It has no idea of linear types that ATS has and cannot carry embedded proofs like Frama-C.
Plus the culture regarding safety critical software in C/C++ is humongous and tbh fairly amazing.
I cannot remember exactly but there are many projects targeting C++ for safety purposes, even the people behind frama-C are creating something called as frama-Clang to allow writing safety critical code in C++ backed by proofs.
Are there any other languages that im missing? If ATS has a prettier syntax, it'd be my candidate for writing a web browser in.
Are there any other languages that im missing? If ATS has a prettier syntax, it'd be my candidate for writing a web browser in.
Note that despite that study, Windows and XBox teams are quite found of their C and C++, and even their own .NET has more success on the Azure side, than replacing all those COM/WinRT C++ workloads, and extension points.
It is Azure that is more keen in adopting memory safe languages, and has the mandate that new systems code should be done using them.
It is Azure that is more keen in adopting memory safe languages, and has the mandate that new systems code should be done using them.
> Note that despite that study, Windows and XBox teams are quite found of their C and C++...
And we all know how secure the average user's Windows computer is.
And Windows' security is so good that it's Windows who's powering tens of billions of servers, smartphones, IoT, appliances, routers etc. throughout the world? Oh, wait, no... These are all running Linux.
And the uptime. Let's not forget the uptime with patch tuesday.
Windows does not strike me as the ecosystem we should strive to immitate.
And we all know how secure the average user's Windows computer is.
And Windows' security is so good that it's Windows who's powering tens of billions of servers, smartphones, IoT, appliances, routers etc. throughout the world? Oh, wait, no... These are all running Linux.
And the uptime. Let's not forget the uptime with patch tuesday.
Windows does not strike me as the ecosystem we should strive to immitate.
In what language is the Linux kernel written on?
https://www.cvedetails.com/product/47/Linux-Linux-Kernel.htm...
Those that have glass ceilings should not throw rocks.
https://www.cvedetails.com/product/47/Linux-Linux-Kernel.htm...
Those that have glass ceilings should not throw rocks.
> why we're still writing applications
> Have we not learned our lesson yet
Why are you speaking like this project is asking you to write code in C++? You are free to exclusively write Rust. Other people writing C++ has 0 impact on what you're writing or what lessons you've learned.
> Have we not learned our lesson yet
Why are you speaking like this project is asking you to write code in C++? You are free to exclusively write Rust. Other people writing C++ has 0 impact on what you're writing or what lessons you've learned.
If the eventual goal is to place the application in the hand of users, I think the question has merit.
Because rust is a cargo cult. We're nearing 10 years since 1.0 and there's still not a single serious, widely used, large software project to prove its viability. Maybe make one instead of trying to passive aggressively convince others to do it for you?
I didn’t mention rust, I don’t know Rust and if I were trying to start a similar project I might do so in .NET Core because of my familiarity with .NET. I’m asking because I don’t know if there is a reason it would not be viable, is the garbage collection too much of a hurdle to get decent performance while trying to interpret JavaScript? Is there too much overhead tracking claims on memory and doing the bounds checks? I’d assume the same checks eventually have to be written in C++ too?
I apologize - when people mention "memory safe" nowadays 95% of the time they're talking about Rust, I made an assumption.
Interpreting JavaScript at all it at all is a problem. Ladybird's LibJS compiles it to bytecode and interprets that (which is usually better than intereprting the AST). The bytecode interpreter is written in C++, and it's still pretty damn slow - websites take a long time to load, and LibJS is the main bottleneck.
The reality is, modern websites throws so much junk at your JS implementation, that you basically need to JIT-compile it in order to have any sort of reasonable performance. And with JIT all memory safety guarantees are thrown out of the window - it doesn't matter if you write your compiler in Rust, C++ or a .NET language - if there's an exploit it's disproportionately more likely to be in the output assembly than it is to be in your compiler.
Browsers nowadays make a best effort, and they have a stack of other mitigations in case the JIT leaks: https://chromium.googlesource.com/chromium/src/+/main/docs/d...
Interpreting JavaScript at all it at all is a problem. Ladybird's LibJS compiles it to bytecode and interprets that (which is usually better than intereprting the AST). The bytecode interpreter is written in C++, and it's still pretty damn slow - websites take a long time to load, and LibJS is the main bottleneck.
The reality is, modern websites throws so much junk at your JS implementation, that you basically need to JIT-compile it in order to have any sort of reasonable performance. And with JIT all memory safety guarantees are thrown out of the window - it doesn't matter if you write your compiler in Rust, C++ or a .NET language - if there's an exploit it's disproportionately more likely to be in the output assembly than it is to be in your compiler.
Browsers nowadays make a best effort, and they have a stack of other mitigations in case the JIT leaks: https://chromium.googlesource.com/chromium/src/+/main/docs/d...
This may be the biggest gap in my understanding. I didn’t realize that at some point the JavaScript is turned into instructions running directly on metal, I thought everything occurred within a synthetic/virtual environment.
> writing applications that will almost certainly execute or process hostile content in languages that don't maintain strict memory safe contract?
That point is 50% FUD. A language which "maintains strict memory safe contracts" but has an `unsafe` keyword; or has a "native code interface", or uses libraries implemented in a different language, doesn't really strictly maintain its guarantees. And on the other hand, a language in which you can, in principle, load and execute arbitrary code from a string you got from the user, can be hardened very well by statically-checkable constraints.
So, it's a matter of degrees rather than absolutes. If you then add considerations such as programming paradigm flexibility and performance, C++ is very much a valid choice even for the use case of a browser.
That point is 50% FUD. A language which "maintains strict memory safe contracts" but has an `unsafe` keyword; or has a "native code interface", or uses libraries implemented in a different language, doesn't really strictly maintain its guarantees. And on the other hand, a language in which you can, in principle, load and execute arbitrary code from a string you got from the user, can be hardened very well by statically-checkable constraints.
So, it's a matter of degrees rather than absolutes. If you then add considerations such as programming paradigm flexibility and performance, C++ is very much a valid choice even for the use case of a browser.
[deleted]
It's crap programmers that write buggy code, and they will write similarly buggy code in any language. It's not hard to write memory safe code, most people are not skilled enough to do it. I doubt they will be skilled enough to write good rust.
Where is the proof that Rust can achieve the productivity and design flexibility needed at browser scale?
I'm very happy that projects like this exist, and hope that they succeed in their mission.
With the current state of the web, filled with mostly spam content designed to generate ad revenue and to exploit the user, accessed from mainstream browsers produced by large corporations that are increasingly trying to do the same thing, web users are being squeezed from all sides. Using the web today is a hostile experience, and the only safe haven from all this nonsense is using community-supported alternative browsers, that are really stripped down versions of mainstream ones, and relying heavily on ad, cookie, JavaScript and other blockers, which may stop working at any point. This is a difficult task only tech savvy users can realistically do, while most other users have no choice.
A new, independent, browser alone will not solve this, but it's certainly a step in the right direction.
With the current state of the web, filled with mostly spam content designed to generate ad revenue and to exploit the user, accessed from mainstream browsers produced by large corporations that are increasingly trying to do the same thing, web users are being squeezed from all sides. Using the web today is a hostile experience, and the only safe haven from all this nonsense is using community-supported alternative browsers, that are really stripped down versions of mainstream ones, and relying heavily on ad, cookie, JavaScript and other blockers, which may stop working at any point. This is a difficult task only tech savvy users can realistically do, while most other users have no choice.
A new, independent, browser alone will not solve this, but it's certainly a step in the right direction.
> Using the web today is a hostile experience, and the only safe haven from all this nonsense is using community-supported alternative browsers, that are really stripped down versions of mainstream ones, and relying heavily on ad, cookie, JavaScript and other blockers, which may stop working at any point.
I think the actual root of the problem is that the people and organizations developing and running the sites do want to force the ads, analytics and other things upon you and you as a user basically have to hack around that. If the users actually took a stance with something a bit like https://en.wikipedia.org/wiki/GNU_LibreJS then the sad reality would be that you just couldn't use most sites altogether.
I think the actual root of the problem is that the people and organizations developing and running the sites do want to force the ads, analytics and other things upon you and you as a user basically have to hack around that. If the users actually took a stance with something a bit like https://en.wikipedia.org/wiki/GNU_LibreJS then the sad reality would be that you just couldn't use most sites altogether.
I found NoScript to be a good alternative. It disables JS by default but then you can reenable per page but also per domain. You only enable just what you need for the page to work and sometimes only temporarily.
I still need to enable things here and there but it's a fairly easy straightforward process.
Couple this with uBlock and firefox Container (where I am logged to google only for gmail in a specific container) and the web is pleasant again
I still need to enable things here and there but it's a fairly easy straightforward process.
Couple this with uBlock and firefox Container (where I am logged to google only for gmail in a specific container) and the web is pleasant again
uBlock Origin already supports Javascript blocking (both globally and per domain) if you enable advanced mode. Redundant extensions are just extra attack surface.
This is astonishing given that the project only started in Sept 2022! Andreas Kling, you are the man!
Ladybird has a good use case on embedded projects where there is a need
to use a well understood API for small gadgets acting as clients. I wish success.
> Ladybird now targets Linux and macOS. The SerenityOS target is dropped.
What does this mean, that Ladybird will no longer run on Serenity OS? And that is up to the Serenity peeps to make it run should they wish to do so?
What does this mean, that Ladybird will no longer run on Serenity OS? And that is up to the Serenity peeps to make it run should they wish to do so?
Yeah and I believe the reason given is because Ladybird wanted to use third party code and SerenityOS has a no third party code policy which made targeting Serenity kind of hard.
Serenity is just another Linux. So they target all Linux distributions instead of this specific one.
Still hoping for future Windows support to replace Firefox.
The founder usually lives to stream his work—very impressive skills.
Only bots around us
My disappointment for what this means for SerenityOS is pretty high.
Why build another browser, from scratch, in C++?
Why not? Some people are hacking on 30+ year old 8 bit systems... just for the fun of it.
From GitHub.
> Ladybird is a truly independent web browser, using a novel engine based on web standards.
So I assume they want to build a truly independent web browser instead of leaving the Browser market to Google, Apple, and Firefox (relies heavily on Google ad revenue.) and executives that run them who are primarily motivated by money.
> Ladybird is a truly independent web browser, using a novel engine based on web standards.
So I assume they want to build a truly independent web browser instead of leaving the Browser market to Google, Apple, and Firefox (relies heavily on Google ad revenue.) and executives that run them who are primarily motivated by money.
Because its fun, and because it might break the chromium monopoly we're currently living in, some day far in the future.
[deleted]
Why aren't you building one in another language if that is something you feel is missing?
Because they can
[deleted]
I'm already speculating that sooner or later in the future this project will end up pivoting to chromium as the underlying engine.
I can think of two reasons for this
- money is involved and someone buys them out / influences the direction of the project
- the reality of the task ahead sets in the and the dev team gives up on custom engine development
For those of you coming back to this comment from the future, yep "told you so". ;-)
I can think of two reasons for this
- money is involved and someone buys them out / influences the direction of the project
- the reality of the task ahead sets in the and the dev team gives up on custom engine development
For those of you coming back to this comment from the future, yep "told you so". ;-)
Do you think you have a better handle on the "reality of the task" than Kling, who already worked at Apple on WebKit and subsequently got Ladybird to where it is now?
I doubt it. Your prediction might be more appropriate for a project that's in its first week of development, not having been developed for several years and already overcome many difficult hurdles. And if they switch to chromium, there is literally nothing interesting about this project. The fact that it's a novel engine is their only differentiating feature.
The age of the project or the development status of the project does not matter, what matters is the user base.
If you build anything that accumulates users, business interests will be aroused at some point. Business people don't give a shit about the technology itself unless of course the technology itself really is a USP and can be converted into €$. But most people (end users) don't care much about the underlying technology in the browser and whether it's open source or not, chromium or not. Only technologists care.
If you build anything that accumulates users, business interests will be aroused at some point. Business people don't give a shit about the technology itself unless of course the technology itself really is a USP and can be converted into €$. But most people (end users) don't care much about the underlying technology in the browser and whether it's open source or not, chromium or not. Only technologists care.
> The age of the project or the development status of the project does not matter
If you have any evidence to support this, you could become quite well-known for disproving the Lindy effect's applicability to software projects.
If you have any evidence to support this, you could become quite well-known for disproving the Lindy effect's applicability to software projects.
It may be hard for you to believe but there are projects not run by "business people".
You really think Google has people running around with suitcases full of money, tempting devs to abandon their own browser engines in favour of chromium?
As long as they don't get rid of the Qt dependency the project is a bit pointless. If you are using Qt anyways Qt Webview offers already a superior way to render HTML than Ladybird.
Qt webview is just Chromium in a trenchcoat. The point is to create a new browser engine, not a new Chromium UI (and hopefully much less bloated than Chromium).
GUI libraries and a browser engines are vastly different things.
Think of Ladybird as Blink, Webkit or Gecko.
I think the point is the opposite; they have decided to build a new "web stack" from scratch, not just build a new "browser" (or invent a new GUI framework). Hopefully the web engine is not deeply tied to Qt, but you need something in order to draw an interactive window. The article mentions that they will also use existing libraries for things like font rendering. Seems like a pragmatic decision to me.
No, because with the current architecture they can more easily migrate away to different GUI libraries.
On mac there's a native appkit backend, no qt needed as far as i can see.
I hear so much about Ladybird on HN, that I’m equally excited and cynical.
What is the value proposition? Is it to be another general purpose browser, so there’s more competition with Chrome / WebKit? Or to be a niche browser, that could be an alternative to Electron?
How close is it to achieving that?
What is the value proposition? Is it to be another general purpose browser, so there’s more competition with Chrome / WebKit? Or to be a niche browser, that could be an alternative to Electron?
How close is it to achieving that?
The question for a value proposition seems to be out of place to me.
It's not a business. Some people develop a browser for their own joy and now they decided to target Linux and use 3rd party libraries.
It's not a business. Some people develop a browser for their own joy and now they decided to target Linux and use 3rd party libraries.
So the main value is to the people who get pleasure from working on it? I don’t mean it in a pejorative way, I love the idea.
I've heard innumerable times that it's infeasible to write a modern web browser from scratch without a trillion dollars of funding or something absurd like that. So it's exciting to see a small guy / group take a serious swing at it.
As I see it, Ladybird's value is showing that its still possible to write a modern browser engine without the resources of a major tech company like Apple or Google.
In the future it might be a real competitor to Chrome & Safari, but we're several years from that happening, if at all.
In the future it might be a real competitor to Chrome & Safari, but we're several years from that happening, if at all.
Having looked at the source code… it’s not close. Not even 1/20 of the way there IMO.
But it might not need to be. It’s nice just having a second system. I don’t know to what extent Ladybird can replace Chrome, but the issues that come with a monoculture are known. There’s probably at least some hope that Ladybird could take off once it reaches a critical mass.
But it might not need to be. It’s nice just having a second system. I don’t know to what extent Ladybird can replace Chrome, but the issues that come with a monoculture are known. There’s probably at least some hope that Ladybird could take off once it reaches a critical mass.
So it’s a fun project where people are learning a lot by working on it as a hobby project. But I shouldn’t expect it to threaten Firefox, let alone Chrome, any time soon, although that’s the dream. Is that a fair summary?
To play devils advocate, Firefox breaks the monoculture, and arguably (Mobile) Safari too. If neither of these is big enough, will Ladybird be? I can’t imagine it getting bigger than them.
> Firefox breaks the monoculture
Not really as long as it is funded by Google.
Not really as long as it is funded by Google.
But it’s a completely separate codebase right, and that’s the monoculture we’re aiming to prevent here.
If it’s not about tech but rather about funding, then should we be concerned of the monoculture of American browser vendors, or English speaking browser vendors? I don’t think we need to be, but I also think the tech side is the important place to prevent a monoculture for the open development of web technologies.
If it’s not about tech but rather about funding, then should we be concerned of the monoculture of American browser vendors, or English speaking browser vendors? I don’t think we need to be, but I also think the tech side is the important place to prevent a monoculture for the open development of web technologies.
> But it’s a completely separate codebase right
Not entirely separate anymore as both make use of shared external libraries.
Not entirely separate anymore as both make use of shared external libraries.
It will never reach critical mass.
You don't know that. After all, Chrome comes from Webkit, which comes from Khtml, which comes from a huuuge one-person rewrite of basically a whole browser engine (https://en.wikipedia.org/wiki/KHTML#Re-write_and_improvement)
It might not, but so what? Don't we deserve options?
Ladybird is an experimental engineering project; consider it "basic engineering" (a la basic research). Thinking in terms of "value proposition" is very limiting. Its goal is to develop an independent web stack (not a "hobby project" at all); its intent, one of several really, is to peek into and implement the internals of the modern web stack.
By doing so openly and incrementally without attachments to deadlines or an employer with specific priorities, the dev can take the time to identify inefficiencies, pain points, subtleties across the stack etc. which are then recorded in the development of the browser.
Thus, the project is not aimed to "achieve" something at some point in time; its "value proposition", if you must use this annoying term, is the development process itself.
By doing so openly and incrementally without attachments to deadlines or an employer with specific priorities, the dev can take the time to identify inefficiencies, pain points, subtleties across the stack etc. which are then recorded in the development of the browser.
Thus, the project is not aimed to "achieve" something at some point in time; its "value proposition", if you must use this annoying term, is the development process itself.
It's a fun project, but there's no practical value proposition besides showing that it can be done.
People are cheering on it because they love the author and want a new web browser written from scratch, but practically speaking it is a web browser that is 1) written in a memory unsafe language, 2) doesn't really have any sandboxing, and 3) is highly incomplete.
People are cheering on it because they love the author and want a new web browser written from scratch, but practically speaking it is a web browser that is 1) written in a memory unsafe language, 2) doesn't really have any sandboxing, and 3) is highly incomplete.
I think I just read in another comment that it uses per tab process isolation. Unless that's not what you mean by sandboxing?
By sandboxing I mean running various subcomponents of the web browser each in their own process, maximally reducing their priviledges and attack surface (through things like seccomp, user namespaces, strict resource limits, clearing and disabling capabilities, minimizing what code is loaded, making the address space immutable, etc.) and maybe even virtualizing some parts (e.g. Firefox started running some components in a WebAssembly sandbox).
There is this document here:
https://raw.githubusercontent.com/LadybirdBrowser/ladybird/d...
so there are some plans for sandboxing so that's good, but if I'm reading the code correctly (please correct me if I'm wrong) then no actual sandboxing is yet implemented on non-SerenityOS systems (e.g. there are some "pledge" calls that I can find, but it looks like it'll only work on SerenityOS?), and, if I'm being honest, this is nowhere near aggressive enough for a web browser, especially one written from scratch. If the goal was "produce the most secure web browser in the world" there's much more you could do with its architecture that even likes of Chrome won't (because of legacy considerations, and because they care a lot about how fast it runs).
But, of course, practically speaking as long as it has no market share (so no one will realistically target it) then even minimal sandboxing should be fine, and as long as the project itself doesn't pretend that it's something it is not then all is good.
There is this document here:
https://raw.githubusercontent.com/LadybirdBrowser/ladybird/d...
so there are some plans for sandboxing so that's good, but if I'm reading the code correctly (please correct me if I'm wrong) then no actual sandboxing is yet implemented on non-SerenityOS systems (e.g. there are some "pledge" calls that I can find, but it looks like it'll only work on SerenityOS?), and, if I'm being honest, this is nowhere near aggressive enough for a web browser, especially one written from scratch. If the goal was "produce the most secure web browser in the world" there's much more you could do with its architecture that even likes of Chrome won't (because of legacy considerations, and because they care a lot about how fast it runs).
But, of course, practically speaking as long as it has no market share (so no one will realistically target it) then even minimal sandboxing should be fine, and as long as the project itself doesn't pretend that it's something it is not then all is good.
I feel the same way. Excited to see another attempt. But it's a c++ engine so not something I would want to expose to the internet really.
Probably there's very little point to this other than learning how to build a browser right now.
I don't see this catching up any time soon to a point where you could use this and not deal with a very broken browsing experience. So this will likely stay a bit of a niche thing for quite some time. But I'm happy for people to prove me wrong.
Easy to forget that Webkit started out as a fork of Khtml when Apple embraced it for Safari. Later Google forked it off as Chrome. So, it has been done before. But it's a lot of work.
I don't see this catching up any time soon to a point where you could use this and not deal with a very broken browsing experience. So this will likely stay a bit of a niche thing for quite some time. But I'm happy for people to prove me wrong.
Easy to forget that Webkit started out as a fork of Khtml when Apple embraced it for Safari. Later Google forked it off as Chrome. So, it has been done before. But it's a lot of work.
It sets my expectations. Sometimes you hear a lot about a project because it's a vaporware scam, and I'm reassured that's not happening here. I should expect to see lots of excited people posting about it because they enjoy working on it, and it's delivering on that value even without much production usage.