DEV Community: Vivaldi Browser

Vivaldi presents: “Browser choices. A tale of two Gatekeepers.”

Jane — Wed, 14 Feb 2024 09:01:47 +0000

At Vivaldi, we have long advocated for people to be able to select their favorite browser. We picture a world where upon setting up a new device, you are presented with the option to choose your browser. Whether your device is an iPhone or an iPad, an Android device, or a Windows PC, your journey should start by selecting the app you use to go online. That choice should be made in an informed manner.

Doesn’t that sound like a dream?

Well soon, thanks to the EU Digital Market Act (DMA), we will be one step closer to this reality. This new regulation aimed to reign in the powers of Big Tech mandates among other things that they loosen their grasp on the web. One part of this is the requirement to implement Browser Choice Screens.

The new requirement applies to several big platform owners, such as Apple, Google, and Microsoft, dubbed Gatekeepers in the DMA.

Needless to say, we are pretty pleased with this.

Browser Choice Screens have been tried before by Microsoft, following a different EU ruling. At the time, we saw that it was absolutely possible to implement them in flawed ways. And there is a risk that they will be.

Indeed, gatekeepers, as platform owners, exert natural control over the software and apps available on their platforms. The ability to gather more data about their users through their own browser provides them with an incentive to impose that browser on their users. This incentive leads them to use their privileged position to stifle competition, favor their own products and apps, and dissuade them from installing competing software. With that in mind, they might decide not to care about implementing an effective choice screen.

To make matters worse, without choice, the platform owners’ apps do not need to compete on their merits. They may be ill-suited to their user’s needs and be of poor quality. In an environment built on standards such as the web, this can lower the quality of the web as a whole.

However, while gatekeepers can indeed choose to be a problem and act purely in their self-interest, they can also choose to do the right thing. We do believe that doing the right thing is going to be good for them in the long run as they will have a more sustainable relationship with their user base. To provide some guidance over what the right thing is, we present the following tale.

A Tale of Two Gatekeepers

Let us look at two archetypal companies to demonstrate how bad (or how good) a Browser Choice Screen can be. They are both large corporations, controlling popular platforms, and are the gatekeepers for this exercise.

IronGrip Inc. sees the DMA purely as a nuisance. They spend countless hours in frivolous meetings arguing over the best way to comply with the new regulation. They still want to make sure their users stick with their app.

As they explored the problem, someone proposed to weaponize the newly mandated Choice Screen. The idea resonated around the organization. Eventually, the decision was made, “These fools at the EU will know not to mess with us again! We will make this the most painful experience imaginable for anyone who dares to engage with it!”, they gleefully wrote in the memo from that meeting. “They will regret not having chosen the easy path out and stuck with us. And they will be convinced that the EU hates users,” they concluded.

Meanwhile, at the headquarters of FreeChoice Ltd, the news about the Choice Screen is met with a more measured response. They are not thrilled to admit it, but they agree with the EU regulators. FreeChoice Ltd had clearly gone astray in the past in trying to conquer the market. In doing so, they have built insurmountable barriers for all competitors and have alienated their own users. Clearly, the Browser Choice Screen is an opportunity to make things right.

And so, the two rivals set out to work on their Choice Screen. One reluctantly with malicious intent, and the other with a cautiously optimistic approach.

Now, let us compare the Choice Screens the two companies implemented.

IronGrip vs FreeChoice

The right time to show the Choice Screen

IronGrip: When the user clicks a browser icon.

FreeChoice: As early as possible during device/OS installation or update.

IronGrip Inc. through their market research discovers that once the user has started a browser, they are in the mindset of using that browser and surfing the web. They might be happy setting up that browser, but anything else is inconvenient. This will be the perfect time to show their Choice Screen.

Meanwhile, FreeChoice Ltd wants their user to pick a browser when they are in the mindset of setting things up. The best time for this is when first setting up or updating their device. They discover that users tend to hurry through the last step of the setup process as they lose interest in it. So they make sure to show the browser screen as early as possible, right after having asked the user for essential settings.

User influence

IronGrip: Makes sure the user has seen the gatekeeper’s browser icon or brand colors, before the choice screen.

FreeChoice: Avoid displaying even brand colors before browser choice occurs.

IronGrip makes sure that the user has seen what the icon of their browser looks like by the time the Choice Screen shows up. They will probably pick that one to get on with their day.

FreeChoice realizes that any hint of what might be the default for their platform will make the user subconsciously trust that choice more. Unfortunately, their brand colors show up a lot through the early stage of their setup process. They have to show their brand logo when starting the device — that is unavoidable. But they make sure to make the setup process look as neutral as possible up until the browser choice has happened

Impatience is the enemy of choice

IronGrip: Provide a way to skip the Choice Screen. No guarantee it will be shown again.

FreeChoice: Do not provide a way to skip the Shoice Screen.

IronGrip has already made their Choice Screen show up at a maximally inconvenient time and made sure users were likely to select them anyway. But if a user is hesitating, they don’t want to force them to take the time to think. They add a handy option to come back to the Choice Screen later. Then they can just ask again sometime soon. Or maybe not so soon. Or maybe ever? At any rate, if they ask again, it will probably be while the user is watching a video.

FreeChoice understands that the longer the user waits to make the choice, the more likely they are to stick with what they have. So, they make sure that they have to choose the first time.

Expose users to more choice

IronGrip: Keeps randomization limited and promotes some items over others.

FreeChoice: Show a random selection with plenty of choices.

IronGrip certainly has made it likely that users will recognize and choose their browser, but for this to have the best chance of working, they must make sure that their browser appears prominently on the Choice Screen. So, they come up with an excuse. The Choice Screen is supposed to be randomized, but, they argue, the choices the user is most likely to be familiar with should be closer to the top. That makes the user’s life easier. Of course, they then place themselves among the top contenders and randomize those separately from the rest. It doesn’t matter where they end up on that initial screen, so long as they are there. This considerably increases the odds that the user will choose IronGripBrowser

FreeChoice has the insight that with more browser diversity and competition in the market, there will be a lot of incentives for the web to develop in new and exciting directions and give them an incentive to improve FreeChoiceBrowser. Therefore, they make sure to calibrate their design to be readable while also showing as many options as possible on the screen. To fully give everyone an equal chance, they make sure that all the options have an equal chance of being shown.

Sometimes, the FreeChoiceBrowser is at the bottom of the list and users have to scroll all the way to find it, but that’s ok. They get to see what’s out there.

Help make a meaningful choice

IronGrip: Show just a name and icon. No description. Any browser the user doesn’t know will be a mystery.

FreeChoice: Add some descriptions. The most important information is always visible.

IronGrip certainly has made it likely that users will choose their browser, but if they are really in the mindset of trying something new, IronGrip doesn’t want to make it easy for them. After all, that might just help create one more serious competitor they have to deal with. So, they make sure to provide only minimal information. Just an icon and a name should be enough.

FreeChoice also understands that people are likely to choose something that looks familiar, but at least they want people to know what they are getting into. So, they request each vendor to provide a few lines to describe their browser. This lets users make a choice that aligns with their values and needs.

Make sure all choices are useful

IronGrip: Include some underwhelming or hard-to-use options and exclude some obvious competitors.

FreeChoice: Use a submission process. Push for all relevant browsers to be included. Keep to one browser per competitor.

IronGrip has already made its Choice Screen as confusing as possible. But if users decide to pick a less well-known option despite everything, it is best to make sure they get an underwhelming experience or even a bad one. Or one that’s still IronGrip in disguise. To achieve that, they add into the mix some browsers that are just copies of existing ones with different branding, or extremely minimal changes. Some of those copies are clones of IronGripBrowser itself. Some of them are abandoned projects with no updates. They also add a few experimental or specialized choices that are not designed for regular web browsing, or only intended for use in specialized circumstances or on very specific websites, and will not work well for anyone else. Finally, they also avoid adding some legitimate contenders, making the experience maximally frustrating for everyone.

FreeChoice has already made sure to have a clear description for every browser, so at least the experimental ones can be clear about the challenges involved. Even so, they make sure that only browsers that wish to be part of the selection are there and encourage featureful browsers to apply. They also ensure that each company has no more than one browser included and that the included browsers are updated regularly.

Ensure the chosen browser is easy to start

IronGrip: The chosen default browser is hidden away while the gatekeeper’s browser is easy to access.

FreeChoice: The chosen browser is easy to find.

Even if the user has managed to pick something they love from the convoluted IronGrip Choice Screen is not the end of their frustrations. First of all, the IronGripBrowser is still shown on the main screen and the one they set up is nowhere to be seen. It takes a while to discover that to launch it, they have to wade through the list of installed apps.

FreeChoice respects what the user has chosen. If it was not selected, FreeChoiceBrowser is nowhere to be seen and there is no obvious way to start it.

Ensure the chosen browser is easily used

IronGrip: Apps distributed by IronGrip always use the IronGripBrowser.

FreeChoice: The chosen browser is always started for browsing.

In addition to making the chosen browser hard to find, most of IronGrip’s own apps and services just ignore the default and start the IronGripBrowser when navigating. With that, IronGrip has made sure that the user would quickly forget what they have chosen and stick with the IronGripBrowser instead.

FreeChoice makes sure that opening any link anywhere results in the user’s chosen browser to be started.

Let people change their mind

IronGrip: There is no easy way to make a different choice.

FreeChoice: The Choice Screen can be restarted on demand.

IronGrip has put a lot of effort into having their browser ending on top, they’re not about to let someone change their mind and pick a different one later on. They make sure that if the user tries to change the default browser, they have to navigate a maze of settings and change every small detail that affects which browser gets started when in multiple unrelated places. In fact, it might be easier to just buy a new device if you want to switch the default browser.

FreeChoice has a single prominent option leading back to the Choice Screen. They also expose more advanced settings, for users who understand what they are doing, but in most cases, making a new selection via the Choice Screen does the right thing.

Handling of newly installed browsers

IronGrip: A newly installed browser cannot just become the new default.

FreeChoice: Provides an easy way for any browser to become the default.

IronGrip has made changing the default browser almost impossible, the same applies to any browser that the user manually installs.

FreeChoice makes a smaller version of the Choice Screen to deal with browsers installed manually. Whenever an installed browser requests it, this screen shows up, asking users if they wish to change the default to this new browser or keep the existing one. They rely on existing malware removal techniques to deal with any illegitimate software abusing this feature.

Don’t force people to change their minds

IronGrip: The platform regularly discourages using the chosen default and even attempts to hijack it.

FreeChoice: IronGrip is really pushing it now. We don’t do that.

If someone didn’t choose IronGripBrowser, IronGrip likes to remind them on every occasion that they have made the wrong choice. They will express concern about how secure the chosen alternative is and ask if the user really didn’t mean to use the secure default they provide. Not only that, but they are avidly using dark patterns, attempting to trick people into choosing IronGripBrowser whenever they ask. By now, it has become clear that their Choice Screen was never meant to provide an actual choice.

FreeChoice doesn’t do any of that and is putting out a statement complaining about IronGrip.

Bonus section: Allow procuring browsers from anywhere

IronGrip: The platform limits which browsers can be installed.

FreeChoice: The platform allows installing browsers from any source.

IronGrip only allows people to obtain new software through their store of which they have full control. In this store, they can freely decide whether a given browser is allowed or not. If they opt to not have a given browser there, then it’s tough luck for the people who want to use it. Even if a browser is present, they can make it arbitrarily hard to find, sometimes making competitors show up when looking for a specific browser.

FreeChoice happily lets anyone install software from any source they choose. They have some malware protection in place to weed out genuinely bad actors, but they use it responsibly.

What of the real Gatekeepers

With the Browser Choice Screen requirements soon to be effective in full force, we are starting to get to know more about how the actual gatekeepers are designing their Choice Screens.

Certainly, we hope to see everyone strive to be like FreeChoice. Most people stick with the default when selected so they must be able to make a meaningful informed choice from the start. All points presented here are crucial to achieve this result and skipping any of them would seriously erode the effectiveness of the Choice Screen. We believe that gatekeepers can get out of the mindset that they must coerce their users into using a given browser and truly embrace choice, allowing competition to flourish in the browser space once more to the benefit of everyone.

If browsers are offered and selected based on their merits, then the Choice Screen will truly have fulfilled its purpose.

Do any of the gatekeepers have a Browser Choice Screen that makes the cut? We will take a closer look when they get released in a few weeks. Meanwhile, if you encounter a Browser Choice Screen, you can use this handy table to remind yourself of what to look for.

IronGrip		FreeChoice
Shown when the user clicks a browser icon.	👎	Shown as early as possible during device/OS installation or update.	👍
Make sure the user has seen the gatekeeper’s browser icon or brand colors, before the Choice screen.	👎	Avoid displaying even brand colors before browser Choice occurs.	👍
Provide a way to skip the Choice Screen. No guarantee it will be shown again.	👎	Do not provide a way to skip the Choice Screen.	👍
Keeps randomization limited and promotes some items over others.	👎	Show a random selection with plenty of choices.	👍
Show just a name and icon. No description. Any browser the user doesn’t know will be a mystery.	👎	Add some descriptions. The most important information is always visible.	👍
Include some underwhelming or hard-to-use options and exclude some obvious competitors.	👎	Use a submission process. Push for all relevant browsers to be included. Keep to one browser per competitor.	👍
The chosen default browser is hidden away while the gatekeeper’s browser is easy to access.	👎	The chosen browser is easy to find.	👍
Apps distributed by IronGrip always use the IronGripBrowser	👎	The chosen browser is always started for browsing.	👍
There is no easy way to make a different choice.	👎	The Choice Screen can be restarted on demand.	👍
A newly installed browser cannot just become the new default.	👎	Provides an easy way for any browser to become the default.	👍
The platform regularly discourages using the chosen default and even attempts to hijack it.	👎	IronGrip is really pushing it now. We don’t do that.	👍
The platform limits which browsers can be installed.	👎	The platform allows installing browsers from any source.	👍

Why Vivaldi won’t follow the current AI trend?

Jane — Mon, 05 Feb 2024 13:22:48 +0000

ChatGPT came into the public eye a year and a few months ago. Ever since then, there has been an increasing trend in many sectors to try to put it to use to replace some of the things that people do, or to provide a new way to help people find answers to whatever they may wonder.

The world of web browsers has not been spared by this trend with multiple examples of web browsers integrating LLM (Large Language Model) functionality in one way or another.

Yet, even as they do so in the name of building the future, none of them seem to consider the glaring flaw in these features: The LLMs themselves are simply not suited as conversation partners, as summarization engines, and are only able to help with generating language with a significant risk of plagiarism.

In order to understand why all of those are fundamental problems, and not problems that are eventually going to be solved, we should examine the very nature of LLMs.

We do not want to get into a very long-winded explanation of the intricacies of LLMs here. Instead, we will settle for a shorter explanation. It might leave out some caveats, but everything said here does apply to the big popular generic LLMs out there.

Many experts in the field have already done an excellent job of this. Here is an interesting read: “You are not a parrot. And a chatbot is not a human“.

What are LLMs?

LLMs are just a model of what a written language looks like. That is a mathematical description of what it looks like. It is built by examining a large variety of sources and focuses on describing which word is the most likely to follow a large set of other words. There is a bit of randomness added to the system to make it feel more interesting and then the output is filtered by a second model which determines how “nice” that output sounds. In several cases, this second stage model was made by having many (underpaid) people to look at what comes out of the first stage and choose whether they liked it or not and whether it sounded plausible.

This has two fundamental issues:

Copyright and privacy violations

In order to have a good idea of which word is likely to follow a set of words, it is necessary to look at a lot of text. The more text, the better as every bit of text allows to tweak the model to be a more accurate representation of a language. Also, much of the text fed into it needs to be relatively recent to reflect the current usage of the language.

This means there is a tremendous incentive to consume text from all recent sources available, from social media to articles and books. Unfortunately, such text being baked into the model means that it is possible to cause it to output the same text verbatim. This happens if, for a given input sequence, there is no better choice than regurgitating this original text. As a result, these models will in some case just repeat copyrighted material, leading to plagiarism.

Similarly, the mass of text coming from social media and other user-provided sources may well contain sensitive, private information that can similarly be regurgitated. Some clever people have found ways to trigger this sort of behavior, and it is unlikely that it is possible to protect fully against it. Being clearly aware of the risk posed by exposing private information, we have never been thrilled by the idea of it possibly getting baked into those models.

Plausible-sounding lies

Since the text that an LLM is built out of originates in large part from the Internet in general, that means that a lot of it is complete trash. That goes from mere poorly written prose to factual error and actually offensive content. Early experiments with the technology would result in chatbots which quickly started spewing out offensive language themselves, proving that they are unfit for purpose. This is why modern LLMs are moderated by a second stage filtering their output.

Unfortunately, as written above, this second stage is built by people rating the output of the first stage. To make this useful, they need to examine huge amounts of outputs. Even the most knowledgeable people in the world could not hope to check everything for accuracy and even if they could, they cannot know every output that will ever be produced. For those, all the filter does is help set the tone. All this leads to favoring the kind of output that people like to see, which is confident-sounding text, regardless of accuracy. They will be right for the most part on widely known facts, but for the rest, it’s a gamble. More often than not, they will just give a politician-grade lie.

The right thing to do

So, as we have seen, LLMs are essentially confident-sounding lying machines with a penchant to occasionally disclose private data or plagiarise existing work. While they do this, they also use vast amounts of energy and are happy using all the GPUs you can throw at them which is a problem we’ve seen before in the field of cryptocurrencies.

As such, it does not feel right to bundle any such solution into Vivaldi. There is enough misinformation going around to risk adding more to the pile. We will not use an LLM to add a chatbot, a summarization solution or a suggestion engine to fill up forms for you until more rigorous ways to do those things are available.

Still, Vivaldi is about choice and we will continue to make it possible for people to use any LLM they wish online.

Despite all this, we feel that the field on machine learning in general remains an exciting one and may lead to features that are actually useful. In the future, we hope that it will allow us to bring good privacy-respecting features to our users with a focus on improving discoverability and accesibility.

We will keep striving to provide an featureful and ethical browsing experience.

Unpacking Google’s new “dangerous” Web-Environment-Integrity specification

Jane — Tue, 25 Jul 2023 17:51:43 +0000

Google seems to love creating specifications that are terrible for the open web and it feels like they find a way to create a new one every few months. This time, we have come across some controversy caused by a new Web Environment Integrity that Google seems to be working on.

At this time, I could not find any official message from Google about this spec, so it is possible that it is just the work of some misguided engineer at the company that has no backing from higher up, but it seems to be work that has gone on for more than a year, and the resulting spec is so toxic to the open Web that at this point, Google needs to at least give some explanation as to how it could go so far.

What is Web Environment Integrity? It is simply dangerous.

The spec in question, which is described at https://github.com/RupertBenWiser/Web-Environment-Integrity/blob/main/explainer.md, is called Web Environment Integrity. The idea of it is as simple as it is dangerous. It would provide websites with an API telling them whether the browser and the platform it is running on that is currently in use is trusted by an authoritative third party (called an attester). The details are nebulous, but the goal seems to be to prevent “fake” interactions with websites of all kinds. While this seems like a noble motivation, and the use cases listed seem very reasonable, the solution proposed is absolutely terrible and has already been equated with DRM for websites, with all that it implies.

It is also interesting to note that the first use case listed is about ensuring that interactions with ads are genuine. While this is not problematic on the surface, it certainly hints at the idea that Google is willing to use any means of bolstering its advertising platform, regardless of the potential harm to the users of the web.

Despite the text mentioning the incredible risk of excluding vendors (read, other browsers), it only makes a lukewarm attempt at addressing the issue and ends up without any real solution.

So, what is the issue?

Simply, if an entity has the power of deciding which browsers are trusted and which are not, there is no guarantee that they will trust any given browser. Any new browser would by default not be trusted until they have somehow demonstrated that they are trustworthy, to the discretion of the attesters. Also, anyone stuck running on legacy software where this spec is not supported would eventually be excluded from the web.

To make matters worse, the primary example given of an attester is Google Play on Android. This means Google decides which browser is trustworthy on its own platform. I do not see how they can be expected to be impartial.

On Windows, they would probably defer to Microsoft via the Windows Store, and on Mac, they would defer to Apple. So, we can expect that at least Edge and Safari are going to be trusted. Any other browser will be left to the good graces of those three companies.

Of course, you can note one glaring omission in the previous paragraph. What of Linux? Well, that is the big question. Will Linux be completely excluded from browsing the web? Or will Canonical become the decider by virtue of controlling the snaps package repositories? Who knows. But it’s not looking good for Linux.

This alone would be bad enough, but it gets worse. The spec hints heavily that one aim is to ensure that real people are interacting with the website. It does not clarify in any way how it aims to do that, so we are left with some big questions about how it will achieve this.

Will behavioral data be used to see if the user behaves in a human-like fashion? Will this data be presented to the attesters? Will accessibility tools that rely on automating input to the browser cause it to become untrusted? Will it affect extensions? The spec does currently specify a carveout for browser modifications and extensions, but those can make automating interactions with a website trivial. So, either the spec is useless or restrictions will eventually be applied there too. It would otherwise be trivial for an attacker to bypass the whole thing.

Can we just refuse to implement it?

Unfortunately, it’s not that simple this time. Any browser choosing not to implement this would not be trusted and any website choosing to use this API could therefore reject users from those browsers. Google also has ways to drive adoptions by websites themselves.

First, they can easily make all their properties depend on using these features, and not being able to use Google websites is a death sentence for most browsers already.

Furthermore, they could try to mandate that sites that use Google Ads use this API as well, which makes sense since the first goal is to prevent fake ad clicks. That would quickly ensure that any browser not supporting the API would be doomed.

There is hope.

There is an overwhelming likelihood that EU law will not allow a few companies to have a huge amount of power in deciding which browsers are allowed and which are not. There is no doubt that attesters would be under a huge amount of pressure to be as fair as possible.

Unfortunately, legislative and judicial machineries tend to be slow and there is no saying how much damage will be done while governments and judges are examining this. If this is allowed to move forward, it will be a hard time for the open web and might affect smaller vendors significantly.

It has been long known that Google’s dominance of the web browser market gives them the potential to become an existential threat to the web. With every bad idea they have brought to the table, like FLOC, TOPIC, and Client Hints, they have come closer to realizing that potential.

Web Environment Integrity is more of the same but also a step above the rest in the threat it represents, especially since it could be used to encourage Microsoft and Apple to cooperate with Google to restrict competition both in the browser space and the operating system space. It is imperative that they be called out on this and prevented from moving forward.

While our vigilance allows us to notice and push back against all these attempts to undermine the web, the only long-term solution is to get Google to be on an even playing field. Legislation helps there, but so does reducing their market share.

Similarly, our voice grows in strength for every Vivaldi user, allowing us to be more effective in these discussions. We hope that users of the web realize this and choose their browsers consequently.

The fight for the web to remain open is going to be a long one and there is much at stake. Let us fight together.

Client hints or client lies?

YngveNPettersen — Fri, 13 Jan 2023 12:38:09 +0000

The User Agent header

The User Agent header has been used for decades to identify the browser connecting to the server, both for statistics purposes, and to work around bugs in specific versions of the browser.

Unfortunately, it has also been used to block browsers, because they are not one of the “supported browsers”. This has been implemented both as pure blocks, or more insidious ones like not sending the same content as for other browser, “because that browser does not support it, anyway”.

To work around such problems, browsers started to include parts of the identification strings of some of the other browsers, mostly the major ones. This may have started with Internet Explorer, if not earlier.

While at Opera, we tried to identify as just plain “Opera”, without any of the other pretensions, but we eventually had to start sending fake User Agents to many sites, due to them blocking us or sending us bad data.

One of the more notable cases was what I call the “Catch-22 cookie”, which was a bad cookie checker that usually works like this:

A new user loads the site.
Since the user does not have any cookies, check if the client supports cookies by sending a cookie.
Redirect to a new page that checks that the cookie was returned, and, if not, tell the user to enable cookies.

The problem in our case was that the code in step 2 sending the cookie first checked the User Agent string against a list in a Microsoft IIS server Client Capabilities module. It then only sent a cookie if the list said that the User Agent supported cookies. And since the module did not have Opera listed as a client that supported cookies, it did not send any cookies.

So, when reaching step 3, Opera, of course, did not have a cookie to send, because it never received one, and the user got told to enable cookies. Catch-22!

The site in question was rather large and important, so we needed it fixed. However, in the end, we actually had to submit patches to Microsoft to fix their server product.

To work, such a list needs to be based on perfect knowledge about all existing clients, which is difficult and costly, if not impossible.

The proper way of conducting this test would have been to always send a dummy cookie and remove it after the test completed. And, the capabilities module’s list should have been a block list for known user agents that the server shouldn’t send cookies to.

At Vivaldi, we’ve also encountered issues when identifying as “Vivaldi” and tried to use customized User Agents with sites that broke. Eventually, we gave up and started just identifying as Chrome to all websites, except those few that we knew would handle our Vivaldi ID correctly (e.g., our own site or our partners’).

But, it is not just the name of the browser that can cause trouble, it can also be the version number.

When Opera reached version 10, we actually encountered websites that believed the version was 1.0, not 10.0. The reason was that the scripts that processes the header were hardcoded to assume there was just one digit in from of the version dot, so two-digit numbers broke the script. We thus had to stop the version at 9.9 and add a second Opera-specific User Agent name to identify the 10.x+ versions.

We encountered similar issues when we reached Vivaldi 1.10. Again, websites assumed there was just one digit in the minor version number, so 1.10 was considered 1.1. Instead, we had to use 1.91 as the version number in the User Agent string.

When we later reached 2.10 and were still encountering extensive browser sniffing at levels that made adding overrides unsustainable, we decided “ it!” and stopped sending “Vivaldi” in the general User Agent header.

It is not just Client version numbers that are causing issues. A couple of months ago, I discovered that the Chromium code had frozen the MacOS version in the User Agent string at 10.15.7, the last released Mac OSX 10.x release, because websites would refuse to accept requests from machines running MacOS 11 (or later) and using that in the OS part of the User Agent String. Oops!

This is actually a problem for our bug reports, since we record the OS version from the User Agent string when bugs are reported. So, unless the reporter adds extra information, we may not realize the report is for Mac OS 11, 12, or 13.

In a related development, a year ago, the Chromium team actually had to run a long series of tests while preparing for their release of Chromium 100, due to the possibility of them encountering the same kind of problems. I assume Mozilla did something similar before they reached version 100.

More recently, there has been work to retire the User Agent header, starting with a reduction in the version information in the User Agent header. Chromium 106+ is no longer sending detailed information abut the version, just “106.0.0.0”. This is part of the transition to a new system of providing information about the browser: “Client Hints”.

Client Hints

Over the past few years, work has been going on to create a new system to provide more accurate information about the browser to the website, called Client Hints.

This new system is based around a set of HTTP headers prefixed with “Sec-CH-“, e.g. “Sec-CH-UA”, the new User Agent header. There are also headers for other information, browser engine, device, OS, resolution of the document on the display, etc.

Standards-wise, the system is based on the server indicating which of these headers it wants to receive. The browser then sends them if it supports them. However, Chromium, at the very least, is currently always sending three of these headers, including the User Agent (Sec-CH-UA), mobile, and platform information, and may send others.

Chrome’s Sec-CH-UA header contains information about browser brands and their version (Chrome and Chromium), as well as a “brand” value called “Not A Brand”.

The brand values are regularly (based on the version numbers) shuffled around in the header, and the “Not A Brand” value is also regularly modified by inserting various non-letter characters like “;”, “:”, and “.”, a process called “GREASE”, which has the effect of varying the header, so websites cannot rely on a particular sequence of values, or the text in the values. It thus attempts to force them into writing parsers that are standards compliant and don’t take shortcuts.

Vivaldi is currently not including a brand in this header, only sending “Chromium” and the “Not A Brand” values.

Client Lies

The big question about Client Hints is whether they (in particular Sec-CH-UA) will work better for browsers than the User Agent string?

Will websites properly parse the headers (Really?? ) and only use them responsibly (🤣 🙃). Or, will they start abusing this information to block “unsupported” browsers, too (😭)?

Unfortunately, the early indications are that some won’t parse properly, and others will use them to block “unsupported” browsers.

We have, so far, encountered two cases, one of each, where sites would not work for Vivaldi due to how the websites processed the Sec-CH-UA header information.

The first case was a website that worked in one version of Vivaldi but failed to load in the next, due to a server-side problem. This turned out to be due to the value shuffling and GREASE modification of the “Not A Brand” value. Chromium varies the sequence of values differently in each Chromium version, e.g.:

“Chromium”;v=”108″, “Not?A_Brand”;v=”8″

In the failing version, the sequence was “Not a Brand” and “Chromium”, and the “Not a Brand” value included a semicolon (“;”) character, which is used to separate values in unquoted text, but is just a normal character when it is in a quoted value. The website’s header parser ignored the quotes, and the result was that, when the “Not A Brand” value is first, the parser (and the server script) crashed.

Further investigation revealed that browsers with a branded header (e.g., Chrome and Microsoft Edge) would never have the “Not A Brand” value at the start of the header. Unbranded ones would have it that way every even-numbered Chromium version, that is, the Extended Stable versions, like 106 and 108. And every third of those would have a semi-colon in the string in a way that would break the parsing.

We “solved” that problem by freezing the sequence, so the “Chromium” brand was always first in the header.

In my opinion, part of the problem here is that Chromium does not vary the header enough, and not frequently enough. As mentioned, the branded browsers would never send the variation that caused our problem, and fact that Chromium only varies the content for each Chromium release, and not more often, means that it can take a long time (years) to discover parser problems like the one we encountered.

Part of the reason why the header isn’t varied more frequently is that the header value can be used as part of the key by websites to return cached webpages requested with the exact same set of URL and certain headers. Frequently changing the header value would increase the load on the website cache system and servers.

I still think that should not be a blocker for varying the sequence more frequently.

The second problem was a Japanese site that used the JavaScript APIs to access the Sec-CH-UA values and for whatever reason refused to serve the requested content if the brand wasn’t “Chrome” or “Microsoft Edge” (Firefox was accepted using a different test).

We have not yet worked around this issue, but, as far as we can tell, the only workaround is to use one of the “approved” brand names in our header. Using “Vivaldi” as the brand would not work.

If we encounter further issues of this kind, my guess is that the only way we can avoid the problem is to do like we did with the old User Agent string: pretend to be Google Chrome and make sure we do not send any Vivaldi-specific information.

That may not have been the desired goal for Client Hints, but if the last several decades of using User Agent string information have proven anything, it is that only the major vendors (OS or browser) are able to tell the truth. Everybody else will have to tell lies one way or the other – even Microsoft had to tell lies when they started distributing Internet Explorer.

Pulling the plug on expired Operating Systems

YngveNPettersen — Thu, 24 Nov 2022 14:41:19 +0000

All browsers run in an Operating System (OS) environment, whether it is named Android, iOS, Linux, macOS, ChromeOS, or Windows. These OSes provide a large amount of functionality to the applications running on them, like file system, keyboard, mouse, and graphics support. They manage the hardware-specific drivers for this functionality so that the applications don’t have to implement everything from fundamentals.

Life of an Operating System (OS)

Each OS is regularly updated with bug fixes, new functionality, and adaptions to new hardware. Usually, new functionality is added every few years, while bug fixes, especially security patches, are released more frequently to update existing OS versions.

Maintaining older versions of OSes become problematic after a while, as one needs to test all these versions on hardware and configurations that may no longer be available, or difficult to find. There will also be a question of having the resources, including employees who know the older systems and hardware.

How long an OS version is maintained, and what will be maintained, is usually decided well in advance of the last update. Usually, there will be several years of only releasing security updates, and even these can be difficult, if not impossible, to develop as the OS gets older.

Once the End-Of-Life(EOL) date is reached, the updates will stop, and users on the now-unsupported OS version will have to move to a newer version (if possible, or to new hardware), or live with the risk of having their computer attacked.

Just in the last few years, various OS versions have reached their EOL dates, e.g Android 6, Windows 7 (although one could pay for a few more years of support), MacOS 10.12, and early next year Windows 7 (extended support) and Windows 8.1 reach EOL, too.

Browser challenges due to different OS versions

All the various OS versions cause challenges for browsers, too. All that nice functionality the OS is managing for the applications is accessed through various function calls, called SDKsand APIs. These tend to change, new ones added, and old ones removed in newer versions of the OS, which means that to support older OSes special code needs to be written to adapt to the changes, and all of these variations need to be tested, usually on relevant hardware, which as mentioned can be hard to find. These adaptations also tend to complicate the logic of the code, making maintenance and testing more difficult, and can introduce bugs that are difficult to find.

So, when an OS version reaches EOL it becomes a question of whether or not the browser should support that older version, and how long it should be supported. One factor can be the number of users on the older platform, and another is how difficult continued support will be to maintain.

Goodbye Windows 7 and Windows 8.1

Regarding Windows 7, at present support has been maintained for three years past the consumer EOL, probably because there were still a lot of users, and because corporate users could still purchase maintenance updates. There might have been some overlap with Windows 8.1 variants. The extended support by Microsoft for Windows 7 ends in early 2023, as does the support for Windows 8.1.

At this point, for each EOL OS version, it becomes a question for browser engine vendors whether they should continue to support these versions, or remove the adaptions for the old version(s).

This evaluation must consider how difficult will it be to maintain, especially if supporting tools like the compilers and SDK packages, both of which need to be updated regularly to be able to support the newest OS versions, stop supporting the older versions, too. Once that happens, the question becomes even more pointed: Support old, obsolete OS versions, or the newer versions?

The correct answer is, of course, to support the newer versions, and retire the older ones.

Thus, at present, the Chromium team has decided to end support for Win7 and Win8.1 in early 2023. Following the point at which they no longer support these OS versions, the teams will start to remove the obsolete code, making it effectively impossible for a Windows executable to run on those OS versions.

Will Vivaldi support Win7 and Win8.1?

Sorry, no. Since Vivaldi is based on Chromium, we will get these updates removing Win7 and Win8.1 support when we next update the Chromium source, to Chromium 110, which will be the foundation for the next Vivaldi version after Vivaldi 5.6.

As a related example, on Linux, while Chromium did end support for 32-bit (386) Linux, Vivaldi continued to release builds as long as they continued to build and run until the builds stopped running. As it turns out, the most recent 386 release of Vivaldi (3.8) does not run, because Chromium updated to a version of a central library that was not supported by 386 versions of Linux (some Linux distros do distribute patched versions that avoid the issue in their 386 versions).

Recommendation: Update to a more modern operating system (OS)

When such support ends it is time to, at least, update the OS to a newer version, although in some cases that might mean buying new hardware (at least more disk space and memory, although Windows 10 may require a new machine).

Another option is to change to an alternative OS that supports your hardware, e.g. Linux supports quite old hardware and should be able to run 64-bit versions on CPUs from the past 10-15 years.

When you are using a computer with an OS installation that is more than 5-6 years old, it is usually time to consider updating to a more modern OS, anyway, even if the browsers and other applications you are using still work. It is usually just a question of time before the OS is no longer supported. By considering your options early, you won’t have to do emergency migrations (or risk security problems). For your system, having an up-to-date environment will provide the best features and security.

The trouble with Chromium translations

YngveNPettersen — Fri, 11 Nov 2022 12:33:17 +0000

Most applications that are intended for a broad international audience have their UI translated to various languages. But the number of languages varies widely, depending on the resources of the vendor, especially their ability to recruit translators.

Vivaldi is currently being translated to 91 languages, a few more than in Chrome.

Under the hood, Vivaldi’s UI string translation system actually consists of two independent systems: the Chromium one and rhe system used by Vivaldi’s native UI.

This article will only cover the Chromium system and the challenges of using it.

First things first

The Chromium string/text translation and resource system consists of two kinds of files:

The GRD files, which can declare the US English version of the strings, and the location of various file resources like icons and documents (HTML, JS, CSS) used by the Chromium UI, and

The XTB files, one for each language, contain the various translations of the original strings in the associated GRD file.

When building the product (Vivaldi, in our case), these files are processed by various scripts in the build system and converted into files that can be handled by the Chromium code handling strings and the resources.

One of the challenges for a product like Vivaldi is that the strings and resources defined by the Chromium project are very specific to Chromium and Google Chrome, such as logos and the company and product names used in the string.

But, of course, we in Vivaldi want to use the Vivaldi logo, and to use “Vivaldi” and name of our product and company.

This means that we have to change the resource definitions and the strings (and translations) to use Vivaldi’s preferred resources and names.

How do you change a file without changing it?

If you’ve read my article about maintaining a Chromium fork, you will have noticed that I said that you should never modify the Chromium translation files. Yet, I just said above that, to use our preferred resources and strings, we must change the files. Why shouldn’t we change the files, and how do we work around the problem so we can use our chosen resources?

There are two reasons why we should not change the files:

First, the Chromium resource files are frequently updated by the Chromium team. New resources and new strings are added, and old ones are changed to improve their meaning, and occasionally some are removed. All of these changes mean that when upgrading the Chromium source code, there is a significant risk that these changes will occur to the specific lines of the file we modified, or close to them. That means that we would have to resolve the conflicts between the new text and our changes, which will significantly increase the time needed to complete the update.
Second, for the strings we would have to not just modify the GRD file entry, we would have to modify the corresponding entry in each of the 80+ translation XTB files associated with each file, and to top it off, each of those entries has a numeric identifier calculated from the original string in the GRD file, so if you change the original string, you have to recalculate the value and update each XTB file for that entry. Ouch! Lots of work. Additionally, each of those updated entries in each file is another possible update merge conflict that has to be resolved manually. Double ouch!

“String” is a term used in computer programming for “a section of text“.

So, how do we resolve this problem? How do we update the resources, strings, and translations without modifying the Chromium resource files?

The answer is that we both do and don’t change them.

What we have done for Vivaldi is to create our own resource GRD and XTB files for each set of Chromium resource files that we want to update. We add our file resources, strings, and translations in these files. The translation files are usually used to add the translations for the extra languages we support, but in some cases we do an extensive rewrite of the original string, which requires more translations to be added in our version.

Then, while building the application, we have updated the project and the scripts it used to automatically insert our updated changes into the data, before they are used to generate the binary files used by the application.

The result is that we don’t have to update the original files, but we can update the resources, strings, and translations.

This process is also used to automatically replace mentions of Chromium and Google Chrome company and product names with Vivaldi’s name, both in the original US English strings and the translations. This process does have its challenges, especially since “Google” is frequently used in combination with other words to name products we don’t support, like “Google Pay”, so we have to exclude such replacements.

Occasionally, there are strings that mention the Google, Chrome, or Chromium names when replacing them with Vivaldi is not desirable (and an example just showed up in the forums, where information about a system Google is working on said “Vivaldi” instead, which has now been “fixed”). In these cases, we exclude that particular string from being replaced.

Another recent example was the string “Chrome is made possible by the Chromium open-source project”, which was auto replaced with “Vivaldi is made possible by the Vivaldi open-source project”, not “Vivaldi is made possible by the Chromium open-source project”. Oooops! This was fixed by adding a full override of the text with correct wording.

Is there any other way?

Could we avoid using this kind of system? Well, there are other ways to implement such a system.

We could add an independent set of resource files (and we have those for our own), and add our replacements in those files using different identifiers for them and replace the originals everywhere they are used. However, we would still have the problem with later updates, both of the strings and their meaning, and starting to use them elsewhere (which would have to be discovered and updated). Then, there is the issue of more potential merge conflicts during updates.

Quite simply, using different identifiers would not work very well, since their use would have to be maintained continuously. Just replacing the original entries will generally work better.

And that ignores the use of product names in many strings. There are a lot of those names used around the code, and copying and modifying them into a different set of files would be a major undertaking. They would also still have to be updated with new strings every Chromium upgrade.

The best way to avoid the search and replace of product names (and thus avoid the funny cases) would be for the Chromium team to stop using “Google”, “Google Chrome”, “Chromium”, etc., hardcoded into the strings. Instead they could use variables that can insert the downstream project’s own preferred name in those strings. But this kind of project would be a major undertaking by the Chromium team, and I have my doubts that they would be willing to take it on.

What do the other Chromium-based browser teams do? I have absolutely no idea. Maybe they use a similar system, or they have found their own way to manage the issue.

This article was originally published on my blog, Yngve’s corner. If you like these technical deep dives, be sure to stop by.

Manifest V3, webRequest, and ad blockers

Jane — Fri, 23 Sep 2022 10:32:08 +0000

Back in 2019, we were loud and clear: Ad blockers or not – your choice matters.

In 2020, Vivaldi’s Ad Blocker was built as a response to the deprecations announced in Manifest V3, with the intention that it would keep working when existing ad-blocking extensions would become inoperant. The goal is to keep it working regardless of what happens regarding the extension code.

Will the Vivaldi Ad Blocker be affected by the Manifest V3 changes?

I made some architectural choices early on that I believe should keep it functional, regardless of the Manifest V3 changes. Of course, there is always a possibility that the underlying Chromium architecture will change now or in the future, forcing us to do some extra work to keep this working.

Hopefully, a more in-depth description of the architecture and some of the facts surrounding the Manifest V3 changes should help to show why I believe that our implementation is safe for the time being.

How is Vivaldi’s Ad Blocker built?

The Vivaldi Ad Blocker available on desktop and Android and in cars is built on the same internal chromium API that is used by both the Manifest V2 version of webRequest and declarativeNetRequest.

It is also designed to allow Chromium/content embedders to interact with requests performed with the Chromium network service in general. The basic idea is that the requests from the network service get proxied through some piece of code provided by the embedder that can examine or modify the request through its different stages, pretty much like webRequest currently does.

What happens after the Manifest V3 changes?

The concern of course would be that, since webRequest is going away, this particular API would become useless and disappear with it.

This is unlikely for a few reasons:

webRequest isn’t completely going away. Only the ability to block requests from webRequest is disappearing. So, at the very least, a mechanism to proxy requests from the network services through extensions there needs to keep existing.
declarativeNetRequest is currently built on top of webRequest. It is conceivable that it would be rebuilt later on to handle the blocking at a deeper level. If this ever happens, it will use a new set of hooks to handle blocking that our Ad Blocker should be able to use, as well. But there doesn’t seem to be much reason for that to happen yet.
The blocking ability of webRequest is being kept for enterprise users (at least for the time being). So, all the underlying code for webRequest including the blocking abilities will have to remain intact.

So, to the best of my reckoning, I can say that it looks very likely that the Vivaldi Ad Blocker won’t suffer any adverse effects from the Manifest V3 changes. And, if it does, there should be relatively simple ways to fix it.

Could we keep using our ad-blocking extensions in Vivaldi?

But, “Wait”, I hear you say, “Doesn’t that mean that basically, Vivaldi might be able to keep webRequest intact just by bypassing the checks for enterprise environments? Could we keep using our adblocking extensions in Vivaldi?”

This certainly sounds plausible, but it is not something that we can promise without seeing what ends up happening in the code itself. If there is an easy way to keep webRequest functioning as it did for a while longer, we’ll consider doing it.

However, it is important to note that extension ad blockers often depend on other APIs that are removed in Manifest V3 (and probably much harder to bring back), so there is no guarantee that simply keeping the blocking version of webRequest alive is going to be enough, without some work from extension maintainers.

The road ahead

The move to Manifest V3 makes it more difficult to run content blockers and privacy extensions in Chrome. While some users may not notice a difference, users who use multiple extensions or add custom filter lists may run into artificial limitations set by Google. Perhaps, wise to move away from Chrome?

As Vivaldi is built on the Chromium code, how we tackle the API change depends on how Google implements the restriction. The assurance is, whatever restrictions Google adds, in the end, we’ll look into removing them.

Our mission will always be to ensure that you have the choice.

Soooo … you say you want to maintain a Chromium fork?

YngveNPettersen — Wed, 27 Jul 2022 09:39:26 +0000

Originally published on Vivaldi.net.

(Note: this article assumes you have some familiarity with Git terminology, building Chromium, and related topics)

Building your own Chromium-based browser is a lot of work, unless you want to just ship the basic Chromium version without any changes.

If you are going to work on and release a Chromium-derived browser, on the technical side you will need a few things when you start with the serious work:

A Git source code repository for your changes
One or more developer machines, configured for each OS you want to release on
Test machines and devices to test your builds
Build machines for each platform. These should be connected to a system that will automatically build new test builds for each source update, and your work branches, as well as build production (official) builds. These should be much more powerful than your developer machines. Official builds will take several hours even on a powerful machine, and requires a lot of memory and disk space. There are various cloud solutions available, but you should weigh time and (especially) cost carefully. Frankly, having your own on-premises build server rack may cost “a bit” up front, but it lets you have better control of the system.
A web site where you can post your Official builds so that your users can download and install them Now you are good to go, and you can start developing and releasing your browser.

Then … the Chromium team releases a new major version (which they do every 4 or 8 weeks, depending on the track) with lots of security fixes. Now your browser is buggy and unsecure. How do you get your fixes to the new version?

This process can get very involved and messy, especially if you have a lot of patches on the Chromium code. These will frequently introduce merge conflicts when updating the source code to a newer Chromium version because the upstream project have updated the code you patched, or just nearby, but there are a few things you can do about that to reduce the problems.

There are at least two major ways to maintain updates for a code base: A git branch, and diff patches to be applied on a clean checkout. Both have benefits and challenges, but both will have to be updated regularly to match the upstream code. The process described below is for a git branch.

The major rule is to put all (or as much as practical) of your additional independent code that is whole classes and functions (even extra functions in Chromium classes) in a separate repository module that have the Chromium code as a submodule. Vivaldi uses special extensions to the GN project language to update the relevant targets with the new files and dependencies.

Other rules for patches are:

Put all added include/imports after the upstream includes/import declaration.
Similarly, group all new functions and members in classes at the end of the section. Do the same for other declarations.
Any functions you have to add in a source file should always be put at the end of the file, or at the end of an internal namespace.
Generally, try to put an empty line above and below your patch.
Identify all of your patches’ start and end.
Don’t change indentation of unmodified original code lines, unless you have to (e.g. in Python files).
Repetitive patching of the same lines should be fixuped or squashed. Such repetitions have the potential to trigger multiple merge conflicts during the update, which could easily cause errors and bugs to be introduced.
NEVER (repeat: NEVER!!!) modify the Chromium string and translation files (GRD and XTB). You will be in for a world of hurt when strings change (and some tools can mess up these files under certain conditions). If you need to override strings add the overrides via scripts, e.g. in the grit system merging your own changes with with the upstream ones (Vivaldi is using such a modified system; if there is enough interest from embedders we may upstream it; you can find the scripts in the Vivaldi source bundle if you want to investigate). Vivaldi uses (mostly) Git submodules to manage submodules, rather than the DEPS file system used by Chromium (some parts of Vivaldi’s upstream source code and tools are downloaded using this system, though). Our process for updating Chromium will work whichever system is used, with some modifications.

The first step of the process is identifying which upstream commit (U) you are going to move the code to, and what is the first (F) and last (L, which you create a work branch W for) commit you are going to move on top of that commit. If you have updated submodules you do this for those as well.

(There are different ways to organize the work branch. We use a branch that is rebased for each update. A different way is to merge the upstream updates into the branch you are using, however this quickly gets even messier than rebasing branches, especially when doing major updates, and after two years of that we started rebasing branches instead.)

The second step is to check out the upstream U commit, including submodules. If you are using Git submodules you configure these at this stage. This commit should be handled as a separate commit, and not included in the F to L commits.

Then you update the submodules with any patches, and update the commit references.

The resulting Chromium checkout can be called W_0

Now we can start moving patches on top of W_0. The git command for this is deceptively simple:

git rebase --onto W_0 F~1 W

This applies each commit F through to L (inclusive) in sequence onto the W_0 commit and names the resulting branch W.

A number of these commits (about 10% of patched files in Vivaldi’s source base) will encounter merge conflicts when they are applied, and the process will pause while you repair the conflicts.

It is important to carefully consider the conflicts and whether they may cause functionality to break, and register such possibilities in your bug tracking system.

Once the rebase has completed (a process that can take several workdays) it is time for the next step: Get the code to build again.

This is done the same way as you normally build your browser, fixing compile errors as they are encountered, and yet again registering any that could potentially break the product. This is also a step that can take several work days. A frequent source of build problems are API changes and retired/renamed header files.

Once you have it built and running on your machine, it is time to (finally) commit all your changes and update the work branch in the top module and push everything into your repository. My suggestion is that patches in Chromium are mostly committed as “fixups” of the original patch; this will reduce the merge conflict potential, and keeps your patch in one piece.

Then you should try compiling it on your other delivery platforms, and fix any compile errors there.

Once you have it built and preferably have it running of the other platforms, you can have your autobuilders build the product for each platform, and start more detailed testing, fixing the outstanding issues and regressions that might have been introduced by the update. Depending on your project’s complexity, this can take several weeks to complete.

This entire sequence can be partially automated; you still have to manually fix merge conflicts and compile errors, as well as testing and fixing the resulting executable.

At the time of writing, Vivaldi has just integrated Chromium 104 into our code base, a process that took just over two weeks (the process may take longer at times). Vivaldi is only using the 8-week-cycle Extended Stable releases of Chromium due to the time needed to update the code base and stabilize the product afterwards. In our opinion, if you have a significant number of patches, the only way you can follow the 4 week cycle is to have at least two full teams for upgrades and development, and very likely the upgrade process will have to update weekly to the most recent dev or canary release.

Once you get your browser into production every couple of weeks you are going to encounter a slightly different problem: keeping the browser up to date with the (security) patches applied to the upstream version you are basing your fork on. This means, again, that you have to update the code base, but these changes are usually not as major as they are for a major version upgrade. A slightly modified, less complicated variant of the above process can be used to perform such minor version updates, and in our case this smaller process usually takes just a few hours.

Good luck with your brand new browser fork!

Cover photo by Ari Greve

Good riddance, Internet Explorer!

Jane — Thu, 16 Jun 2022 15:30:00 +0000

On the 17th of August, Microsoft decided to kill off its Internet Explorer browser. The browser lives on as Edge which first appeared with an engine also called Edge, but finally, the original Internet Explorer has been put to rest.

It is unfortunate that we now have one less browser engine on the Internet. Competition is good and fewer browser engines means less innovation in browser engines. It is quite simple really.

But that being said, the loss of Internet Explorer is not really a loss. The loss of the Presto browser engine was a much bigger loss. In fact, I would say that the Web is better off without Internet Explorer, something even Microsoft has understood.

Internet Explorer: Embrace, extend, extinguish

The first Internet Explorer was based off the original Mosaic code, licensed from Spyglass. Microsoft was late to the Web game. Their original goal was to build their own Internet, but like other proprietary attempts at building Internet, such as AOL and Compuserve, they failed.

Having seen the growth of Netscape, Microsoft understood that they needed to act and they did. After getting the license from Spyglass, they started on their road of the infamous Embrace, extend, extinguish tactic.

The principle there was to embrace web standards and get the standards community on board. After “cutting off the air supply” from Netscape, by bundling IE with Windows and stopping any ability to get browsers bundled on Windows computers, they quickly took the lead in the browser market.

They then started to expand on the web standards, with total disregard for the standards community. During this time they introduced technology such as ActiveX and Silverlight, making it impossible to use competing browsers when accessing services that used those technologies.

They also added various proprietary tags in their HTML/CSS/JS code, which made life difficult for web developers. In reality, many web developers made sites optimized for IE, instead of for web standards, making it really hard for competing browsers.

Microsoft close to taking over the Web

At the time, I was leading the Opera browser which I had co-founded with Geir Ivarsøy.

As a competitor of Microsoft, we noticed a lot of the things they did to kill off competition.

Getting distribution with any Windows-based computer was impossible. Projects we were involved with, such as with Compaq and Intel, got canceled due to threats from Microsoft. We had to deal with compatibility issues across the board. Some examples include:

Microsoft made their own server software and in an update (to version 4), they included a file that made sure we would not be sent cookies. It took us a really long time to figure that one out. Websites, such as the BBC, broke, and we got the blame. After we discovered the issue, Microsoft fixed it.
Microsoft barred Opera users from accessing their MSN service, claiming we did not support XHTML. We wrote a press release rebutting them, in XHTML. The reality was that we supported XHTML, but they did not.
Microsoft sent Opera users a broken CSS file, which meant that text overlapped. We had a bit of fun with this one and made a special Bork edition of Opera that changed all the text on the MSN site to something resembling the way the Swedish Cook spoke in the Muppet show. It worked and Microsoft fixed their site.

But there were a lot more websites with issues. Given that Microsoft deviated from the standards and they had the most used browser, so many sites demanded that you use Internet Explorer to access their content.

Microsoft was really close to taking over the Web fully.

Jon von Tetzchner on stage.

Microsoft’s tactic backfires

Microsoft killed Netscape and although Netscape was replaced by Mozilla, Mozilla did not have a lot of clout in the early days.

Luckily Microsoft’s tactic backfired.

They stopped developing Internet Explorer after Internet Explorer 6, presumably because they wanted to move people over to Silverlight instead.

At the same time, Opera, Mozilla, and Apple, alongside the World Wide Web consortium, decided to work together on improving Web standards. Together we wrote HTML 4, which took the Web to another level.

Gradually our combined user base started to grow and Microsoft was forced to restart the development of Internet Explorer, but from this point onwards they were lagging behind. They still lead the market share, but they had lost momentum, and given that both the US government and the EU were watching Microsoft’s anti-competitive behavior, they were somewhat limited in their response.

Microsoft was pretty close to being split up over how they had used their domination in the browser market to kill off Netscape. With the government watching, they had to compete more on the merits and there they lost. Suddenly their incompatibility had moved from being an asset to being a liability.

Websites code for Web standards first, not Internet Explorer

Instead of sites coding for Internet Explorer first, more and more sites began coding for the standards first and then for Internet Explorer.

Microsoft was now dealing with the problem they had created. It became hard for them to both support the standards and their own deviations from those standards. Finally, they decided to drop their old code and embrace the standards. As doing that from scratch is hard and as there still is a lot of code there looking for their name in identification strings, they decided to use Chromium instead.

* * *

Microsoft can not be written off. Given that the focus of governments is now more on Google and Facebook, you can see how Microsoft is gradually trying to use their position to steal users in Windows, during updates and by making it hard for competing browsers to fully default.

At the same time, it is good to see that Internet Explorer is gone. As much as I want there to be choice on the Internet, Internet Explorer is not a choice we ever needed.

Photo by Aron Visuals on Unsplash.

Recent edit: This blog has been republished on 16th June 2022.

Ever get the feeling you’re being watched?

Jane — Mon, 16 May 2022 07:44:02 +0000

Massive information about us is collected from all quarters of our lives. And, as this information is compiled, it develops a highly detailed picture of us – one that reveals what we do in our daily lives, including in our most sensitive moments.

This Spy Cat video, produced by the Consumers’ Association of Iceland in collaboration with Vivaldi, takes a darkly humorous approach to make the pervasiveness and hazards of targeted profiling and advertising more relatable. Please view and share!

For more information about this campaign, as well as tips for avoiding or limiting the information being gathered about you, visit banspying.org.

And a special shout out goes to Flóki, Hneta, Lotta, Mandarína, Milla, Mirra, Móri and Stormur for channeling their inquisitive feline powers for this video. Fortunately for us, their true intentions were 0% evil, 100% adorable.

What do you think about this campaign? Let us know in the comments.

Heads up: Google’s going off Topics again.

Jane — Thu, 27 Jan 2022 17:18:28 +0000

Google recently released a proposal for a third-party cookie replacement technology called Topics. It’s move meant to satisfy the needs of advertisers while side-stepping many of the privacy pitfalls of their previous proposal, FLoC, the privacy nightmare we denounced earlier this year.

But with Topics, Google is just twisting user tracking and profiling in different ways.

Right from the start, the document outlining how the Topics API works, clearly shows its true purpose:

key use cases that browsers want to support […] is interest-based advertising […] a form of personalized advertising in which an ad is selected for the user based on interests derived from the sites that they’ve visited in the past

That is behavioral profiling.

How does Topics differ from FLoC?

Google limits the amount of information a site can gather to a few topics initially from a set that might be as big as a few thousands and only allows a single additional topic to be obtained every week. They also limit the topics advertisers can see to topics offered by sites on which those advertisers are present, giving topics approximately the same reach as third-party cookies. Some random topics might be offered as well and Google claims that this lessens the chance that sharing a given topic will automatically be compromising or identifying.

Google also claims that this will reduce the ability of advertisers to gather enough data themselves for building a profile, but it is clear that big advertisers that have sites covering all topics will be able to obtain a full list of topics of interest for a user quite fast. We also suspect that smaller advertisers will be able to easily build workarounds

The only really useful part is that users are able to disable the whole system or exclude certain topics in a way that can’t be easily detected. However, we expect that most users won’t change the defaults and will just fall victim to this anyway.

In addition, the wording in the specification is loose and ambiguous in a way that leaves it open to manipulation by Google, to expose more or less information. This is especially possible for websites that cover a large range of topics, such as Google and Facebook, which will be able to observe the widest range of behaviorally profiled information.

How Topics stays true to the FLoC spirit

Topics has the same fundamental problem as FLoC: it enables third parties to build profiles, which is always problematic, no matter how many privacy mitigations you put around it. Your browser would still learn about your interests as you move around the web. So, it’s basically spyware.

As we know, revealing information about the user’s interests to various entities, even slowly, will allow them over time to identify political affiliation, sexual orientation, and other personal information about the user. This can have real-world consequences. And, as has been shown by the Cambridge Analytica scandal, this identification can be done even with very few topics. The little randomness element Google has added will unlikely do much to counter this.

Indeed, in going back to the drawing board after FLoC, the only aspects Google seems to have looked into are the ability to identify someone and to get compromising information about them. But this is addressed less by making improvements than by creating a complex system that is harder to analyze for loopholes. But the loopholes remain and can be played.

The Verdict?

Based on this, and Google’s track record, we currently have no faith in the new Topics API. Adding tweaks upon tweaks to “fix” privacy issues of a system that’s specifically engineered to leak user information only ends up obscuring the real problem and leading nowhere. Even if a compromise could be reached for now, the system would not be safe from future tweaks that could lead to leaking more information about a user.

We believe that spying on people’s behavior and profiling them is wrong. Period. It is easy to get misled by this new variation of FLoC, since it does appear to have made some positive changes. However, it still violates your privacy. And pretending that behavioral profiling can be okay as long as you hide a few bits of information, or sometimes add false information, is really missing the point that you shouldn’t be profiling in the first place.

Instead of arguing endlessly about whether profiling can be made acceptable (it can’t), we would much rather start with a return to context-based advertising and then fine-tune that, if (as Google claims) there are indeed cases where it doesn’t work.

At least this time, we can just disable it without fearing that it will cause issues in the future.

Nice try, Google, but you are still off-topics on this one.

Input from Vivaldi developers Tarquin Wilton-Jones and Julien Picalausa

Why Vivaldi will never create ThinkCoin

Jon McCullough — Thu, 13 Jan 2022 11:04:48 +0000

Some years ago, when cryptocurrencies weren’t talked about as much, we were considering announcing a parody cryptocurrency for April’s Fools. It would be called ThinkCoin, and the joke was that all the value associated with it was in the mind of the user, with no software to back it in the real world.

This was ridiculous, of course, playing on the idea that actual cryptocurrencies have no actual value either. This should tell you that we never thought seriously about entering that space. These days, however, with the incredible hype and attention that cryptocurrencies, and more recently NFTs, are currently getting, we couldn’t even go for such a joke, for fear that it would be taken seriously.

Since the discussion around cryptocurrencies has reached such an extreme, I think it is high time to clarify Vivaldi’s position.

Cryptocurrency – is it a revolution?

Cryptocurrency has been touted by many as a revolution in currency, the future of investment, and a breakthrough technology. But if you look beyond the hype, you’ll find nothing more than a pyramid scheme posing as currency.

It’s basically a digital commodity, though one without government backing or banking system support. Claiming to be the new digital currency of the internet, cryptocurrencies promise decentralization and freedom from governments.

Each cryptocurrency typically follows a certain recipe to ensure that the founders create a lot of wealth, a way to distribute the currency to give it legitimacy, and some story on how it is different from all the others.

But since cryptocurrencies are too volatile to be used as an actual currency, people treat it as a sort of investment scheme. The problem is that to extract actual money from the system you have to find someone willing to buy the tokens you are holding. And this is only likely to happen as long as they believe they will be able to sell them on to someone who’ll pay even more for them. And so on, and so on.

If at any point one stops being able to find people willing to buy those tokens on just the promise of them being worth more in the future, the whole scheme might well come crashing down, with the value of all tokens going to zero.

An environmental disaster

The energy consumption of cryptocurrency is another major concern. The energy usage of bitcoin alone is staggering, consuming as much electricity as some countries. And this is likely to keep increasing as the technology behind it does not and cannot scale in any reasonable way.

For obvious reasons, that sort of energy consumption isn’t good for the environment as the energy could clearly be spent better somewhere else. This is also true if it’s renewable energy since it could instead be used to displace fossil fuels in other applications.

While so many of us are trying our best to reduce our carbon footprints, it feels counterproductive to indulge in technology that undoes that hard work.

The entire crypto fantasy is designed to lure you into a system that is extremely inefficient, consumes vast amounts of energy, uses large amounts of hardware that could better be spent doing something else and will quite often result in the average person losing any money they might put into it.

Jon von Tetzchner

Where we stand

At the time of writing (January 2022), there are over 8,000 cryptocurrencies in existence. Compare this to the 180 actual currencies worldwide that can be used as legal tender.

The most baffling part of this cryptocurrency craze is that it’s still unclear if there is any viable use case or a meaningful way to value it. Without this, it is reduced to merely an overcomplicated slot machine for those with money to burn.

Yet, despite all the negatives, there will still be those who opt to participate. And for those who end up owning some crypto tokens that they’ll need to manage, the browser might seem a logical place to keep track of it all. Indeed, some of our competitors have done just that and now provide crypto-wallets in the browser.

Since Vivaldi is all about offering choices and customizability, you might expect us to include this functionality, as well. But in good conscience, we cannot.

The entire crypto fantasy is designed to lure you into a system that is extremely inefficient, consumes vast amounts of energy, uses large amounts of hardware that could better be spent doing something else and will quite often result in the average person losing any money they might put into it.

When you strip away the hype, these virtual currencies have very real repercussions for people, society, and the environment. By creating our own cryptocurrency or supporting cryptocurrency-related features in the browser, we would be helping our users to participate in what is at best a gamble and at worst a scam. It would be unethical, plain and simple.

We refuse to dress these scams up as opportunities. Instead, we encourage you to treat them with the skepticism they deserve. This may be a game for some curious crypto-investors and wealthy speculators, but for those unlucky enough to get caught out by the pyramid scheme, it could be devastating.

It’s just not worth it.

What are your thoughts on Vivaldi’s stance or cryptocurrencies in general? Let us know in the comments below.