The first time you start Firefox,
it looks up a surprising number of names, connects to
several domains, and fetches and posts data, all
before you had a chance to enter a URL. Somewhat
surprised by this, I then set out to compare Firefox
to some other Browsers, namely Google
Chrome, Microsoft
Edge and Apple
Safari.

After I first published this blog post, several
people asked about other browsers, so on 2020-03-03, I
added information about Opera and Brave; on 2020-03-13, I
added information about Vivaldi. Below is the
breakdown of my findings.

Setup

All browsers were installed on a macOS Catalina
10.15.3 dual-stack IPv4/IPv6 enabled system and
invoked without any existing user profile (i.e.,
~/Library/Application
Support/<browser> does not exist). The
system was connected to the internet via a residential
ISP (RCN) from New York City (this is relevant since
some of the default connections made or other behavior
in the browser may be based on your location). IPv6
connectivity was provided via a Hurricane Electric
IPv6 Tunnel.

The SSLKEYLOGFILE
environment variable was set so as to allow
capturing of the TLS session keys for use with Wireshark to be able
to inspect the HTTP calls. (This works for Firefox,
Chrome, and other Chrome-based browsers (i.e., Edge),
but not for Safari.) Most other user applications were
terminated or suspended; various system daemons were
also suspended, so as to minimize unrelated network
traffic.

Once tcpdump(1) was running, the browser
was opened. After any initial browser screens, we
opened a new tab, entered www.netmeister.org
in the location bar, and hit enter. After the website
was loaded, the browser was closed completely and the
packet capture stopped.

After starting Mozilla Firefox 73.0.1 for the first
time, I notice that it performs a significant number
of DNS queries via the default resolver. That is,
this instance of the browser does not yet appear to
have DoH enabled by default. It then loads a welcome
page, allowing the user to "Join Firefox", while
loading the Firefox
Privacy Notice in a second tab:

After closing this pane, you get a second "Welcome
to Firefox" display, offering you the opportunity to
sign in to some of Firefox's services:

After closing that pane, you then get the
default "new tab" experience, offering a Google search
bar, a few "Top Sites", and a number of "Recommended
Reading" tiles:

At this point, I enter www.netmeister.org
in the location bar and hit return, then close the
browser after the page has loaded. Upon termination
of the Firefox process, a pingsender
process is started, which sends
telemetry to Mozilla upon browser shutdown (one
you've started Firefox, you can disable this via
about:config->toolkit.telemetry.shutdownPingSender.enabled):

DNS Lookups

Firefox performed a total of 106 queries
for 65 distinct names; the queries were A and
AAAA lookups only, usually (but not always)
both for a given name and were via to the locally
configured stub resolver. That is, even though
Mozilla began rolling out DNS over HTTPS, this
host and browser were not in the
bucket for which this is currently enabled.
Firefox also did
not look up the DoH Canary
Domain as that domain is only used when the user
is opted into DoH via the default.

The list of DNS queries performed varies from time
to time, likely based on the getpocket widget
in the welcome screen. It's also worth noting that
not all of the names looked up are actually contacted;
this is part of the DNS pre-fetching enabled
in Firefox (see this
link and this
link for more details; in about:config,
you can toggle network.dns.disablePrefetch to
true to disable this behavior).

The total list of DNS lookups done on a fresh new
start by Firefox was, in order:

Of those, only www.netmeister.org was a
domain entered by the user. (You may also notice a
number of domains listed above that are e.g., AWS
systems that the original name already references
via a CNAME result. In this case, the
response to the initial lookup included the A
records in its ADDITIONAL SECTION, but did
not provide any AAAA records (because e.g.,
AWS is primarily IPv4 only). As a result, a second,
explicit AAAA query is made.)

HTTP Traffic

When you start a browser, you may naively assume
that the first HTTP traffic exchanged would occur
after you entered a URL and hit return. However, we
notice the following substantial exchanges other than
the ones for the requested website take place,
roughly (some requests to the same service have been
grouped together) in order:

GET /v1/buckets/main/collections/ms-language-packs/records/cfr-v1-en-US
GET /v1/
GET /v1/buckets/monitor/collections/changes/records?collection=cfr&bucket=main
GET /v1/buckets/main/collections/cfr?_expected=1582570728505
GET /v1/buckets/main/collections/cfr/records?_expected=1582570728505&_sort=-last_modified
GET /v1/buckets/monitor/collections/changes/records?collection=message-groups&bucket=main
GET /v1/buckets/monitor/collections/changes/records?collection=whats-new-panel&bucket=main
GET /v1/buckets/main/collections/whats-new-panel?_expected=1582304242703
GET /v1/buckets/main/collections/whats-new-panel/records?_expected=1582304242703&_sort=-last_modified

Result:

no results

(I'm not quite clear on why the last requests were
never replied to by the server. The pcap
file only shows a bunch of ACKs following the
various GET requests, but never an HTTP reply
before the connection is terminated.)

GET /social-tracking-protection-facebook-digest256/73.0/1578954954
GET /except-flashallow-digest256/1490633678
GET /allow-flashallow-digest256/1490633678
GET /social-tracking-protection-linkedin-digest256/73.0/1578954954
GET /analytics-track-digest256/73.0/1581379643
GET /except-flash-digest256/1494877265
GET /except-flashsubdoc-digest256/1517935265
GET /mozstd-trackwhite-digest256/73.0/1582074377
GET /block-flashsubdoc-digest256/1512160865
GET /base-fingerprinting-track-digest256/73.0/1581379643
GET /social-track-digest256/73.0/1581543360
GET /social-tracking-protection-twitter-digest256/73.0/1578954954
GET /content-track-digest256/73.0/1578954954
GET /block-flash-digest256/1496263270
GET /base-cryptomining-track-digest256/73.0/1578954954
GET /mozplugin-block-digest256/1471849627
GET /ads-track-digest256/73.0/1581543360

Summary

During this first invocation, Firefox makes HTTP
connections to 10 different IPs. These IPs are in 5
different AS operated by 3 different companies
(Akamai, Amazon, Cloudflare) using 5 different
2nd-level domains:

The user does not appear to be given an option to
prevent the sending of the telemetry data or to have
the various widgets before they are loaded. Once the
browser has started, a knowledgeable user may change
some of the preferences or settings to disable these
features.

Unlike for Firefox, all domains looked up do
include both A and AAAA records
(directly, or via the ADDITIONAL SECTION in
the CNAME result).

The list of names looked up included at least three
random character sequences (vprmudr,
hklhckmpbugndd, and ncortvjulifhod,
each then attempted with my ISPs default search domain
cable.rcn.com) in what looks like an attempt
to determine whether the local ISP performs
NXDOMAINhijacking;
see this
discussion for details.

HTTP Traffic

At startup, Chrome makes a number of HTTP calls, as
broken down below:

GET /service/update2/crx?os=mac&arch=x64&os_arch=x86_64&nacl_arch=x86-64&prod=chromecrx&prodchannel=&prodversion=80.0.3987.122&lang=en-US&acceptformat=crx3&x=id%3Dfckonodhlfjlkndmedanenhgdnbopbmh%26v%3D0.0.0.0%26installedby%3Dpolicy%26uc%26brand%3DGCEA%26ping%3Dr%253D-1%2526e%253D1&x=id%3Dhdokiejnpimakedhajhdlcegeplioahd%26v%3D0.0.0.0%26installedby%3Dpolicy%26uc%26brand%3DGCEA%26ping%3Dr%253D-1%2526e%253D1&x=id%3Dnmmhkkegccagdldgiimedpiccmgmieda%26v%3D0.0.0.0%26installedby%3Dother%26uc%26brand%3DGCEA%26ping%3Dr%253D-1%2526e%253D1&x=id%3Dpkedcjkdefgpdelpbcmbmeomcjbeemfm%26v%3D0.0.0.0%26installedby%3Dother%26uc%26brand%3DGCEA%26ping%3Dr%253D-1%2526e%253D1&x=id%3Daapocclcgogkmnckokdopfmhonfmgoek%26v%3D0.0.0.0%26installedby%3Dinternal%26uc%26brand%3DGCEA%26ping%3Dr%253D-1%2526e%253D1&x=id%3Dfelcaaldnbdncclmgdcncolpebgiejap%26v%3D0.0.0.0%26installedby%3Dinternal%26uc%26brand%3DGCEA%26ping%3Dr%253D-1%2526e%253D1&x=id%3Dghbmnnjooekpmoecnnnilnnbdlolhkhi%26v%3D0.0.0.0%26installedby%3Dinternal%26uc%26brand%3DGCEA%26ping%3Dr%253D-1%2526e%253D1&x=id%3Daohghmighlieiainnegkcijnfilokake%26v%3D0.0.0.0%26installedby%3Dinternal%26uc%26brand%3DGCEA%26ping%3Dr%253D-1%2526e%253D1&x=id%3Dapdfllckaahabafndbhieahigkjlhalf%26v%3D0.0.0.0%26installedby%3Dinternal%26uc%26brand%3DGCEA%26ping%3Dr%253D-1%2526e%253D1&x=id%3Dblpcfgokakmgnkcojhhkbfbldkacnbeo%26v%3D0.0.0.0%26installedby%3Dinternal%26uc%26brand%3DGCEA%26ping%3Dr%253D-1%2526e%253D1&x=id%3Dpjkljhegncpnkpknbcohdijeoejaedia%26v%3D0.0.0.0%26installedby%3Dinternal%26uc%26brand%3DGCEA%26ping%3Dr%253D-1%2526e%253D1

GET /crx/blobs/QgAAAC6zw0qH2DJtnXe8Z7rUJP1q2vfaFufYPJ7MMPEdkxYurQqLKfsqlETBqnGAQLjVuUqXAP5kzjisGuCNTfqCtcNWXHJuTNrtTwTfHV02dRyiAMZSmuXqm5VWwl1zMmIqqfa62Kc5n3rCxg/extension_0_10_0_0.crx
GET /crx/blobs/QgAAAC6zw0qH2DJtnXe8Z7rUJP0PBKVA-da_-T21yR2UQUNKDZNldfzJCCheccCxyc0eUdDcCzD3ksljCA37sYE2YQuixwb_lBQCF7WBqfrrMonZAMZSmuWOasTHxYEehcxrMknyH19pG5TAFg/extension_0_10_0_0.crx
GET /crx/blobs/QgAAAC6zw0qH2DJtnXe8Z7rUJP199BPyTfUTqlzrFainq_xpziexr6SSBQsG3al6SBOxXjhz6mtW75j-F1xkh0sFvlhqvkI3ro_fhpbYGWlt8yIvAMZSmuUbWgSmyx0vin-zLiRBVV3QIcVxrQ/extension_14_2_0_0.crx
GET /crx/blobs/QgAAAC6zw0qH2DJtnXe8Z7rUJP34GdSPM8CJTB4XCoKDlT3eZoUVQ66lPGkI7tJP3yA8iyZlYPMFkFE3rtpsNUquY08htcd-DWwPeCsE33hz642FAMZSmuX_x3TLW5Bs8_F8kxawtOpjwV_QwQ/extension_3_1_40_0.crx
GET /crx/blobs/QgAAAC6zw0qH2DJtnXe8Z7rUJP1q2vfaFufYPJ7MMPEdkxYurQqLKfsqlETBqnGAQLjVuUqXAP5kzjisGuCNTfqCtcNWXHJuTNrtTwTfHV02dRyiAMZSmuXqm5VWwl1zMmIqqfa62Kc5n3rCxg/extension_0_10_0_0.crx
GET /crx/blobs/QgAAAC6zw0qH2DJtnXe8Z7rUJP0w4lDJ_bL6-4cEiO2dNd4wY6MRtrB86olYdAWJNSpbQk1Q83A9EM8DbPrtbQ_AZGp0O9Rp13bGeg_IlBP8lMjLAMZSmuXJMLTQge2ehP4yzENeXXd5OSiVew/extension_8_2_0_0.crx
GET /crx/blobs/QwAAAHF3InbmK-wFIemaY3I3BCOlBIvoDMAma8GvG4TlJV63hrc-qX-TqF8hD5aOTImPGuQQq6BujLIzdacuWTEqILccAS18tmDS6pfwab4-elsoAMZSmuX3wxOtQqAilonYeas4_oS69Ej8Jg/extension_4_42_0_2.crx

Result:

a lot of data of Content-Type: application/x-chrome-extension (presumably updates to installed extensions)

GET /gossip?output=fxjson&command=www.n
GET /gossip?output=fxjson&command=www.netm
GET /gossip?output=fxjson&command=www.netmeist
GET /gossip?output=fxjson&command=www.netmeiste
GET /gossip?output=fxjson&command=www.netmeister.o

Result:

incremental predictive results

Here we see the search autocomplete functionality
of the location bar: as you enter the URL, your
partial URL is sent to the default search engine
little by little to allow for the autocomplete window
to provide you with guesses.

What's interesting here is that the default
provider is Yahoo. I had removed all previous
preferences and started from scratch, but somewhere
Chrome picked up my previous default?

Secondly, the search happens over plain HTTP, not
HTTPS! This is due to Chrome having the predictive
search URL hardcoded
as HTTP. I've opened a ticket to see whether a
change request should be submitted to Chrome to switch
this over to HTTPS, which ff.search.yahoo.com
does support.

Once Chrome has started, you can disable the
autocomplete search function via
chrome://settings/syncSetup?search=autocomplete.

GET /edgedl/chromewebstore/L2Nocm9tZV9leHRlbnNpb24vYmxvYnMvOTRmQUFXVHlhaGJaUTdMLWtCSkNJUl9ZQQ/1.0.0.5_nmmhkkegccagdldgiimedpiccmgmieda.crx
GET /edgedl/chromewebstore/L2Nocm9tZV9leHRlbnNpb24vYmxvYnMvMjk4QUFXWHV4aEtlX19peUJMaUFXd3dUZw/8019.1111.0.0_pkedcjkdefgpdelpbcmbmeomcjbeemfm.crx

GET /edgedl/chromewebstore/L2Nocm9tZV9leHRlbnNpb24vYmxvYnMvMjk4QUFXWHV4aEtlX19peUJMaUFXd3dUZw/8019.1111.0.0_pkedcjkdefgpdelpbcmbmeomcjbeemfm.crx?cms_redirect=yes&mip=2001:470:1f07:1d1:7c01:fc76:30b9:4ae7&mm=28&mn=sn-ab5szn7z&ms=nvh&mt=1582903761&mv=m&mvi=4&pl=47&shardbypass=yes

Result:

No HTTP response, although I see a lot of TCP packets being exchanged?

This is an odd exchange: the GET request
appears not to be answered with an HTTP response,
although a number of TCP packets are being sent back.
Making the same request via curl(1) yields
another redirect to
http://r4---sn-ab5l6nzk.gvt1.com, which then
returns an HTTP 200 with binary data with
Content-Type:
application/x-chrome-extension.

This is likely due to my system profile enforcing
the installation of certain Chrome extensions, and
thus perhaps not an accurate reflection of what a
plain vanilla install or setup would look like.

GET /safebrowsing/csd/client_model_v5_variation_0.pb
GET /safebrowsing/csd/client_model_v5_ext_variation_0.pb

Result:

80K of Content-Type: application/octet-stream

Other Traffic

SSDP

When Chrome starts, it sends out an SSDPM-SEARCH * packet to the IPv4 site-local
multicast address 239.255.255.250, port
1900. This is presumably to help in the
discovery of e.g., cloud printers or
other local devices.

A local system may respond with an HTTP response
including a Location header, indicating a
URL to fetch content from. In my case, my local Tivo
helpfully replied, and Chrome then went to fetch the
file http://172.16.1.6:37176/dd.xml.

(See this
issue for more information. There's also this
entertaining blog post relating to SSDP. Related
config flag: chrome://flags/#media-router.)

mDNS

Similarly to SSDP, Chrome also sends out an mDNS
broadcast to 224.0.0.251 and
ff02::fb with a query for a
_googlecast._tcp.localPTR record.
Local devies such as, e.g., a Google Nest Hub, respond
with an IP address and additional information about
the device, and Chrome may then perform an HTTP
GET request e.g., for Expert Info
/ssdp/device-desc.xml, which returns a product
description.

(I'm also seeing at least two packets speaking the
AJP13
protocol being exchanged, but can't make much sense of
them; I'm not feeling particularly warm and fuzzy
about that being in use on my devices, however.)

Summary

During this first invocation, Chrome makes HTTP
connections to external systems on 8 different IPs,
all IPv6. These IPs are in 2 different AS operated by
2 different companies (Google and Yahoo) in 6
different 2nd-level domains:

It is worth noting that if the default search
engine had not been Yahoo, but Google, then
all of the traffic would have gone to
Google's systems only. It is also worth noting that
all of Google's systems used IPv6, TLS 1.3,
and HTTP2.

Edge is now a Chrome based browser, so we expect
at least some similarities with Google Chrome. Let's
see if that's true or how much Microsoft changed
here.

When installing Edge, the installer offers you an
option to choose whether to "help microsoft improve
our products by sending crash reports, info about how
you use the browser, and websites you visit" to
Microsoft, linking to this
webpage. This is a nice touch, as it allows you
to opt out of data collection even before the first
start of the browser! In this example, I chose to opt
out.

After starting Microsoft Edge 80.0.361.57 for the
first time, it displays a startup site:

Here, you can choose to import Chrome settings or
sign into your profile or whatnot. Let's not. After
opting out, you then get a generic welcome page:

DNS Lookups

Edge performed a total of 102 queries for
46 distinct names; the queries were A and AAAA lookups
only and were via to the locally configured stub
resolver.

The total list of DNS lookups done on a fresh new
start by Edge was, in order:

As before with Google Chrome, we see a number of
lookups of random character sequences to detect DNS
hijacking; we also see consecutive lookups of records
as we type our destination name,
www.netmeister.org.

GET /edge/ntp?locale=en-US&fre=1&rt=1&dsp=1&sp=Bing&startpage=1
GET /content/view/v1/weathersummary/en-us/40.74,-73.9855?units=F&days=5
GET /breakingnews/v1/cms/api/amp/article/AA157JY
GET /service/msn/topics?apikey=0QfOX3Vn51YCzitbLaRkTTBadtWpgTN8NZLW0C1SEM&activityId=AADBF64E-E4FA-4BAA-8500-0FBE111C0ECC&ocid=anaheim-dhp-feeds&market=en-us&user=m-1F7801155A8F68020D0C0F6B5B0D6994&fdhead=msnallexpusers,muidflt10cf,muidflt26cf,muidflt50cf,muidflt313cf,complianceedge1cf,samrtb-n,platagyhp2cf,moneyhp1cf,compliancehp1cf,starthz1cf,samrtbflex-nc,artgly3cf,gallery2cf,jslltelemetry,msnapp4cf,1s-feed-next-v1&queryType=MyFeed&$top=1000&allTopics=true&$select=id,name,image,feedType&location=40.74|-73.9855

GET /config/v1/Edge/80.0.361.57?agents=EdgeDomainActions%2CEdgeFirstRun%2CEdgeFirstRunConfig%2CEdgeDataConfig&enabledomainactions=1&osname=mac&channel=stable&osver=10.15.3&osarch=x86_64&uma=0&mngd=0
GET /config/v1/Edge/80.0.361.57?enabledomainactions=1&osname=mac&channel=stable&osver=10.15.3&osarch=x86_64&uma=0&mngd=0

GET /v1/a/click?PG=IRIS000001.0000000216&UNID=88000216&CID=128000000001812729&PID=425122465&TargetID=700336220&REQASID=&ASID=0823319A7CDB414F99B3E4ABFCF120DA&REQT=20200228T234550&UIT=M&ID=00000000000000000000000000000

Other Traffic

SSDP and mDNS

Since Edge is based on Chrome, it's no surprise we
see the same SSDP and mDNS traffic as we saw
above.

Summary

During this first invocation, Edge makes HTTP
connections to external systems on 14 different IPs,
almost all IPv4. These IPs are in 6 different AS operated by
3 different companies (Microsoft, Akamai, MCI) in 5
different 2nd-level domains:

Safari is a bit of an outlier in this analysis: it
is more closely integrated with the OS, starts a few
other processes, and has access to a shared DNS cache
via mDNSResponder.

It also is the only browser that I did not start in
a factory-new configuration; instead, I started with
the default of a blank page, thereby avoiding loading
a heavy advertising driven homepage or anything of
that sort. The reason for this is that I simply could
not easily untangle Safari from whatever system
settings I have as defaults to recreate or simulate a
fresh install.

What's more, unlike with Firefox or Chrome based
browsers, Safari does not honor the
SSLKEYLOGFILE environment variable, meaning I
can't decrypt the TLS traffic easily in Wireshark
without setting up a proxy, a trouble through which I
didn't bother going. Therefor, I can only provide the
correlation of IP addresses to which Safari made a TLS
connection with the SNI from the TLS handshake and the
Little Snitch network map and connection information,
but not provide the details of the data
exchanged.

The version of Safari used here is 13.0.5
(15608.5.11).

DNS Lookups

Safari performed a total of 43 queries for
26 distinct names; the queries were A and AAAA lookups
only and were via to the locally configured stub
resolver.

There were some lookups that appeared to have been
made as follow ups to previously cached results. For
example, no DNS query for www.bing.com was
observed in the pcap file, but a query for
the resolution of its CNAME
(a-0001.a-afdentry.net.trafficmanager.net.)
was observed. This appears to be the effect of mDNSResponder
caching DNS lookups.

The total list of DNS lookups done on a fresh new
start by Safari was, in order:

Other Traffic

Summary

During this first invocation, Safari makes HTTP
connections to external systems on 19 different IPs,
most IPv6. These IPs are in 12 different AS operated
by 10 different companies (Akamai, Apple, Facebook,
Google, LinkedIn, MCI, Microsoft, Twitter, Wikimedia,
Yahoo) in 12 different 2nd-level domains:

What's interesting about Safari is that even though
it doesn't load a welcome page or display any content
at startup as per my preferences, it still fetches
content from the various popular domains, suggesting
there is some pre-fetching to content happening in the
background.

Braveservicekey: qjVKcxtUybh8WpKNoQ7EbgbkJTMu7omjDHKk=VrPApb8PwJyPE9eqchxedTsMEWg
GET /autofill/hourly/bins.json
GET /autofill/weekly/merchants.json
GET /safebrowsing/csd/client_model_v5_variation_0.pb
GET /safebrowsing/csd/client_model_v5_ext_variation_0.pb

GET /promo/custom-headers
PUT /promo/initialize/nonua
GET /1/usage/brave-core?platform=osx-bc*amp;channel=release*amp;version=1.4.95*amp;daily=true*amp;weekly=true*amp;monthly=true*amp;first=true*amp;woi=2020-03-02*amp;ref=BRV001

GET /release/gccbbckogglekeggclmmekihdgdpdgoe/extension_1_0_21.crx
GET /release/cffkpbalmllkdoenhmdmpbkajipdjfam/extension_1_0_498.crx
GET /release/afalakplffnnnlkncjhbmahjfjhmlkal/extension_1_0_22.crx
GET /release/oofiananboodjbbmdelgdommihjbkfag/extension_1_0_14.crx

Result:

Content-Type: application/x-chrome-extension

Summary

During this first invocation, Brave makes HTTP
connections to external systems on 3 different IPs.
These IPs are in 2 different AS operated by 2
different companies (Cloudflare, Fastly) with domains
in a single 2nd-level domain:

For Opera, things were split into two processes to
track: the installer, and the browser invocation
itself, which immediately and automatically followed
the installation. Once the installer completed and
opened the browser window (version 67.0.3575.53), a
default startup page was loaded:

After that, we enter our destination URL, let the page
load, and exit the browser.

DNS Lookups

Opera (and its installer) performed a total of
74 queries for 29 distinct names; the queries
were A and AAAA lookups as well as one PTR
lookup and were via to the locally configured stub
resolver.

The total list of DNS lookups done on a fresh new
installation of Opera was, in order:

GET /api/v2/partner-content?product=*amp;country=US*amp;edition=*amp;uuid=900cb00e-d350-4aed-a74e-d4c08ec47567
GET /api/v2/suggestions?product=*amp;country=US*amp;language=en-US*amp;uuid=0d1ac479-1b16-412e-86dc-118fcdede04c*amp;type=desktop-suggestions
GET /api/v2/suggestions?product=*amp;country=US*amp;language=en-US*amp;uuid=0d1ac479-1b16-412e-86dc-118fcdede04c*amp;type=desktop-suggestions
GET /api/v3/news?country=us*amp;language=en*amp;locale=en_US*amp;category=ar,bu,en,fo,ga,he,li,lv,mo,ne,sc,sp,te,tr*amp;timezone=-05:00
GET /api/v1/features?country=US*amp;language=en-US*amp;uuid=a036c8a3-4076-4918-853f-dd9650893333
GET /api/v1/thumbnails/www.netmeister.org

GET /api/omaha/update/?os=mac*amp;arch=x64*amp;os_arch=x86_64*amp;nacl_arch=x86-64*amp;prod=chromiumcrx*amp;prodchannel=Stable*amp;prodversion=80.0.3987.122*amp;lang=en-US*amp;acceptformat=crx3*amp;x=id%3Dcom.opera.crx.blacklist%26v%3D0%26uc
GET /api/omaha/blacklist.aa8c9c6d317f343a4c2e1b80f132be89058411264919eb57947037b57467cf9f.txt

Another case of some sort of authentication token
baked into the client.

Summary

During this first invocation, Opera makes HTTP
connections to external systems on 9 different IPs.
These IPs are in 5 different AS operated by 5
different companies (Akamai, Amazon, Google, Opera
(NO), and Opera (US)) with domains
in four different 2nd-level domains:

Vivaldi 2.11.1811.47 is another Chromium based
browser that was tested based on popular demand.

The packet capture was started before opening the
application for the first time after downloading it;
we are prompted to confirm that we want to install the
browser, then eventually displays a welcome screen,
where we can skip the tour to end up on the home
screen:

In the background, Vivaldi opens a second tab with
the "What's New" page:

DNS Lookups

Vivaldi performed a total of 52 queries
for 24 distinct names; the queries were for A and AAAA
lookups only and were via the locally configured stub
resolver.

The total list of DNS lookups done on a fresh new
start by Vivaldi was, in order:

GET /service/update2/crx?os=mac&arch=x64&os_arch=x86_64&nacl_arch=x86-64&prod=chromiumcrx&prodchannel=&prodversion=80.0.3987.136&lang=en-US&acceptformat=crx3&x=id%3Dpkedcjkdefgpdelpbcmbmeomcjbeemfm%26v%3D0.0.0.0%26installedby%3Dother%26uc%26ping%3Dr%253D-1%2526e%253D1

GET /edgedl/chromewebstore/L2Nocm9tZV9leHRlbnNpb24vYmxvYnMvMjk4QUFXWHV4aEtlX19peUJMaUFXd3dUZw/8019.1111.0.0_pkedcjkdefgpdelpbcmbmeomcjbeemfm.crx

Result:

Redirect to http://r1---sn-ab5sznly.gvt1.com/edgedl/chromewebstore/L2Nocm9tZV9leHRlbnNpb24vYmxvYnMvMjk4QUFXWHV4aEtlX19peUJMaUFXd3dUZw/8019.1111.0.0_pkedcjkdefgpdelpbcmbmeomcjbeemfm.crx?cms_redirect=yes&mh=uP&mip=2001:470:1f07:1d1:c0fc:4ab4:ec31:5694&mm=28&mn=sn-ab5sznly&ms=nvh&mt=1584117640&mv=u&mvi=0&pl=47&shardbypass=yes

GET /edgedl/chromewebstore/L2Nocm9tZV9leHRlbnNpb24vYmxvYnMvMjk4QUFXWHV4aEtlX19peUJMaUFXd3dUZw/8019.1111.0.0_pkedcjkdefgpdelpbcmbmeomcjbeemfm.crx?cms_redirect=yes&mh=uP&mip=2001:470:1f07:1d1:c0fc:4ab4:ec31:5694&mm=28&mn=sn-ab5sznly&ms=nvh&mt=1584117640&mv=u&mvi=0&pl=47&shardbypass=yes

GET /newfeatures?hl=en-US&version=2.11.1811.47&os=M
GET /browser/whats-new-in-vivaldi-2-11
GET /whats-new-in-vivaldi-2-11/
GET /wp-includes/css/dist/block-library/style.min.css?ver=5.3.2
GET /wp-content/themes/vivaldicom-theme/style.css?ver=1582721612
GET /wp-content/themes/vivaldicom-theme/fonts/font-awesome/font-awesome.min.css?ver=1539179228
GET /wp-includes/js/jquery/jquery.js?ver=1.12.4-wp
GET /wp-includes/js/jquery/jquery-migrate.min.js?ver=1.4.1
GET /cdn-cgi/scripts/5c5dd728/cloudflare-static/email-decode.min.js
GET /wp-content/plugins/page-links-to/dist/new-tab.js?ver=3.2.2
GET /wp-content/themes/vivaldicom-theme/img/vivaldilogo-standard.png
GET /logme.gif
GET /wp-content/uploads/vivaldi.2.11.pip-hero_b.jpg
GET /wp-content/uploads/2.11-PiP_Screenshot_Final.png
GET /wp-content/uploads/2.11_OS-themes_Screenshot_Final.png
GET /wp-content/uploads/keyboard-shortcut-tabs_loop.gif
GET /wp-content/themes/vivaldicom-theme/img/social_twitter.png
GET /wp-content/themes/vivaldicom-theme/img/social_facebook.png
GET /wp-content/themes/vivaldicom-theme/img/social_reddit.png
GET /wp-content/themes/vivaldicom-theme/img/social_email.png
GET /wp-content/themes/vivaldicom-theme/img/icons/mail.png
GET /wp-content/themes/vivaldicom-theme/img/icons/vivaldi-red.svg
GET /wp-content/themes/vivaldicom-theme/img/android/icon-vivaldi-beta.png
GET /rep/rep?action_name=What%E2%80%99s%20New%20in%20Vivaldi%202.11%20%7C%20Vivaldi%20Browser&idsite=4&rec=1&r=463671&h=12&m=48&s=43&url=https%3A%2F%2Fvivaldi.com%2Fwhats-new-in-vivaldi-2-11%2F&_id=1657ef4941f57060&_idts=1584118123&_idvc=1&_idn=0&_refts=0&_viewts=1584118123&send_image=1&pdf=1&qt=0&realp=0&wma=0&dir=0&fla=0&java=0&gears=0&ag=0&cookie=1&res=1440x900&gt_ms=679&pv_id=lqmvek
GET /favicon.ico

Result:

Redirect to /browser/whats-new-in-vivaldi-2-11
Redirect to https://vivaldi.com/whats-new-in-vivaldi-2-11/

GET /safebrowsing/csd/client_model_v5_variation_0.pb
GET /safebrowsing/csd/client_model_v5_ext_variation_0.pb

Result:

80K of Content-Type: application/octet-stream

Other Traffic

SSDP and mDNS

Since Edge is based on Chrome, it's no surprise we
see the same SSDP and mDNS traffic as we saw
above.

Summary

During the first invocation, Vivaldi makes HTTP
connections to external systems on 6 different IPs in
4 different AS operated by 4 different companies
(Google, Highwinds Network Group, Virgin Media,
Cloudflare) in 4 different 2nd-level domains:

Well, there you have it. When you start a browser
and visit a single page, you're not connecting to
just that page. All of the major browsers make a
number of calls to their provider for updates, as well
as to third parties, but they differ in how widespread
those connections are:

Browser

# of unique names looked up via DNS

# of services contacted via HTTP

amount of data downloaded

amount of data uploaded

Mozilla Firefox 73.0.1

65

10 (in 5 different 2nd-level domains)

9.54 MB

171 kB

Google Chrome 80.0.3987.122

19

9 (in 6 different 2nd-level domains)

7.21 MB

20.3 kB

Microsoft Edge 80.0.361.57

46

15 (in 5 different 2nd-level domains)

10.8 MB

382 kB

Safari 13.0.5 (15608.5.11)

26

19 (in 12 different 2nd-level domains)

560 kB

24.5 kB

Brave 1.4.95 (Chromium 80.0.3987.122)

19

6 (in a single 2nd-level domain)

8.4 MB

38.9 kB

Opera 67.0.3575.53

29

12 (in 4 different 2nd-level domains)

5.05 MB

75.1 kB

Vivaldi 2.11.1811.47

24

8 (in 4 different 2nd-level domains)

9.84 MB

50.7 kB

A few additional things that I think stand out:

Firefox makes a surprising number of connections
and lookups

Chrome has the fewest connections and keeps data
within the company

HTTP2 and TLS 1.3 are now widely used for the main
sites; IPv6 is still not ubiquitous

Chrome is the only browser that makes
all calls via IPv6, TLS 1.3, and HTTP2
only

there is basically no plain HTTP; almost all
observed traffic was HTTPS

by and large, we only use two or three different
TLS ciphers (Wikimedia was the only one to deviate by
offering ECDSA with ChaCha20/Poly1305;
all others were RSA/GCM
(for TLS 1.2) or TLS_AES_128_GCM_SHA256 (for
TLS 1.3)); considering how many different ciphers most
servers offer, we are arriving at a perhaps surprising
monoculture of ciphers

Safari is hard to untangle from the OS, taking
advantage of several helper apps

Firefox is the only browser left to make OCSP
calls (about:config#ocsp); Safari appears to
outsource this to trustd, while Chrome (and
by extension, Edge) simply have OCSP lookups disabled

The other thing worth pointing out here is that
from a network perspective, we're looking at
significant centralization of our resources: companies
use the same registrar and almost all connections were
made to primarily the same handful of (CDN) networks
(Akamai, Amazon, Google).

With the advent of DNS over HTTPS, I plan on
revisiting the default connectivity from a DNS point
of view with different configurations (default DNS,
use of the canary domain (for Firefox), use of
Google's DNS, ...). But of course that won't have any
impact on where the browsers make their HTTP calls to,
and I think that is something that's not been
paid much attention to in this debate.