The following review was conducted by Sampson, Senior Developer Relations Specialist at Brave.

When a Web browser first launches, it typically goes through an initial setup phase where various resources are requested, downloaded, configured, and more. You can learn quite a bit about a browser from observing the requests it makes in its first moments with a new user profile. Often, a cursory examination will tell you a great deal about how the browser thinks about, and handles, user privacy and security.

In the past we at Brave have taken a look at desktop and iOS browsers, to see what they do in the first moments of being launched with a fresh user profile. It’s important to us that we keep a close eye on Brave in particular. Similar efforts have been conducted by others, such as the 2020 work of Douglas Leith, which will be referenced throughout this review.

This effort compared the first-run experiences of five popular browsers: Brave, Chrome, Firefox, Edge, and Opera. Each of these readings were conducted on an updated Windows 10 (Version 20H2, Build 19042.804) desktop computer, with an authenticated Microsoft account.

Methodology

Each analysis was preceded by the clearing of any pre-existing profile data from the device by removing browser-specific files from Windows’ %appdata% and %localappdata% directories. All browsers were confirmed to be up to date. Telerik Fiddler (v5.0.20204.45441) was then used to capture network requests for 10 minutes per browser.

Aside from launching the application, no user-interactions took place for the first 5 minutes. After this time only necessary interactions were made to arrive at a usable New Tab Page. Any offer to enable the collection of data, personalization, syncing, etc., was denied and/or dismissed.

Once the New Tab Page had been reached, the browser was left alone for 4 minutes. At the 9th minute of testing, “brave” (an example of a potential search term) was typed into the address bar, and subsequently deleted character by character. “Password” was then pasted into the address bar, and deleted in like manner. This was to determine whether user data, including data pasted by mistake, would be emitted from the browser to a remote service.

Following a 10 minute session, the browser was then closed and launched for a second time after a brief moment. On the second launch, the browser was left alone for 2 minutes before it was subsequently closed again. This second launch enables us to identify any difference in behavior between an initial launch, and those that follow.

At times this review links to source code for various browsers. This is done to better understand certain observed behaviors. Source for Brave is available at code.brave.com, Chrome at cs.chromium.org, and Firefox at searchfox.org. While Edge provides partial-source archives through thirdpartysource.microsoft.com, these are large and difficult to utilize. Opera does not publish its source code for the public.

Summary

In Leith’s 2020 review, he concluded that “the browsers split into three distinct groups… In the first (most private) group lies Brave, in the second Chrome, Firefox and Safari and in the third (least private) group lie Edge and Yandex.” While Safari and Yandex were not included in this review, and Opera was not included in Leith’s analysis, I feel the results otherwise remain consistent with Leith’s earlier findings.

Brave had the fewest network requests, and to the fewest number of hosts. All of Brave’s connections were to a Brave endpoint. Firefox had the highest number of requests, although most were security-related, and to Mozilla endpoints. Firefox also had what may be the most aggressive telemetry collection. Microsoft’s Edge had the earliest, and most active third-party advertising strategy. Edge also demonstrated how much information about a user is within reach of the browser by virtue of using a Windows Account.

Chrome, like Edge, attempts to identify the user as early as possible. Chrome also transmits larger keystroke/pasted-content payloads than the other browsers. All browsers, with the exception of Brave, transmitted keystrokes and pasted content to a remote search engine (Firefox waited for 2 characters of input before transmission). Opera stood out for making calls to the highest number of third-parties, and also for its divergent approach to integrity-checking navigation attempts (i.e. sending every URL to sitecheck.opera.com).

Results

Brave v1.21.73

Brave’s requests fell into a few different categories. First were security-related requests, such as the retrieval of a set of ad-and-tracker-blocking rules, the HTTPS Everywhere component, 2 certificate revocation lists, a list of known-unsafe or potentially dangerous URLs and resources from the proxied SafeBrowsing service (using the Update API), and a set of OS-specific rules specifying which browser plugins (e.g. Adobe Flash, Chrome PDF Viewer) can be safely used.

The next category of requests were those that represent various features of Brave. First in the list was a set of custom headers, which serve in lieu of a custom user-agent string (Brave uses Chrome’s user-agent string). Brave documents these on GitHub. At the time of this analysis, there were 2 headers used for custom content on eaff.com, and layout/design changes on uphold.com. Also in the features category, Brave downloaded a rule-set for its emerging SpeedReader functionality.

Next we saw a request to download Brave’s “variations”. These control field trials, or experiments, which may be running in the browser. Brave uses these to deploy small, safe A/B tests to a subset of its 25+ million users.

The last feature item downloaded was the Sponsored Images campaign for the user’s region (i.e. their country). Not all regions have active Sponsored Image campaigns, so some users may not see this download. The package consisted of 2 small JSON files, and a few image files, and did not include any user data or identifiers. These resources are displayed on every fourth new tab for participating users in supported regions.

Once Brave completed its initial setup, it requested update status for various components. Some of these were downloaded and installed moments before, while others are packaged within the browser itself.

The last category is telemetry and reporting. An update ping, which Brave uses to anonymously quantify its user base, was observed. And lastly, a short series of P3A requests, or Privacy-Preserving Product Analytics, which help Brave Software understand how the browser is used and where it can be improved.

What connections did Brave make?

Brave issued 70 network requests to 10 distinct hosts, all subdomains of brave.com.

What information did Brave access and/or share?

Personal and Potentially Sensitive Information

No personal information was included in any of Brave’s requests. Instead, what this review saw being transmitted to the *.brave.com endpoints was the browser “channel” (e.g. stable, beta, nightly), browser version, any referral code that may have been used, and a few pieces of information about the device itself, such as operating system and version, amount of memory, and the user’s language.

Telemetry Data

Brave’s update ping (or Stats Updater) sent a few bits of information (i.e. platform, browser channel, and browser version). In order to calculate the size of Brave’s user-base and measure retention, these requests also included four boolean (true/false) values indicating whether this was a first launch for Brave, and if the browser has been used daily, weekly, and/or monthly. As part of Brave’s previous referral program, content creators and publishers were rewarded when a user they referred had used the browser for 30 days. To measure this retention, Brave also sent 2 date values: week of install (e.g. 2021-01-4) and date of install (e.g. 2021-01-08). No user data or identifiers were included in this request. An adsEnabled boolean shared whether or not the instance was participating in Brave Ads; the value was false.

Next, Brave made 5 requests to p3a.brave.com as part of Brave’s privacy-preserving telemetry. These requests carried a small amount of base64-encoded data with a few values contained within (e.g. platform, browser version). No identifiers or user information was present in these requests. P3A is further-documented at github.com/brave/brave-browser/wiki/P3A.

Transmission of Keystrokes and Pasted Content

At the end of this session, “brave” was typed into the address bar. The input was then deleted, one character at a time. Lastly, “password” was pasted into the address bar, and subsequently deleted in like manner. These actions resulted in no additional network requests being made, and therefore no potentially-sensitive data being unintentionally transmitted to an outside party.

Brave’s Second Launch

Brave’s second request issued 24 requests (excluding redirects and DNS-hijacking detection tests). Brave’s second launch did not reveal any new requests. Instead, we saw a request for any relevant variations, the retrieval of Brave’s custom headers, update-checks for installed components and extensions, one P3A call, and a call to safebrowsing.brave.com to retrieve any new potentially-harmful URLs since the previous launch.

Chrome v89.0.4389.72

One of the first requests Chrome made was to their Google Accounts and ID Administration service, or GAIA. This request attempts to associate the user with an existing Google account.

Next, a request was made to Chrome’s own variations endpoint, similar to Brave. Chrome uses this server for field trials as well, enabling them to test features and more before deploying a feature or change to a broader audience.

Chrome then proceeded to download a set of default extensions. Most of these are small, convenience-based extensions. Rather than package up a great deal of logic, instead they serve as links and shortcuts to popular Web apps like Docs, Sheets, Presentation, and more. Others establish shortcuts to YouTube, Gmail, Drive and the Chrome Web Store. Many are visible when you navigate to chrome://apps within the browser. Various other internal components were checked for updates as well, as was the case with Brave.

Chrome proceeded to request a list of known-malicious or otherwise potentially harmful domains from the SafeBrowsing service. In addition to this, Chrome loaded the same list of trusted plugins that was observed in Brave’s traffic.

Once Chrome was ready to display its New Tab Page, it requested any existing promotional messages, doodle meta-data, the Google apps widget, and a JSON file which hosts HTML and more representing bits and pieces of the New Tab Page. The New Tab Page was then constructed on the fly, which is unique among the browsers tested.

What connections did Chrome make?

Chrome issued 91 network requests to 5 distinct top-level domains, all of which belong to Google.

ogs.google.com requested a cookie be set

What information did Chrome access and/or share?

Personal and Potentially Sensitive Information

Chrome was not observed to successfully access and/or share any personal or sensitive information. At the start of this analysis however, an attempt was made by Chrome to locate an existing GAIA account for the user (see Why I’m done with Chrome, by Matthew Green). This failed, however, presumably because this is a first-run on a Windows machine. Leith found a request to accounts.google.com/ServiceLogin during his 2020 review, which also included a ‘device_id’—no such request or value was observed during this analysis.

Note: When considering differences between Leith’s review, and this effort, it is important to note the timing and environmental differences. Leith’s review was published in February of 2020, roughly one year prior to this review. Furthermore, Leith’s review was conducted on macOS, whereas this effort used Windows 10.

Shortly after Chrome’s default extensions and components were installed, the Google Docs Offline Extension issued a request to docs.google.com/offline/extension/report, sharing the extensions version (1.26.0) and an “optin” status, which was unknown.Like Brave, Chrome also transmitted general device and instance information, such as the operating system and version, amount of onboard memory, the user’s preferred language, as well as which channel and version of Chrome has been installed. This information is crucial to delivering the proper extensions and/or components to the end user.

When requesting meta-data for doodles (the artistic variants of the Google logo), Chrome harmlessly informed Google that the data was intended for the New Tab Page.

Transmission of Keystrokes and Pasted Content

Chrome was observed to transmit all keystrokes to google.com/complete/search when “brave” was typed into, and deleted from, the address bar. The same was observed when “password” was pasted and subsequently removed from the address bar as well.

As each character was typed into the address bar, Chrome sent this input (‘q’) to Google. Each request contained at least 7 (and up to 14) pieces of data. Most of these values were unrelated to the user and/or their query. Chrome identified the type of device being used (‘gs_ri’), where in the app/UI these requests originated (‘client’), whether to include a cross-site script inclusion preamble in the response (‘xssi’), the cursor’s current position (‘cp’), which version of search to use (‘gs_rn’), a 12-byte, base64-encoded, 60-second session token (‘psi’), classification of the current page (‘pgcl’), and an API key (‘sugkey’).

Chrome also sent over an omnibox input type (‘oit’), that is, the type of input provided by the user. 0 marks empty input, and was observed when clicking on the address bar, or focusing it with Ctrl+L (using the tab key to focus the address bar did not result in a network request). 1 marks unknown input, meaning it is valid but has no discernable type. While other input types exist, this analysis only observed instances of 0 and 1. Chrome also issued the same requests during the insertion and deletion of pasted input.

Lastly, when the Google apps New Tab Page widget was requested from ogs.google.com, the server returned a 180-byte cookie: NID={3 numbers}={171 characters}. This cookie was sent to google.com during each of the user-input requests.

Chrome’s Second Launch

Chrome’s second launch did not introduce any new requests. Similar to the first launch, Chrome again attempted to locate a user account via accounts.google.com/ListAccounts. This attempt returned no user data, as expected. Chrome then requested updates for doodles, and other new tab content. Requests to accounts.google.com, www.google.com, apis.google.com, and ogs.google.com all included the same cookie created during the first launch.

Firefox v86

The first requests Firefox made were to its portal-detection endpoint. Similar to Chrome, Brave and Edge’s requests to detect DNS hijacking, Firefox attempts to reach a remote success.txt file. If found, and its contents are “success”, Firefox knows that it is able to access the Internet. Firefox issued 21 requests to this endpoint in all. 7 of the requests had no query string, while 7 others had a ?ipv4 query string. The final 7 had a ?ipv6 query string.

Similar to other browsers tested so far, Firefox issues requests to harden its security. Unlike other browsers however, Firefox made thousands of requests in this process, which isn’t necessarily a bad thing. One of the first requests was to Mozilla’s Shavar service, which returned a set of tracking-protection and other security-related list names. The Shavar service mapped these names into a list of resource URLs which were subsequently requested.

Firefox established a WebSocket connection to Mozilla’s AutoPush server during the first run; this connection is used by web applications to deliver messages to users even when the web app is not opened or being accessed. Firefox then sends a “hello” handshake message to the server, and receives a Push User Agent Registration ID (UAID) in response. A second message is transmitted, one of “broadcast_subscribe” which received a timestamp in response.

Soon after were requests to Normandy, Firefox’s recipe server. Similar to the variations servers of Chrome and Brave, Normandy enables Firefox to deliver small experiments, studies, and more by enabling preferences for small sets of users.

When Firefox first launched, it did so with two tabs. One was the typical New Tab Page, and the second was Firefox’s Privacy Notice. Because the latter is hosted on the Web, this analysis saw 22 additional requests and roughly 450 KB of data downloaded.

What connections did Firefox make?

Firefox issued 2,799 network requests to 8 top-level domains. Most of these domains are owned and/or maintained by Mozilla.

What information did Firefox access and/or share?

Personal and Potentially Sensitive Information

Near the end of the profiling session, Firefox called out to Mozilla’s client-classification endpoint. The response contained a country code (“US”), and a granular timestamp for this request. This request was observed one other time during the review. Earlier responses contained similar information, but likely inferred it from the device’s public IP address.

Telemetry Data

Telemetry data typically included an event type (e.g. impression, button click, session end), event context, the user’s locale (e.g. ‘en-US’), the version and channel of Firefox being used, as well as a client id and a browser session id. In all, 9 telemetry requests were made. There were two distinct types of requests issued: messaging-system and telemetry.

The messaging-system payloads were the smallest, and recorded events such as impressions, button clicks, and the end of a session. Among the data carried were a browser session ID, a client ID, and an event context. The event context recorded more granular details about the event represented. For example, when a user clicks a button during the onboarding process, the event context object shares which button and on which page. For impressions, the event context was observed to include the page name, and various metrics. When a session ends, the event context object includes a reason (.e.g. address-bar-navigated) along with the last URL. These payloads often included a list of experiments for which the user and device have been enrolled (e.g. “bug-1648229-rollout-comcast-steering-rollout-release-78-80”).

Three requests of type telemetry occurred towards the end of this analysis. Each of these requests were issued by a separate process, pingsender.exe. They will be examined more closely in the next section.

pingsender.exe

Firefox delegates much of its telemetry reporting to an entirely different process called pingsender. This process was observed to submit telemetry data while Firefox was open and in use, as well as after the browser had been closed. In all, 2 instances of pingsender were observed making a total of 3 requests. The request types observed were new profile, event, and first-shutdown.

After the 10 minute review, when Firefox was closed, pingsender.exe issued 3 more telemetry requests. The telemetry calls emitting from the firefox.exe process were on average about 1.3 KB; by contrast, the first telemetry request from pingsender was roughly 6.5 times larger. This request included quite a bit of data: a 36-character Client ID, device architecture, Firefox’s date-based Build ID, version, channel, a list of active addons, plugins, and which theme was in use, a short list of experiments for which the device and user have been enrolled, a set of nulled-out attribution fields for a partner distributing the application, and the dates on which Firefox was installed and first used (represented as total number of days since January 1, 1970), and whether or not it was configured as the default browser.

A granular description of the device was also included in this payload: an Apple Model ID (if any), details about the CPU (e.g. cores, extensions, family, L3 and L2 cache, model number, speed, vendor), graphics card and display settings (e.g. name of graphics card, full on-disk address to drivers, driver dates, vendor, version, whether or not the GPU is active, amount of on-board memory, current state of D2D and DWrite, a granular set of feature flags, connected displays (how many, resolutions, refresh rates), hard drives (e.g. model names, type), operating system (e.g. name, date of install, locale, version, granular windows build number), security software (e.g. names of anti-spyware, antivirus, and firewalls in use), and more.

One of the more interesting observations about this Telemetry payload is the presence of a key called environment.settings.telemetryEnabled, which was set to false. Presumably this would mean no such telemetry calls would be made, which clearly was not the case.

The last payload, at 90 KB in size, contained “first-shutdown” data, including a verbose list of histograms, how long the browser had been running (in seconds), a timezone offset, sessionId, and many metrics measuring various events and processes within the browser. While most of this is not personal in any way, it is incredibly granular. And having it all sent, as a single payload even, is a bit uncomfortable.

Transmission of Keystrokes and Pasted Content

When typing input into the address bar, Firefox waited until there were at least 2 characters of input before sending the input to Google. Firefox’s queries included only a client-attribution string (“firefox” in this case), and the query itself.

Note: While Firefox also immediately transmitted the pasted input, Leith found no such transmission during his review. It is worth noting that Leith’s pasted input consisted of a URL (i.e. http://leith.ie/nothingtosee.html). Firefox appears to only transmit non-URL input.

Firefox’s Second Launch

Firefox’s second launch introduced new requests. As was the case with the first launch, the initial requests are to Firefox’s portal-detection endpoint. 6 such requests were made; two with no query string, two with ?ipv4, and the final two with ?ipv6. The next request was to location.services.mozilla.com, which returned the user’s country code and name.

This launch introduced endpoints getpocket.cdn.mozilla.net, and spocs.getpocket.com. Mozilla acquired Read It Later, Inc., the developers of Pocket, in 2017. So it should come as no surprise that they are eager to introduce users to the service.

During the second launch, Firefox appears to have generated a unique ID for the user. This ID was referred to as “pocket_id” (referred to elsewhere in source as impressionId). Once generated, this value was stored in the user’s preferences, where it will presumably persist indefinitely and unchanged.

This short, second, session concluded with 4 telemetry requests: 2 from the firefox process, and 2 from the pingsender process. The structure and contents of these requests were similar to those observed in the first session (i.e. a Client ID, Session ID, Experiment IDs, etc.). Curiously, these requests also indicated (via environment.settings.telemetryEnabled being false) that this device and instance had telemetry disabled.

Edge v88.0.705.81

Edge used 2 processes (both instances of msedge.exe) during this analysis; one of which communicated exclusively with security-related SmartScreen endpoints. The other process handled the download and setup phase of a typical first-run experience.

Edge requests fall into a few distinct categories; the first is user content and data retrieval. When Edge was launched, it attempted to gather details about the user. On Windows, it may ultimately be able to learn quite a bit. More on that below, under What Information Did Edge Access and/or Share?

The second category of requests in Edge’s traffic are those pertaining to security and/or privacy. Domain-specific rules and instructions were retrieved which held special rules for various Web properties the user may encounter while navigating. These instructions inform Edge which plugins are safe to expose to particular websites, whether or not the browser should conceal or modify its user-agent string for those sites, and more. SmartScreen requests fall into this category as well, as they help to prevent the user from navigating to known-malicious URLs and/or downloading malware.

Benign content requests make up the third category. Edge’s New Tab Page was loaded remotely from ntp.msn.com, and resulted in numerous requests for various page assets. By and large, these requests are what you would expect to see: images, fonts, scripts, and stylesheets.

While all of the browsers included in this review have access to information regarding the user’s device and region, Edge reaches remote data associated with the user’s Windows account. For many, this can yield a very detailed, personal association as we’ll discuss further below.

The fourth category of Edge’s traffic falls into the advertising and tracking space. Edge appeared to engage in tracking and advertising more aggressively, and earlier, than any other browser tested. In this category, we saw data sent to third-parties, real-time bidding indicators, and potential redirection-based tracking, which is commonly used by those wishing to circumvent cross-origin security policies in browsers.

What connections did Edge make?

Edge issued 367 network requests to 13 top-level domains. Most of these domains are owned by Microsoft. Potentially sensitive data was commonly shared across these properties, including by methods often used to evade cross-origin security and privacy protections.

Several Set-Cookie Requests Encountered

What information did Edge access and/or share?

Personal and Potentially Sensitive Information

During this analysis, it was evident that Edge not only had access to, but would ultimately retrieve, more sensitive information than any other browser tested. During the setup screen, the device owner’s image and email address were retrieved and displayed.

Requests were observed sending encoded user-credentials (belonging to the authenticated Windows user) to remote endpoints, retrieving various types of data in return. One request to bing.com/fd/auth/signin yielded a set of cookies containing IDs (some of which were shared in later requests), and even the device owner’s first name. Another request to substrate.office.com returned even more information, including the device owner’s full name (first, middle, and last), age (including year, month, and day of birth), location, email address, and gender.

Edge’s SmartScreen integration occasionally transferred information about the user, their device, and web traffic for security and privacy purposes. When these requests occurred, they at times included the user’s locale (en-US in this case), the browser version and configuration, information about the operating system, and more. Other device details were shared as well, such as the device battery and network status.

A request to ntp.msn.com resulted in an HTML response with encoded JSON data as a “data-info” attribute. When decoded, this data included the user’s language, country, subdivision (in this case, which US State), zipcode, city, and coordinates (which were 22 miles, or 35 km away from the device’s actual location).

Note: In his 2020 review, Leith reported seeing an early “troubling” request which included his Apple device’s immutable UUID. He stated “This identifier is unique to the device and never changes, thus it provides a strong, enduring user identifier.” No such request, or identifier, was observed during this analysis from a Windows 10 device.

In spite of opting out of Sync when setting up the new profile, Edge locates and accesses various types of data belonging to the user. During the portion of this review where a search phrase is typed into the address bar, Edge suggested historical inputs belonging to the Windows user. Once the network traffic was analyzed, it was clear that this information originated from bing.com/profile/history/data. To request this data, Edge transmitted various cookies identifiers as well as a lengthy and encoded x-rps-token header.

Cross-Origin Redirects

There’s a unique set of requests made by Edge which weren’t seen in other browsers; these include indicators of real-time bidding, and possible redirect-based tracking. For example, data was observed being passed via URL parameters between c.bing.com and c.msn.com during an image request.

When the New Tab Page requested c.msn.com/c.gif, it sent with the payload numerous bits of information. While not entirely clear what all of the data represented, this analysis observed timestamps, first run indicators, a screen resolution, locale data, and more.

When c.msn.com received the request and data, it immediately responded by redirecting the browser to c.bing.com/c.gif, with more values in tow (i.e. ctsa, CtsSyncId, RedC, and MXFR). The “MXFR” key contained msn.com’s “MUID” cookie value. c.bing.com, now having received the additional data, redirected the browser back to c.msn.com/c.gif. During this response, bing.com set 3 new cookies (i.e. MUID, SRM_B, and SRM_M), each with the value observed in msn.com’s “MUID” cookie. c.msn.com returned a 1×1 GIF to conclude the redirects.

Requests to c.clarity.ms/c.gif were also observed to bounce data back and forth with c.bing.com/c.gif. Like msn.com, Clarity generated a CtsSyncId, and MXFR (which was then set as a cookie on clarity.ms), and passed this information to c.bing.com/c.gif. Bing then returned the request with it’s own MUID value (itself a copy of msn.com’s MUID).

Ads and Tracking

Requests were observed being made to sb.scorecardresearch.com, a service which (according to their site) “conducts research by collecting Internet web browsing data and then uses that data to help show how people use the Internet, what they like about it, and what they don’t.” By merely launching Edge, the user and their device are now participating in this collection of data by a third party. ScorecardResearch appears on numerous popular ad and tracker blocking lists.

Note: ScorecardResearch is blocked by default for users of Brave, uBlock Origin, and other popular content-blocking extensions. For all other users, an opt-out page exists at scorecardresearch.com/optout.aspx?newlanguage=1. ScorecardResearch’s opt-out feature relies on third-party cookies.

The initial request to sb.scorecardresearch.com/b received 2 cookies (i.e. UID and UIDR) and a redirect to /b2. When the redirect happened, a “cs_ak_ss” key with a value of 1 was introduced  and attached to the query-string parameter list. It is not clear what this data represents.

Numerous requests were issued to arc.msn.com, recording various “placement” events. For example, one of the first requests was to report the “Built with your privacy and security in mind” ad had been displayed. Included in this request was a placement ID, the operating system, version number, preferred UI theme, the user’s language, country, and a few more pieces of information.

The “arc” server responded with a set of tracking instructions, including URLs that should be pinged when an action involving the placement has occurred. Moments later a request was made indicating a click event had taken place, followed by another request stating a conversion had happened. Each of these requests transmitted 37 pieces of information to ris.api.iris.microsoft.com via the query-string.

Telemetry Data

Like the other browsers, Edge aims to collect telemetry data during its first run experience. A Device ID (consisting of 36 alpha-numeric characters) was observed being assigned to the device traffic. This ID was referred to elsewhere as MicrosoftApplicationsTelemetryDeviceID and Install ID, and was randomly generated (therefore not based on personal or device information) by a script on the New Tab Page. Quite a few GUIDs and other long identifiers were observed in Edge’s traffic; enough that it would merit a much closer and more rigorous analysis to more fully understand the degree to which data is tied to a user, their device, or their Windows account.

Towards the end of the analysis, numerous requests were made to clarity.ms. Each of these posted quite a bit of information, however the structure of the data makes it difficult to know what information was being collected.

Telemetry and other reporting data were sent to, and/or associated with domains arc.msn.com, browser.events.data.msn.com, edge.activity.windows.com, config.edge.skype.com, browser.pipe.aria.microsoft.com, target.microsoft.com, web.vortex.data.microsoft.com, and clarity.ms.

When the browser was closed and exited a PageUnload event transmitted the app ID, an impression GUID, how long (in milliseconds) the last page had been opened, the height (in pixels) of the page document, how far down the page the user scrolled, and more. Prior to this, another event was fired for a button-click action. This event transferred similar data, including flags to indicate whether cookies were enabled, if the click was manual, if the user was logged-in (to the browser/OS?), how much time had passed before the button had been clicked, etc.

Transmission of Keystrokes and Pasted Content

Edge was observed to transmit keystrokes and pasted content to bing.com/qbox. Each request to bing.com included 8 query string parameters, and 8 cookies (474 bytes of information), including one which contained the device owner’s name along with a 16-character identifier.

Edge’s Second Launch

Edge’s second launch was one of the more verbose among the set with 70 requests being made. The types of requests didn’t appear to differ much from the first launch, however. Requests were still issued for ScorecardResearch, data bounced between requests for c.gif, and more.

Opera v88.0.4324.182

When Opera launched, it was directed at redir.opera.com, an endpoint responsible for handling a redirect. During this time, Opera issued 2 requests to sitecheck.opera.com. These request bodies were compressed in the protobuf format, and were therefore not easily parsed. What was clear was a distinct URL in both request bodies. In both cases, a request is made to that URL moments later. Sitecheck is Opera’s “SafeBrowsing” alternative, which examines requests and decides if they can safely be fulfilled or not. A third request happened later, following the same pattern.

After issuing a request for limited regional information, Opera requested regional partner and “merchandise” information, along with a list of features IDs, which are likely used similarly to the variations and field trials in the browsers reviewed above.

Midway through the analysys, Opera issued 3 requests to exchange.opera.com. Specifically, they were exchange.opera.com/api/v1/cmc/, /api/v1/ecb/, and /api/v1/nbu/. These requests are likely related to Opera’s built-in currency conversion, and/or their built-in crypto wallet.

Opera then proceeded to issue various app/extension-related requests, including an extension-blacklist resource, and a request for Opera’s Rich Hints Agent. A request to addons.opera.com moments later served to verify the contents of the Rich Hints Agent extension.

Opera issued 3 requests to android.clients.google.com. This was quite surprising, since the tests were carried out on a Windows 10 desktop computer. These requests will be explored further below, in What Information Does Opera Access and/or Share?

Towards the end of the session, Opera performed an update-check, an authenticated request to desktop-dna.osp.opera.software/v1/dna, and issued 5 requests to download3.operacdn.com. These requests retrieved site-specific scripts and user-agent string overrides, further Rich Hints information, preference overrides, and lastly a set of rules for linking certain browsing activity to various partnerships.

What connections did Opera make?

In all, Opera issued 106 requests to 30 top-level domains, 17 of which were owned and/or administered by Opera Software.

analytics.twitter.com requested a cookie be created

What information did Opera access and/or share?

Personal and Potentially Sensitive Information

Opera’s first call was to redir.opera.com, and contained information (derived from the installer) explaining how the user came to acquire the browser. The information included a download ID (this download was assigned an ID value of just over 52,500), a campaign name, the last URL visited, from which domain the installer was downloaded, a UUID called “niuid”, and even the URL which referred the user. With this data posted to Opera’s server, the browser initiated a request for www.opera.com/firstrun/.

One of Opera’s first calls was to autoupdate.geo.opera.com/geolocation/ which returned the user’s country. This user’s country code then appeared in 2 calls to speeddials.opera.com. The first of the 2 calls was to api/v2/partner-content, and included the user’s country and a UUID (a 36-character identifier). The response contained a list of partners to be enumerated within the bookmarks bar and New Tab Page.

The second request included the country as well, but also the user’s primary locale/language (e.g. en-US). This request also contained a UUID, although its value was different from the first. Moments later a third call (api/v2/suggestions) was observed. This call transmitted the user’s language, locale, and the unchanged UUID from the previous call.

Opera issued a request to weather.opera-api.com, but didn’t include the user’s location. Instead, only the user’s language was provided, while Oslo was provided as the default location.

Device details needed for the delivery of extension updates (e.g. platform, operating system and version, amount of memory) were transferred across a few requests.

Opera’s Sitecheck service determines whether URLs are safe to visit or not. Similar to Google’s SafeBrowsing Lookup API, Opera sends every URL requested to sitecheck.opera.com. The service then indicates whether the navigation should continue. This practice is uncommon, as we have observed in the reviews above. Instead, Brave, Chrome, and Firefox all use the Update API of Google’s SafeBrowsing service (Edge uses Defender SmartScreen). This approach routinely downloads an updated list of known-malicious URLs for client-side checking, thus avoiding the need to send every URL requested to a remote service for examination.

In addition to Sitecheck, URLs are also sent to speeddials.opera.com/api/v1/thumbnails/ to retrieve a representative image for the domain. As an example, navigating to brave.com would issue a request for speeddials.opera.com/api/v1/thumbnails/brave.com, where the domain is added to the path of the service endpoint.

Telemetry Data

Connections were made from the Welcome Page to Google Analytics, Twitter, and HotJar endpoints. Google Analytics received a payload containing 22 pieces of information, including what appeared to be device/user identifiers, resolution and browser-window sizes, locale information, display color depth, and more. Most of the data was difficult to discern. Immediately following this analytics request, stats.g.doubleclick.net and google.com/ads/ga-audiences were sent similar payloads, both with roughly 12 pieces of information each.

Twitter (via t.co, analytics.twitter.com and ads-twitter.com) was sent 3 requests. The first was for a “pageview” event, and included the URL of the Welcome page as well as a transaction ID. Other fields existed to hold the user’s Twitter ID, a Sale Amount, Order Quantity, and iframe status. These fields were all empty. The second request was nearly identical and resulted in a new “personalization_id” cookie set to expire one year into the future.

While requests to hotjar.com were observed in the analysis, these appeared to be limited to resource requests. No payloads containing user data were observed. The hotjar resource names did contain unique identifiers, one of which was likely a Site ID belonging to the Opera page from which these resources were requested. The second identifier was found in a request to vars.hotjar.com/box-469c…57a4.html. This identifier did not appear to be unique to the request, device, or user in any way.

Midway through Opera’s first launch, a request for desktop-dna.osp.opera.software was issued. Opera transmitted a username and password, encoded as base64, to the endpoint and received a set of descriptions regarding the instance and user: active, sessionTracking, veteran, lowABsearches, noSPsearches, lowSearches, noOrganicSearches, lowAttributedSearches, noPageviews, midSessionDuration, organic, fsOrganic, workUser, homeUser, activatedByAssistant, noSPsearches30days, searchboxEnabled, speedDialsEnabled, noPartnerSD30days, noPersonalSD30days, weeklyUser, lowABsearches30days, Yandex_share_0, user4_5days, DesktopUser_last7days.

Device Registration

During the analysis, three requests were made to android.clients.google.com. This seemed quite odd, since the browser was running on a Windows 10 desktop, and not an Android device. The first request was to /checkin, and contained two distinct values: a timestamp, and a lengthy identifier. The response contained “android_id”, “chrome_device”, “device_country”, and “device_registration_time” values. More data was contained within the response, but it is unclear what that additional data represents.

The “android_id” value from the initial request was posted back to android.clients.google.com in the next 2 requests to /c2dm/register3. These requests stood out, since they appear to be for Google’s Cloud to Device Messaging service, which was deprecated in 2012 and “shut down completely” in 2015. That said, these endpoints appear to work, surprisingly. Lacking more context, it is assumed that these calls are intentional, and enable Opera to send push notifications to client devices when time-sensitive information and other updates are available.

Transmission of Keystrokes and Pasted Content

By default, Opera sends address-bar keystrokes and pasted content to Google for real-time search results. These requests include an identifier which attributes the traffic to Opera, the user’s input, and two additional parameters, ie and oe, which specify the input and output encoding as UTF-8.

Opera’s Second Launch

Opera’s second launch was quite concise, coming in at only 16 requests. The browser started by requesting the user’s country again, checking for extension updates, asking for an updated set of feature IDs from features.opera-api.com, and polling the aforementioned exchanges for fresh currency and cryptocurrency information.

Opera’s second launch did introduce a new request to get.geo.opera.com, for a Big Blue Wide component. This endpoint served a “rich hint” module in a transparent webview on top of the browser itself.