Security and Vivaldi

Vivaldi Security Group

The Vivaldi Security Group is a team that works to ensure the security of the products and services offered by Vivaldi. The team deals with incoming security reports, communicates with researchers, and also does proactive security research when new features and services are being developed, or whenever new security risks are identified. Each time a new technology is being considered or implemented, the Security Group will investigate the technology to check for potential weaknesses, to see if any protections are required before it can be implemented.

All code is reviewed for potential security flaws, and then the subsequent feature development is evaluated again to ensure that it complies with the security requirements.

If new issues are discovered after the initial release, fixes are prepared for the issues, and released to protect users. We aim to release security fixes as soon as possible after issues have been discovered.

We also review features of upstream open source projects such as Chromium, and disable features that we believe have a negative impact on user privacy.

 

Tracking Chromium security updates

Vivaldi follows the Extended Stable track of Chromium. This means that Vivaldi gets all the same security patches as Chromium, but the version number is different from the upstream Chromium Stable for half the time (Extended Stable follows the even Chromium version numbers, not the odd ones). We also update with Chromium security patches that are released out of the normal schedule. Having a different version number from some other browser does not mean that any patches are missing – we get the patches either way.

As a general rule, we try to be among the very first to release patches. Often the day after a patch is released, sometimes the same day, and sometimes a couple of days. The exact timing depends on various factors, but security patching is the highest priority, and we try our best to have patches made available as soon as possible. In cases where there is a delay during integration of an upstream Extended Stable release, we evaluate whether there are important security fixes from that release that need to be backported, so that they can be made available as a separate security update. See more details about how we track Chromium updates.

 

How to report security issues to us

If you have discovered an exploitable security vulnerability in any of our products or services, please contact us confidentially by filing a bug report. We will investigate the problem, and let you know the results of our investigation. If the issue is found to be exploitable, we will keep you in touch with our plans to release any fixes for that issue. Please ensure that you supply a valid email address with your report, so that we can discuss the issue with you or request further details as needed.

When an issue report is received, it is treated with the highest priority, and we aim to contact you at the earliest possible opportunity. Note that responses may take longer at weekends or during national holidays, or at particularly busy times.

 

Responsible disclosure

When a researcher or research team discovers an issue in our products or services, we ask them not to disclose this to others (except in the case of using an information security communication agency to provide translations), but instead to disclose it confidentially to us. We ask to be given the time necessary so that the issue can be investigated, a fix can be prepared, and the fix can be delivered to our users in a stable software release, in order to protect users from abuse. After we (and any other affected vendors) have released a stable fix to users, the researcher may then announce their research and discovery, if they wish. This is known as responsible disclosure.

We aim to fix reported issues in a timely manner. The exact amount of time needed may vary depending on the cause and complexity of the issue, and whether other vendors are also affected. We will keep you in touch with our progress, and let you know our plans as soon as we can. A disclosure date will be agreed on a case-by-case basis.

Vivaldi Technologies is registered in Norway, and Norwegian law follows EU GDPR regulations, which relates to private data on our servers. In cases where private data on our servers is compromised, we may be required by those regulations to disclose some details of a breach before we have been able to prepare and release a fix. In these cases, we ask that researchers continue to keep the details confidential until the fix has been prepared and released.

 

How we credit security researchers

We offer researchers written credit in our Hall Of Fame in exchange for responsibly disclosing issues in our software to us. Researchers are normally offered credit by name, using the name of the researcher that discovers and reports the issue to us, optionally also with the research team name if there is one. If the issue affects a product that is delivered to users, the changelog will normally also mention the issue, and credit the researcher in the same way.

If multiple researchers all independently discover the same issue and responsibly disclose it to us before it has been fixed, then we would normally only be able to credit the first researcher. However, we may credit each researcher in cases where they have made significant individual effort that warrants a separate reward. If we suspect that independent researchers have revealed the details of the issue to each other so that they each may try to gain credit, then we will normally not credit any researcher, since this would not be responsible disclosure.

 

When other vendors have similar issues

If we discover that products made by other vendors also have similar issues, we may suggest that the researcher contacts those other vendors, or we may contact the other vendors on their behalf if they have not already been contacted. Vendors will normally coordinate the release of their fixes when this happens.

If an issue affects multiple vendors independently, we will normally wait for all vendors to have delivered their own stable fixes before announcing our own fix and crediting the researcher. Web browser vendors typically operate in this way to ensure that the users of all products are protected before disclosure.

 

Open source projects

Several of our browser products use parts of open source projects like Chromium. If an issue affects that open source project, it may also affect Vivaldi. In these cases, we encourage researchers to report it to the open source project directly, so that it can be fixed by members of that project, and the researcher can be correctly credited. External projects like Chromium can offer researcher credit for issues that are discovered in that project. We can only offer researcher credit for issues that are discovered in software that we produce ourselves. If you are unsure whether an issue affects parts of the software produced by us or an external project, or whether our software has an unrelated but similar issue to the external project, please report it to us, so that we can investigate.

Issues in an open source project will be dealt with by that project according to their own policies, and you should contact them for further details if needed. Any fixes will be inherited by our products when they are released by the open source project.

 

AI and LLM generated reports

We will not accept unverified „AI“ (LLM) generated reports. Please do not use „AI“ or „LLM“ services to try to detect potential vulnerabilities. Please do not use „AI“ or „LLM“ services to prepare text for issue reports. Please do not submit these reports, as they waste development time on diagnosing non-existent issues, and „AI“ hallucinations. We will not reward any such reports, and the reports will be closed without sending any replies. Even in the extremely rare cases where we detect an issue as a result of an „AI“ generated report, we will not offer any reward to the person who submits the report, and we will close the report without sending a reply. All reports need to have been diagnosed and reviewed by an actual human, and the text of the report needs to have been prepared by a human. See Wikipedia’s page about „AI slop„, the cURL announcement, Seth Larsen’s statement, and the TechCrunch article for further information about the issues that „AI“ generated security reports create.