Antitrust action could force Apple to allow real third party browsers on iOS, at which point Chromium could easily take over. We're stuck in a situation where we have to choose between two bad...
Antitrust action could force Apple to allow real third party browsers on iOS, at which point Chromium could easily take over.
We're stuck in a situation where we have to choose between two bad things: Allowing Apple to wholly dictate browser technology on a major platform, or allowing Google to functionally dictate browser technology on every platform.
There is the third option of breaking Google up but I seriously doubt there is enough political willpower to make that happen.
When this sort of thing is discussed in terms of the politics of tech companies and standards committees, it sounds like a lot is at stake. But there's a more practical way to look at it: how...
When this sort of thing is discussed in terms of the politics of tech companies and standards committees, it sounds like a lot is at stake. But there's a more practical way to look at it: how would it affect web developers day to day? Regardless of how the politics plays out, very little would change, I suspect.
After many years of evolution, today's web standards already let you do just about anything you would normally want to do with a website. If web standards completely stagnated, I don't think most web developers would notice. The things being standardized now are pretty minor. You could stop reading browser release notes without missing much.
This is unlike the early days when major things were broken, resulting in complicated and painful workarounds, and IE6 was really holding things back.
I actually do use Chrome on iOS, and yes, it's WebKit underneath, but there's little reason to care. The underlying engine hardly seems to matter at all.
What would I like to see change in browsers? I dabble in Arduino so I'd like to see access to serial devices and USB standardized. Browser-based development is becoming more common (consider GitHub Codespaces) and it would be nice to be able to flash and debug firmware from any desktop browser.
But this is a very niche concern and most users and developers don't have any reason to care about it. Also, Chrome proposed Web Serial and Web USB standards and Firefox seems to be against the whole concept, so it's hard to argue that the current web standards process encourages innovation in this niche.
I am a software engineer and I care about it. One company dictating the future of the web is a problem, especially when that company's revenue stream is almost entirely dependent on highly...
I am a software engineer and I care about it. One company dictating the future of the web is a problem, especially when that company's revenue stream is almost entirely dependent on highly invasive tracking and advertising. Google has been slowly inching towards making ad and tracker blockers less effective in Chrome, and they have actively resisted changes to web standards that would improve user privacy.
Simply put, I do not trust Google, at all. And I find it disconcerting that some are willing to place so much blind faith in them. Google is not your friend.
The thing that worries me the most about giving Google the keys to the internet is simply that it means that platforms that google does not bless essentially get fucked unless they've got a huge...
The thing that worries me the most about giving Google the keys to the internet is simply that it means that platforms that google does not bless essentially get fucked unless they've got a huge corporation willing to take the effort to make it work on their system (much like Microsoft did with Edge).
One project that I've been following for a very long time is Haiku, which for all intents and purposes is the last major noncommercial non-UNIX operating system. And of all the individual sections that make up an operating system, the biggest, most important one since I started following their development was their web browser, WebPositive. It took a very long time for WebPositive to become stable enough to be considered useful, and it still has many problems because there's simply not enough people to work on it. What happens when Apple abandons WebKit? Without a working browser, the entire operating system is essentially useless to modern users.
I know you care, but these are high-level political concerns. You care because you care about tech politics. But day to day, is there anything you need that web standards don't have? From privacy...
I know you care, but these are high-level political concerns. You care because you care about tech politics.
But day to day, is there anything you need that web standards don't have?
From privacy point of view, the problem is that web standards, being pretty general purpose, allow too much freedom for people to build tracking tools. They are, in some ways, too powerful.
(Also, browser extensions aren't part of web standards at all. Each browser has its own extension API. Firefox decided to copy Chrome to some extent to make portability easier, though.)
I thought that the primary reason was security -- the old plugin mechanism gave plugins far more control over the changes that they could make to the browser and it was harder to sandbox them.
Firefox decided to copy Chrome to some extent to make portability easier, though.
I thought that the primary reason was security -- the old plugin mechanism gave plugins far more control over the changes that they could make to the browser and it was harder to sandbox them.
(Former Firefox developer here): The old addon scheme pretty much made it impossible for us to deliver a multiprocess browser, with all the benefits that entails.
(Former Firefox developer here): The old addon scheme pretty much made it impossible for us to deliver a multiprocess browser, with all the benefits that entails.
Keep in mind that the original addon system wasn't really an API. There was no abstraction between the engine and the addons; the latter were effectively merged into Firefox itself. This...
Keep in mind that the original addon system wasn't really an API. There was no abstraction between the engine and the addons; the latter were effectively merged into Firefox itself. This eventually made it really hard to make changes, because any time a Firefox developer tried to change existing code, it was very likely to break some addon.
One of the biggest issues with communicating between the parent browser process and the child processes is that you want it all to be asynchronous. At the time, a lot of very critical internal Gecko interfaces were synchronous.
We needed to change those critical interfaces within Gecko to support asynchronicity. But as I've already mentioned, all addons already used the old synchronous interfaces.
There were some experiments with offering a migration path: some very smart people created this concept called a cross-process object wrapper (CPOW, pronounced ka-pow), that would emulate the synchronous, single-process model, while issuing asynchronous cross-process requests under the hood. In fact, CPOWs were used within the core of Firefox to keep its legacy parts working while we overhauled Gecko with new asynchronous stuff.
There was one fly in the ointment, however: CPOWs (perhaps unsurprisingly) performed like shit! We realized that we had to eliminate all the uses of CPOWs or else we would never be able to deliver a competitive multiprocess browser.
Once we realized that CPOWs had to go, we knew that we couldn't make the needed changes to Gecko's innards without breaking any addons. Mozilla made the decision that, if all addons had to be broken anyway, then it was a good time to create a real addons API that keeps the browser internals abstracted from the addons. Since Chromium extensions already existed, Mozilla created a superset of their API called WebExtensions. The rest is history.
Yes, that sounds right to me. But without making any claim about what's primary, portability for web extensions is a good reason to copy Chrome (to some extent) instead of designing a new API from...
Yes, that sounds right to me. But without making any claim about what's primary, portability for web extensions is a good reason to copy Chrome (to some extent) instead of designing a new API from scratch.
It's a hypothetical argument because there's no reason to believe that Apple will switch.
Antitrust action could force Apple to allow real third party browsers on iOS, at which point Chromium could easily take over.
We're stuck in a situation where we have to choose between two bad things: Allowing Apple to wholly dictate browser technology on a major platform, or allowing Google to functionally dictate browser technology on every platform.
There is the third option of breaking Google up but I seriously doubt there is enough political willpower to make that happen.
When this sort of thing is discussed in terms of the politics of tech companies and standards committees, it sounds like a lot is at stake. But there's a more practical way to look at it: how would it affect web developers day to day? Regardless of how the politics plays out, very little would change, I suspect.
After many years of evolution, today's web standards already let you do just about anything you would normally want to do with a website. If web standards completely stagnated, I don't think most web developers would notice. The things being standardized now are pretty minor. You could stop reading browser release notes without missing much.
This is unlike the early days when major things were broken, resulting in complicated and painful workarounds, and IE6 was really holding things back.
I actually do use Chrome on iOS, and yes, it's WebKit underneath, but there's little reason to care. The underlying engine hardly seems to matter at all.
What would I like to see change in browsers? I dabble in Arduino so I'd like to see access to serial devices and USB standardized. Browser-based development is becoming more common (consider GitHub Codespaces) and it would be nice to be able to flash and debug firmware from any desktop browser.
But this is a very niche concern and most users and developers don't have any reason to care about it. Also, Chrome proposed Web Serial and Web USB standards and Firefox seems to be against the whole concept, so it's hard to argue that the current web standards process encourages innovation in this niche.
I am a software engineer and I care about it. One company dictating the future of the web is a problem, especially when that company's revenue stream is almost entirely dependent on highly invasive tracking and advertising. Google has been slowly inching towards making ad and tracker blockers less effective in Chrome, and they have actively resisted changes to web standards that would improve user privacy.
Simply put, I do not trust Google, at all. And I find it disconcerting that some are willing to place so much blind faith in them. Google is not your friend.
The thing that worries me the most about giving Google the keys to the internet is simply that it means that platforms that google does not bless essentially get fucked unless they've got a huge corporation willing to take the effort to make it work on their system (much like Microsoft did with Edge).
One project that I've been following for a very long time is Haiku, which for all intents and purposes is the last major noncommercial non-UNIX operating system. And of all the individual sections that make up an operating system, the biggest, most important one since I started following their development was their web browser, WebPositive. It took a very long time for WebPositive to become stable enough to be considered useful, and it still has many problems because there's simply not enough people to work on it. What happens when Apple abandons WebKit? Without a working browser, the entire operating system is essentially useless to modern users.
I know you care, but these are high-level political concerns. You care because you care about tech politics.
But day to day, is there anything you need that web standards don't have?
From privacy point of view, the problem is that web standards, being pretty general purpose, allow too much freedom for people to build tracking tools. They are, in some ways, too powerful.
(Also, browser extensions aren't part of web standards at all. Each browser has its own extension API. Firefox decided to copy Chrome to some extent to make portability easier, though.)
I thought that the primary reason was security -- the old plugin mechanism gave plugins far more control over the changes that they could make to the browser and it was harder to sandbox them.
(Former Firefox developer here): The old addon scheme pretty much made it impossible for us to deliver a multiprocess browser, with all the benefits that entails.
That's interesting. What about it made that so difficult?
Keep in mind that the original addon system wasn't really an API. There was no abstraction between the engine and the addons; the latter were effectively merged into Firefox itself. This eventually made it really hard to make changes, because any time a Firefox developer tried to change existing code, it was very likely to break some addon.
One of the biggest issues with communicating between the parent browser process and the child processes is that you want it all to be asynchronous. At the time, a lot of very critical internal Gecko interfaces were synchronous.
We needed to change those critical interfaces within Gecko to support asynchronicity. But as I've already mentioned, all addons already used the old synchronous interfaces.
There were some experiments with offering a migration path: some very smart people created this concept called a cross-process object wrapper (CPOW, pronounced ka-pow), that would emulate the synchronous, single-process model, while issuing asynchronous cross-process requests under the hood. In fact, CPOWs were used within the core of Firefox to keep its legacy parts working while we overhauled Gecko with new asynchronous stuff.
There was one fly in the ointment, however: CPOWs (perhaps unsurprisingly) performed like shit! We realized that we had to eliminate all the uses of CPOWs or else we would never be able to deliver a competitive multiprocess browser.
Once we realized that CPOWs had to go, we knew that we couldn't make the needed changes to Gecko's innards without breaking any addons. Mozilla made the decision that, if all addons had to be broken anyway, then it was a good time to create a real addons API that keeps the browser internals abstracted from the addons. Since Chromium extensions already existed, Mozilla created a superset of their API called WebExtensions. The rest is history.
Yes, that sounds right to me. But without making any claim about what's primary, portability for web extensions is a good reason to copy Chrome (to some extent) instead of designing a new API from scratch.