Now and then, a Vivaldi user will start wondering which services Vivaldi connects to.
They will run a network activity scanner and discover that it automatically connects to online services by both Vivaldi and Google.
Occasionally, this will alarm the privacy-conscious user and we’ll get a report describing what the user has observed.
Some users will jump to the conclusion that Vivaldi is spying on their activities and “phoning home” to Google with the details. After all, there are other browsers that actively monitor what their users are doing, sending details back to the browser vendor.
More often than not, it will simply be a case of not getting reliable monitoring results (scroll to the end of the article for advice on how to get accurate results).
While Vivaldi shares its engine with Chrome and downloads some feature and security components from Google, the details of your browsing remain private – hidden from Vivaldi and other service providers. Vivaldi does not collect details or statistics of your browsing activity, period. In fact, unlike many other browsers, Vivaldi does not even have information about the features you use within the browser.
This article explains what each of the handful of services we connect to does, and why it’s needed. It lists the information each service requires for the browser to run smoothly and for you to stay secure.
Vivaldi requests to Google
Downloading components
Several features in Vivaldi depend on separately maintained and updated components provided by the Chromium/Google teams. These components are listed in this special page: vivaldi://components. The downloaded components provide extra functionality that is not practical to provide in the main source code, usually because they might need updates out of step with the normal browser update cycle.
The most important ones are the security-related Certificate Assistant and the CRLset components, as well as the Widevine component that allows you to watch DRM-protected videos online (e.g. Netflix).
These components are downloaded and installed shortly after Vivaldi is started for the first time. Vivaldi will automatically check for updates to these components.
The initial request for these downloads goes to the servers update.googleapis.com and clients2.google.com, but the actual downloads may be from/via other servers such as redirector.gvt1.com and r3---sn-8xouxav-vnas.gvt1.com.
| Cookies | None |
| Control | ComponentUpdatesEnabled policy in vivaldi://policy |
| Network annotation | https://cs.chromium.org/chromium/src/components/update_client/net/network_impl.cc?l=24&rcl=17b2adf184fb218b6096a359b8a06a92be6d22d7 |
SafeBrowsing data
The SafeBrowsing functionality is used to protect you against accessing web sites that, for example, provide dangerous downloads. This functionality is based on a blacklist maintained by Google, and Vivaldi will download updates for the basic list several times a day from the safebrowsing.google.com server.
Previously SafeBrowsing used a technique called a Bloom filter, but they have since changed to a simpler system.
The current system works by creating a “hash” (a cryptographic checksum) of the URL (also parts of the URL) you are about to visit. This hash cannot be easily reversed to reveal the original text used to calculate it, and it is possible that multiple texts result in the same hash (but finding those is also very hard which is the whole point of the checksum). It uses a short portion of the calculated hashes to search the basic list to see if there may be a blacklist entry for any of the partials of the URL. If there is such an indication, a request is sent for each of the matching partials, and the server responds with a list of all the full-length hashes that match any of the prefixes.
If any of those full hashes are a match with any of the calculated hashes, then the URL you were about to visit gets blocked because it is very likely a bad URL.
As only a part of the hash of the URL (or URL-part) is ever sent to the SafeBrowsing server, the service will not know which URL you were visiting, or which, if any, of the full hashes matched.
| Cookies | Some modes permit cookies, but from an isolated cookie store, not shared with other sites |
| Control | chrome://settings/syncSetup |
| Network annotation | https://cs.chromium.org/chromium/src/chrome/browser/safe_browsing/client_side_model_loader.cc?l=125&rcl=2b5ee7a019262c57d80b2740925a5226abe97bb4 |
| Options disabled by default | Upload URL when in doubt |
| Control | “Make searches and browsing better” option in chrome://settings/syncSetup |
| Network annotation | https://cs.chromium.org/chromium/src/components/safe_browsing/realtime/url_lookup_service.cc?l=54 |
Download protection
When you download, for example, an installer for Windows, this might be a software product that could be dangerous to your computer, e.g. a trojan or other malware. In order to protect as many users as possible from such dangers, the SafeBrowsing code in Chromium and Vivaldi checks for dangerous URLs and whitelisted downloads. If it cannot determine the reputation of the downloaded file locally, it sends some detailed information to the SafeBrowsing server, which includes the URL, referrer, hashes for the file itself, and any code signing information, and gets a return verdict about whether the file is reasonably safe, or could be dangerous.
Unfortunately, it is very difficult to determine the reputation of a file without all this information because malware purveyors can change the actual signatures of download URLs as well as the actual downloads, but usually, have to keep some other parts the same. There have been actual attacks that bypassed the protection before the URL and referrers were added to the data.
This system is also used by Mozilla Firefox.
| Cookies | Permitted, from SafeBrowsing’s isolated cookie store (for counting unique users) |
| Control | SafeBrowsing’s setting in Chrome://settings/syncSetup |
| Network annotation | https://cs.chromium.org/chromium/src/chrome/browser/safe_browsing/download_protection/check_client_download_request_base.cc?l=568&rcl=17b2adf184fb218b6096a359b8a06a92be6d22d7 |
Spell checker
Vivaldi uses Chromium’s spellchecker. When you type in Vivaldi, this is the function that helps you mind your p’s and q’s. Chromium’s spellchecker downloads a dictionary for local use from Google, starting the download via redirector.gvt1.com.
| Cookies | None |
| Control | chrome://settings/languages |
| Network annotation | https://cs.chromium.org/chromium/src/chrome/browser/spellchecker/spellcheck_hunspell_dictionary.cc?rcl=95bfa1651b4e2e843fa06ead8506e22f178c00f8&l=282 |
Additional activity
The Chromium codebase can, under certain conditions, do network testing to check whether it is behind a “captive portal” such as a public WiFi network portal that requires a login or a EULA acceptance click.
| Cookies | None |
| Control | chrome://settings/languages |
| Network annotation | https://cs.chromium.org/chromium/src/chrome/browser/captive_portal/captive_portal_service.cc?rcl=ee1c95127800309d94e5457d41983d326fda1fcf&l=252 |
Requests to Vivaldi
User count requests
Recently, we decided to change the way we count our users because some people perceive the use of unique IDs as a form of tracking. We’re currently in the process of implementing a new way of counting users that doesn’t require unique IDs.
Before we can remove the unique ID completely, we’ll go through several stages to make sure the new code works as intended and that we can trust the numbers reported by it. For more details, take a look at this article explaining how we count our users.
The Abusive ad-blocker list
Earlier this year we implemented our own support for blocking ads on sites with bad advertising practices, such as misleading ads, or ads that don’t let you leave the site. This functionality is implemented using a list provided by Google. This list is not downloaded directly from Google. Instead, it is hosted on our own servers after we do some simple preprocessing of the list our back-end server downloads from Google. The list is refreshed daily and updated from the server automatically by the browser, and applied to intrusive websites without needing to contact the server each time.
Auto Update checks
Vivaldi for Mac and Windows regularly checks to see if there is an updated version of Vivaldi.
User-initiated activity
Sync
When you activate syncing of your data to Vivaldi’s sync service, you are logged into your account using the login.vivaldi.net server, and syncing is performed by communicating with the bifrost.vivaldi.com server.
Push notifications
When you allow a site (e.g. a news site) to send you notifications, the site installs a small script in your browser that specifies where to obtain the notifications from. There are several service providers for this, and the web site decides which one to use. One of them is Google’s Cloud Messaging (GCM) system, hosted on mtalk.google.com. Relevant internal URLs for this system are:
chrome://settings/content/notifications,chrome://settings/siteDataandvivaldi://gcm-internals.
Installed extensions
Extensions installed by the user may connect to their vendor’s own site to request updates, or report various usage data. This is not something Vivaldi can control. We always recommend that our users choose their extensions carefully and make sure they trust the extension provider/vendor.
Why network activity scanners won’t show you the full picture
Users who run network activity scanners, typically only use a network activity monitor. This does a reverse DNS lookup, resulting in an “arbitrary” host name being displayed.
Services like the Google servers Vivaldi connects to are hosted in big server parks across multiple servers, even multiple geographical locations, and each of these servers has a unique hostname. It is this unique name that is registered in the reverse DNS index for its IP address.
It is highly unlikely that you will get a complete list of servers hosted on a given IP address of major deployments used by Google, Amazon or Microsoft, or that it will include the name of the server the client actually connected to.
The better way to discover which servers the client connects to is to listen to the DNS requests and responses. This will tell you exactly which servers your browser is connecting to.
An even better way to see what is going on is to use the information provided by Vivaldi. Start Vivaldi with the argument --enable-logging=stderr --v=1. This will produce a wall of data, saved to the chrome_debug.log file in the installation’s User Data directory, and among the data reported there are lines with the following text: NetworkDelegate::NotifyBeforeURLRequest:. This reports which URLs are being requested.
To conclude, none of the automatic services will send details or statistics of your browsing activity to Vivaldi or Google.
A big thank you to Varun Khaneja (@vakh) from the Chromium team for reviewing relevant parts of this article.
Photo by Luca Bravo on Unsplash.
* * *
Read more:
Vivaldi: Built using Chromium, but different from Chrome
Vivaldi’s powerful privacy settings
