1Web Browser Privacy: What Do Browsers Say
When They Phone Home?
Douglas J. Leith
School of Computer Science & Statistics,
Trinity College Dublin, Ireland
24th Feb 2020∗

Abstract—We measure the connections to backend servers madeby six browsers: Google Chrome, Mozilla Firefox, Apple Safari,Brave Browser, Microsoft Edge and Yandex Browser, during
normal web browsing. Our aim is to assess the privacy risks
associated with this back-end data exchange. We find thatthe browsers split into three distinct groups from this privacy
perspective. In the first (most private) group lies Brave, in thesecond Chrome, Firefox and Safari and in the third (least private)group lie Edge and Yandex.

I. I NTRODUCTION
While web browsing privacy has been much studied, mostof this work has focussed either on (i) measurement of
the web tracking/advertising ecosystem, or (ii) methods for
detecting and blocking trackers. For example, see [1], [2], [3]and references therein. This line of work has also included
consideration of browser private browsing modes, e.g. [4], [5].
However, all of this work typically assumes that the browser
itself is a trustworthy platform, and it is this assumption that
we interrogate here.
Browsers do not operate in a standalone fashion but rather
operate in conjunction with backend infrastucture. For example, most browsers make use of safe browsing services [6] toprotect users from phishing and malware sites. Most browsers
also contact backend servers to check for updates [7], tofaciltate running of field trials (e.g. to test new features before
full rollout), to provide telemetry, and so on [8], [9], [10].
Hence, while users are browsing the web Chrome shares datawith Google servers, Firefox with Mozilla servers etc as partof normal internal browser operation.
Before proceeding, it is worth noting that most popularbrowsers are developed by companies that also provide online
services accessed via a browser. For example, Google, Apple
and Microsoft all provide browsers but also are major suppliersof online services and of course integrate support for these
services into their browsers. Here we try to keep these two
aspects separate and to focus solely on the backend services
accessed during general web browsing.
Our aim is to assess the privacy risks associated with this backend data exchange during general web browsing. Questions wetry to answer include: (i) Does this data allow servers to track∗ Updated 11th March 2020 to include additional information from discus-

sions with Apple and Microsoft.
Updated 19th March 2020 to note that GAPS cookie is no longer set by
Google on first startup of Chrome.

the IP address of a browser instance over time (rough location
can be deduced from an IP address, so IP address tracking ispotentially a surrogate for location tracking) and (ii) Does thebrowser leak details of the web pages visited.
We study six browsers: Google Chrome, Mozilla Firefox,
Apple Safari, Brave Browser, Microsoft Edge and Yandex
Browser. Chrome is by far the most popular browser, followed
by Safari and Firefox. Between them these browsers are used
for the great majority of web access. Brave is a recent privacyorientated browser, Edge is the new Microsoft browser andYandex is popular amongst Russian speakers (second only to
Chrome). Notable omissions include Internet Explorer, since
this is a largely confined to legacy devices, browsers specificto mobile handsets such as the Samsung browser, and the UCbrowser which is popular in Asia.
We define a family of tests that are easily reproducible and canbe applied uniformly across different browsers and collect dataon the network connections that browsers generate in responseto these tests, including the content of the connections. In
these tests we evaluate the data shared: (i) on first startup
of a fresh browser install, (ii) on browser close and restart,(iii) on pasting a URL into the top bar, (iv) on typing a
URL into the top bar and (v) when a browser is sitting
idle. We note that these tests can be automated and used forbrowser privacy benchmarking that tracks changes in browser
behaviour over time as new versions are released. However,analysis of the content of network connections for identifiers
probably cannot be easily automated since it is potentiallyan adversarial situation where statistical learning methods caneasily be defeated.
In summary, based on our measurements we find that thebrowsers split into three distinct groups from this privacy
perspective. In the first (most private) group lies Brave, inthe second Chrome, Firefox and Safari and in the third (least
private) group lie Edge and Yandex.
Used “out of the box” with its default settings Brave is by
far the most private of the browsers studied. We did not findany use of identifiers allowing tracking of IP address overtime, and no sharing of the details of web pages visited withbackend servers.
Chrome, Firefox and Safari all tag requests with identifiers
that are linked to the browser instance (i.e. which persist acrossbrowser restarts but are reset upon a fresh browser install). All
three share details of web pages visited with backend servers.

2This happens via the search autocomplete feature, which sends
web addresses to backend servers in realtime as they are
typed1 . Chrome tags these web addresses with a persistentidentifier that allows them to be linked together. Safari uses
an emphemeral identifier while Firefox sends no identifiers
alongside the web addresses. The search autocomplete functionality can be disabled by users, but in all three browsers issilently enabled by default. Chrome sets a persistent cookie on
first startup that is transmitted to Google upon browser restart2
Firefox includes identifiers in its telemetry transmissions to
Mozilla that are used to link these over time. Telemetry canbe disabled, but again is silently enabled by default. Firefox
also maintains an open websocket for push notifications thatis linked to a unique identifier and so potentially can also
be used for tracking and which cannot be easily disabled.
Safari defaults to a choice of start page that prefetches pages
from multiple third parties (Facebook, Twitter etc, sites notwell known for being privacy friendly) and so potentiallyallows them to load pages containing identifiers into thebrowser cache. Start page aside, Safari otherwise made no
extraneous network connections and transmitted no persistentidentifiers, but allied iCloud processes did make connections
containing identifiers. In summary, Chrome, Firefox and Safari
can all be configured to be more private but this requires user
knowledge (since intrusive settings are silently enabled) andactive intervention to adjust settings.
From a privacy perspective Microsoft Edge and Yandex aremuch more worrisome than the other browsers studied. Bothsend identifiers that are linked to the device hardware and so
persist across fresh browser installs and can also be used tolink different apps running on the same device. Edge sends
the hardware UUID of the device to Microsoft, a strong andenduring identifier than cannot be easily changed or deleted.
Similarly, Yandex transmits a hash of the hardware serial
number and MAC address to back end servers. As far as
we can tell this behaviour cannot be disabled by users. In
addition to the search autocomplete functionality (which canbe disabled by users) that shares details of web pages visited,
both transmit web page information to servers that appear
unrelated to search autocomplete.
The results of this study have prompted discussions, which
are ongoing, of browser changes including allowing users to
opt-out of search auto-complete on first startup plus a numberof browser specific changes. We also note that we consistently
found it much easier to engage with open source browser
developers (Chrome, Firefox, Brave) since: (i) inspection of
the source code allows browser behaviour that is otherwise
undocumented (most functionality setting identifiers etc falls
into this category) to be understood and validated, and (ii) it
is relatively straightforward to make contact with the softwaredevelopers themselves to engage in discussion. Interaction
with Safari developers is confined to a one-way interface (it1 The default settings are for Chrome to send addresses to Google servers,
Firefox to Google servers and Safari to Google and Apple servers. In general
this function shares everything a user enters in the top bar, not just URLs.
For example, if users accidently type (or cut and paste) passwords or othersecrets in the top bar then these will also be shared.
2 Update 19th March 2020: this bug has been fixed and the GAPS cookie
is no longer set.

specifically says no reply will be forthcoming) that allows
posting of suggested feature enhancements, although publication of a tech report draft of this paper subsequently did prompt
much more helpful contact from Apple and similarly fromMicrosoft. Interaction with the privacy contacts that Google,
Apple, Mozilla etc publicise was wholly ineffective: either
they simply did not reply or the reply was a pro forma message
directing us to their product support pages.
II. T HREAT M ODEL : W HAT D O W E M EAN B Y P RIVACY ?
It is important to note that transmission of user data to backend
servers is not intrinsically a privacy intrusion. For example, it
can be useful to share details of the user device model/version
and the locale/country of the device (which most browsers do)and this carries few privacy risks if this data is common to
many users since the data itself cannot then be easily linked
back to a specific user [11], [12]. Similarly, sharing coarse
telemetry data such as the average page load time carries few
risks.
Issues arise, however, when data can be tied to a specific user.
A common way that this can happen is when a browser ties along randomised string to a single browser instance which thenacts as an identifier of that browser instance (since no otherbrowser instances share the same string value). When sentalongside other data this allows all of this data to be linked tothe same browser instance. When the same identifier is used
across multiple transmissions it allows these transmissions tobe tied together across time. Note that transmitted data always
includes the IP address of the user device (or more likely ofan upstream NAT gateway) which acts as a rough proxy foruser location via existing geoIP services. While linking data toa browser instance does not explicitly reveal the user’s realworld identity, many studies have shown that location data
linked over time can be used to de-anonymise, e.g. see [13],[14] and later studies. This is unsurprising since, for example,
knowledge of the work and home locations of a user can beinferred from such location data (based on where the user
mostly spends time during the day and evening), and whencombined with other data this information can quickly become
quite revealing [14]. A pertinent factor here is the frequency
with which updates are sent e.g. logging an IP addtress/proxylocation once a day has much less potential to be revealing
than logging one every few minutes. With these concerns in
mind, one of the main questions that we try to answer inthe present study is therefore: Does the data that a browser
transmits to backend servers potentially allow tracking of theIP address of a browser instance over time.
A second way that issues can arise is when user browsing
history is shared with backend servers. Previous studies haveshown that it is relatively easy to de-anonymise browsing
history, especially when combined with other data (plus recall
that transmission of data always involves sharing of the device
IP address/proxy location and so this can be readily combinedwith browsing data), e.g. see [15], [16] and later studies. The
second main question we try to answer is therefore: Does thebrowser leak details of the web pages visited in such a waythat they can be tied together to reconstruct the user browsing
history (even in a rough way).

3

We also pay attention to the persistence of identifiers overtime. We find that commonly identifiers persist over four timespans: (i) emphemeral identifiers are used to link a handful oftransmissions and then reset, (ii) session identifiers are reset onbrowser restart and so such an identifier only persists during
the interval between restarts, (iii) browser instance identifiers
are usually created when the browser is first installed andthen persist across restarts until the browser is uninstalled
and (iv) device identifiers are usually derived from the device
hardware details (e.g. the serial number or hardware UUID)
and so persist across browser reinstalls. Transmission of device
identifiers to backend servers is obviously the most worrisome
since it is a strong, enduring identifer of a user device that canbe regenerated at will, including by other apps (so allowing
linking of data across apps from the same manufacturer) andcannot be easily changed or reset by users. At the otherend of the spectrum, emphemeral identifiers are typically of
little concern. Session and browser instance identifiers lie
somewhere between these two extremes.
We use the time span of the identifiers employed as a simple
yet meaningful way to classify browsers, namely we gatherbrowsers using only emphemeral identifiers into one group(Brave), those which use session and browser instance identifiers into a second group (Chrome, Firefox, Safari) and thosewhich use device identifiers into a third group (Edge, Yandex).
It is worth noting that when location and browsing history canbe inferred from collected data then even if this inference is
not made by the organisation that collects the data it may bemade by third parties with whom data is shared. This includes
commercial partners (who may correlate this with other data
tin their possession), state agencies and disclosure via data
breaches.
An important dimension to privacy that we do not consider
here is the issue of giving and revoking consent for data
use. Our measurements do raise questions in the context of
GDPR regarding whether users have really given informed
consent prior to data collection, whether opting out is as easy
as opting in, and whether the purposes for which consent has
been obtained are sufficiently fine-grained (catch-all consent toall uses being inadmissible under GDPR). However we leavethis to future work.

A. Logging Network Connections
To record the timing of network connections and also to log
connections we use the open source appFirewall application
firewall [17]. Chrome also often tries to use the Google
QUIC/UDP protocol [18] to talk with Google servers and we
use the firewall to block these, forcing fallback to TCP, since
there are currently no tools for decrypting QUIC connections.
B. Viewing Content Of Encrypted Web Connections
Most of the network connections we observe are encrypted.
To inspect the content of a connection we use mitmdump [19]as a proxy and adjusted the firewall settings to redirect all web
traffic to mitmdump so that the proxying is transparent to thebrowsers. We add a mitmdump root certificate to the keychain
and change the settings so that it was trusted. In brief, whena new web connection starts the mitmdump proxy pretends
to be the destination server and presents a certificate for thetarget web site that has been signed by the trusted mitmdump
root certificate. This allows mitmdump to decrypt the traffic. Itthen creates an onward connection to the actual target web site
and acts as an intermediary relaying requests and their replies
between the browser and the target web site while logging thetraffic.
Note that it is possible for browsers to detect this intermediaryin some circumstances. For example, when Safari connects
to an Apple domain for backend services then it knows thecertificate it sees should be signed by an Apple root cert andcould, for example, abort the connection if it observes a nonApple signature (such as one by mitmdump). However, we
did not see evidence of such connection blocking by browsers,
perhaps because Enterprise security appliances also use trusted
root certificates to inspect traffic and it is not desirable forbrowsers to fail in Enterprise environments3 . That said, it isprobably worth bearing in mind that browsers may react bychanging the contents of their connections when interception
is detected, rather than blocking the connection altogether. In
our tests we have few means to detect such changes. One is tocompare the sequence of servers which the browser connects
to (i) without any proxy and (ii) with the proxy in place, andlook for differences. We carry out such comparisons and where
differences are observed we note them (minor changes were
only observed for Firefox);

III. M EASUREMENT S ETUP
We study six browsers: Chrome (v80.0.3987.87), Firefox (v73.0), Brave (v1.3.115), Safari (v13.0.3), Edge
(v80.0.361.48) and Yandex (v20.2.0.1145). Measurements aretaken using two Apple Macbooks, one running MacOS Mojave
10.14.6 and one running MacOS Catalina 10.15. Both werelocated in an EU country when our measurements werecollected. We do not expect browser behaviour to changemuch across desktop operating systems (e.g. we confirmedthat we saw similar behaviour on Windows 10 except for
additional connections by Edge) but it is worth noting thatthe mobile handset versions of browsers may well exhibit
different behaviour from the laptop/desktop version studied
here e.g. Firefox’s privacy policy suggests that additional datais collected on mobile devices.

C. Connection Data: Additional Material
Since the content of connections is not especially humanfriendly they are summarised and annotated in the additional
material4 . The raw connection data is also available on request
by sending an email to the author (since it contains identifiers,
posting the raw data publicily is probably unwise).
3 We were a little surprised at the absence of cert pinning and the like.
Indeed we had expected to need to use tools such as frida to bypass cert
checks but in the end this proved unnecessary. We did need to mark the
mitmproxy root cert as trusted in the keychain, as without this browser cert
checking raised errors, and in part it is this which suggests Enterprise security(with associated installation of trusted root certs) may be a factor here. We
also observed use of cert pinning in processes allied to Safari, as noted below.
4 Available anonymously at https://www.dropbox.com/s/6pao86s99lt4sow/
additional material.pdf

4

D. Ensuring Fresh Browser Installs
To start a browser in a clean state it is generally notenough to simply remove and reinstall the browser since
the old installation leaves files on the disk. We therefore took care to delete these files upon each fresh install. For most browsers it was sufficient to delete therelevant folders in ∼/Library/ApplicationSupport and ∼/Library/Caches. However, additional steps were needed for
Safari since it is more closely integrated with MacOS.
Namely, we delete three folders: ∼/Library/Safari (to delete
the user profile), ∼/Library/Containers/com.apple.Safari/Data/
Library/Caches (to clear the web cache), ∼/Library/Cookies/*(to delete any cookies) and ∼/Library/Containers/com.apple.
Safari/Data/Library/SavedApplicationState (to reset the start
page to the default rather than the last page visited). Also,
Firefox was launched with an initial skeleton profile infolder ∼/Library/ApplicationSupport/Firefox rather than simply with no folder present. This skeleton profile was createdby running Firefox from the command line and quickly
interrupting it. A user.js file was then added with the following entries: user pref(”security.enterprise roots.enabled”,
true); user pref(”security.OCSP.enabled”, 0). These settingstell Firefox to trust root certificates from the keychain. While
Firefox by default has automatic adaptation to allow root certificates this was observed to lead to changes in the sequenceof connections made on startup unless this skeleton profile wasused.
E. Test Design
We seek to define simple experiments that can be applied
uniformly across the set of browsers studied (so allowing directcomparisons), that generate repoducible behaviour and that
capture key aspects of general web browsing activity. To thisend, for each browser we carry out the following experiments(minor variations necessitated by the UI of specific browsers
are flagged when they occur):1) Start the browser from a fresh install/new user profile. Typically this involves simply clicking the browser app icon tolaunch it and then recording what happens. Chrome, Edge
and Yandex display initial windows before the browser
fully launches and in these cases we differentiate between
the data collected before clicking past this window and datacollected after.
2) Paste a URL into the browser to bar, press enter andrecord the network activity. The URL is pasted using asingle key press to allow behaviour with minimal search
autocomplete (a predictive feature that uploads text to asearch provider, typically Google, as it is typed so as todisplay autocomplete predictions to the user) activity to beobserved.
3) Close the browser and restart, recording the network activity during both events.
4) Start the browser from a fresh install/new user profile, click
past any initial window if necessary, and then leave thebrowser untouched for around 24 hours (with power savedisabled on the user device) and record network activity.

This allows us to measure the connections made by thebrowser when sitting idle.
5) Start the browser from a fresh install/new user profile, click
past any initial window if necessary, and then type a URL
into the top bar (the same URL previously pasted). Carewas taken to try to use a consistent typing speed acrossexperiments. This allows us to see the data transmissions
generated by search autocomplete (enabled by default inevery browser apart from Brave).
Each test is repeated multiple times to allow evaluation ofchanges in request identifiers across fresh installs.
Note that since these tests are easily reproducible (and indeed can potentially be automated) they can form the basis
for browser privacy benchmarking and tracking changes inbrowser behaviour over time as new versions are released.
We focus on the default “out of the box” behaviour ofbrowsers. There are several reasons for this. Perhaps themost important is that this is the behaviour experienced
by the majority of everyday users and so the behaviour of
most interest. A second reason is that this is the preferredconfiguration of the browser developer, presumably arrived
at after careful consideration and weighing of alternatives. A
third reason is that we seek to apply the same tests uniformly
across browsers to ensure a fair comparison and consistencyof results. Tweaking individual browser settings erodes thislevel playing field. Such tweaking is also something of an
open-ended business (where does one stop ?) and so practicalconsiderations also discourage this.

F. Finding Identifiers In Network Connections
Potential identifiers in network connections were extracted bymanual inspection5 . Basically any value present in requests
that changes between requests, across restarts and/or acrossfresh installs is flagged as a potential identifier. Values set
by the browser and values set via server responses are distinguished. Since the latter are set by the server changes in
the identifier value can still be linked together by the server,whereas this is not possible with browser randomised values.
For browser generated values where possible the code generating these values are inspected to determine whether they
are randomised or not. We also try to find more informationon the nature of observed values from privacy policies andother public documents and, where possible, by contacting therelevant developers.
IV. E VALUATING T HE P RIVACY O F P OPULAR BACK - ENDS ERVICES U SED B Y B ROWSERS
Before considering the browsers individually we first evaluate
the data transmissions generated by two of the backend
services used by several of the browsers.
5 We note that unfortunately analysis of content of network connections
for identifiers probably cannot be easily automated since it is potentially an
adversarial situation where statistical learning methods can easily be defeated.

5

A. Safe Browsing API
All of the browsers studied make use of a Safe Browsing
service that allows browsers to maintain and update a listof web pages associated with phishing and malware. Mostbrowsers make use of the service operated by Google [6] but
Yandex also operates a Safe Browsing service [20] and both
operators present essentially the same interface to browsers6 .
In view of its importance and widespread use the privacy of
the Safe Browsing service has attracted previous attention, seefor example [21], [22] and references therein. Much of thisfocussed on the original Lookup API which involved sending
URLs in the clear and so created obvious privacy concerns.
To address these concerns in the newer Update API clients
maintain a local copy of the threat database that consists of
URL hash prefixes. URLs are locally checked against thisprefix database and if a match is found a request is made forthe set of full length URL hashes that match the hash prefix.
Full length hashes received are also cached to reduce repeat
network requests. In this way browser URLs are never sentin full to the safe browing service, and some browsers also
add further obfuscation by injecting dummy queries. Broadly
speaking, the community seems content with the level ofprivacy this provides with regard to leaking of user browsing
history.
However, there is a second potential privacy issue associatedwith use of this service, namely whether requests can belinked together over time. Since requests carry the client IP
address then linking of requests together would allow therough location of clients to be tracked, with associated riskof deanonymisation. Our measurements indicate that browsers
typically contact the Safe Browsing API roughly every 30
mins to request updates. A typical update request sent tosafebrowsing.googleapis.com looks as follows:
GET https://safebrowsing.googleapis.com/v4/threatListUpdates:fetch
Parameters:$req: ChwKDGdvb2dsZWNocm9tZRIMOD. . .
$ct: application/x-protobuf
key: AIzaSyBOti4mM-6x9WDnZIjIeyEU2. . .

Note that the dots at the end of the $req and key values areused to indicate that they have been truncated here to save
space.
The key value is linked to the browser type e.g. Chrome orFirefox. Each use different key values, but all requests by,for example Chrome browsers, are observed to use the samevalue. In our measurements the $req value in observed tochange between requests. Public documentation for this API
makes no mention of a $req parameter, and so these requests
are using a private part of the API. However, the difference
from the public API seems minor. Inspection of the Chromium
source [23]7 indicates that the $req value is just a base64
encoded string that contains the same data as described in thesafebrowsing API documentation [6].
6 Tencent also operate a safe browsing service, see https://www.urlsec.qq.
com.
7 See
function GetBase64SerializedUpdateRequestProto() in filecomponents/safe browsing//core/db/v4 update protocol manager.cc

The data encoded within the $req string includes a “state”
value. This value is sent to the browser by safebrowsing.
googleapis.com alongside updates, and is echoed back by thebrowser when requesting updates. Since this value is dictatedby safebrowsing.googleapis.com it can be potentially used tolink requests by the same browser instance over time, andso also to link the device IP addresses over time. That does
not mean that this is actually done of course, only that it ispossible.
To assist in verifying the privacy of the safe browsing service
we note that it would be helpful for operators to make theirserver software open source. However, this is not currently thecase and so to investigate this further we modified a standard
Safe Browsing client [24] to (i) use the same key value andclient API parameters as used by Chrome (extracted fromobserved Chrome connections to the Google Safe Browsing
service) and (ii) by adding instrumentation to log the statevalue sent by safebrowsing.googleapis.com in response to
update requests. In light of the above discussion our interest
is in whether safebrowsing.googleapis.com sends a different
state value to each client, which would then act as a unique
identifier and facilitate tracking, or whether multiple clients
receive the same state value.
A typical state value returned by the safe browsing server is a
27 byte binary value (occasionally longer values are observed).
When multiple clients are started in parallel the state values
they receive typically differ in the last 5 bytes i.e. they do
not receive the same state value. However, closer inspection
reveals that each state value is generallly shared by mutliple
clients.
For example, Figure 1 shows measurements obtain from 100
clients started at the same time and making update requests
roughly every 30 mins (each client adds a few seconds of jitterto requests to avoid creating synchronised load on the server).
Since the clients are started at the same time and request
updates within a few seconds of each other then we expect thatthe actual state of the server-side safe browsing list is generally
the same for each round of client update requests. However, theclients are not all sent the same value. Instead what happens isthat at the first round of requests the 100 clients are assigned
to one of about 10 state values. The assignment is not uniform,
Figure 1(a) shows the number of clients assigned to each statevalue, but at least 5 clients are assigned to each. The last 5
bytes of the state value assigned to each client changes at each
new update, but clients that initially shared the same state value
are assigned the same new value. This behaviour can be seenin Figure 1(b). In this plot we assign an integer index to eachunique state value observed, assigning 1 to the first value andthen counting upwards. We then plot the state value index ofeach client vs the update number. Even though there are 100
clients it can be seen from Figure 1(b) that there are only
10 lines, and these lines remain distinct over time (they do
not cross). Effectively what seems to be happening is that atstartup each client is assigned to one of 10 hopping sequences.
Clients assigned to the same sequence then hop between statevalues in a coordinated manner. Presumably this approach isused to facilitate server load balancing.

Number of Clients

6

15

B. Chrome Extension (CRX) Update API

10

Chrome, and other browsers based on Chromium such as
Brave, Edge and Yandex, use the Autoupdate API [7] to checkfor and install updates to browser extensions. Each round of
update checking typically generates multiple requests to the
update server8 . An example of one such request is:

5

0
2

4

6

8

10

State Value Index

(a)

(b)

Fig. 1. State values returned by safebrowsing.googleapis.com over time to
100 clients behind the same gateway. Clients are initialled assigned one out of
10 state values, distributed as shown in (a). Clients assigned the same initialstate value are assigned the same state value in subsequent update requests,
as shown in (b).

The data shown is for 100 clients running behind the samegateway, so sharing the same external IP address. However, thesame behaviour is observed between clients running behinddifferent gateways. In particular, clients with different IP
addresses are assigned the same state values, and so we caninfer that the state value assigned does not depend on the client
IP address.
In summary, at a given point in time safe browsing clientsare not all assigned the same state value. However, multiple
clients share the same state value, including clients with thesame IP address. When there are sufficiently many clients
sharing the same IP address (e.g. a campus gateway) thenusing the state value and IP address to link requests fromthe same client together therefore seems difficult to achieve
reliably. When only one client, or a small number of clients,
share an IP address then linking requests is feasible. However,linking requests as the IP address (and so location) changes
seems difficult since the same state value is shared by multiple
clients with different IP addresses. Use of the Safe Browsing
API therefore appears to raise few privacy concerns.
We note that the wording of the Chrome Privacy Whitepaper [8] for safebrowsing.googleapis.com indicates that linkingof requests may take place:
For all Safe Browsing requests and reports, Google
logs the transferred data in its raw form and retains
this data for up to 30 days. Google collects standard log information for Safe Browsing requests,
including an IP address and one or more cookies.
After at most 30 days, Safe Browsing deletes the raw
logs, storing only calculated data in an anonymized
form that does not include your IP addresses or
cookies. Additionally, Safe Browsing requests won’t
be associated with your Google Account. They are,however, tied to the other Safe Browsing requests
made from the same device [our emphasis].
However, based on our discussions the last sentence likely
refers to the transmission of cookies with update requests.
Historically, cookies were sent with requests to safebrowsing.
googleapis.com [25] but this no longer seems to be the case:
we saw no examples of cookies being set by safebrowsing.
googleapis.com (and the API documents make no mention onthem) and saw no examples of cookies being sent.

POST https://update.googleapis.com/service/update2/json
Parameters:
cup2key=9:2699949029
cup2hreq=36463a2dd9c$\ldots$39fea17
Headers:
x-goog-update-appid: mimojjlkmoijpicakmndhoigimigcmbb,...
{ "request": {"@os": "mac","@updater": "chrome","acceptformat": "crx2,crx3","app": [{"appid": "mimojjlkmoijpicakmndhoigimigcmbb","brand": "GGRO","enabled": true,"ping": { "r": -2},"updatecheck": {},"version":"0.0.0.0" },<and similar entries>"requestid": "{61f7dcb8-474b-44ac-a0e5-b93a621a549b}","sessionid": "{debfbf76-8eaf-4176-82c6-773d46ca8c57}","updaterversion": "80.0.3987.87"}}

The appid value identifies the browser extension and therequest also includes general system information (O/S etc).
The header contains cup2key and cup2hreq values. Observealso the requestid and sessionid values in the request. If any ofthese values are dictated by the server then they can potentiallybe used to link requests by the same browser instance together
over time, and so also link the device IP addresses over time.
Public documentation for this API is lacking, but inspectionof the Chromium source [23] provides some insight. Firstly9 ,the cup2key value consists of a version number before thecolon and a random value after the colon, a new random
value being generated for each request. The cup2hreq is the
SHA256 hash of the request body. Secondly, inspection of the
Chromium source10 indicates that in fact the value of sessionid
is generated randomly by the browser itself at the start ofeach round of update checking. The requestid is also generated
randomly by the browser11 . Our measurements are consistent
with this: the requestid value is observed to change with eachrequest, the sessionid value remains constant across groups ofrequests but changes over time. This means that it would be
difficult for the server to link requests from the same browser
instance over time, and so also difficult to link the device IP
addresses of requests over time.
Our measurements indicate that browsers typically check for
updates to extensions no more than about every 5 hours.
8 Chrome sends requests to update.googleapis.com while Brave sends requests to go-updater.brave.com, Edge to edge.microsoft.com and Yandex toapi.browser.yandex.com.
9 See function Ecdsa::SignRequest in file components/client update
protocol/ecdsa.cc and its call from request sender.cc
10 See function UpdateContext::UpdateContext in file components/updateclient/update engine.cc
11 See function protocol request::RequestMakeProtocolRequest in filecomponents/update client/protocol serializer.cc

connection number

7

5

ssl.gstatic.com

4

ssl.gstatic.com

3

clients2.googleusercontent.com

2

clients2.google.com

1

accounts.google.com

0

0

5

10

The device id value is set by the browser and its value isobserved to change across fresh installs, although it is notclear how the value is calculated (it seems to be calculated
inside the closed-source part of Chrome). The server responseto this request sets a cookie.

15time (s)(a)(b)

Fig. 2. Chrome connections during first startup, while displays initial popup
box as shown. Nothing was clicked.

connection number

15

r2---sn-q0c7rn76.gvt1.com
r1---sn-q0cedn7s.gvt1.com
r4---sn-q0c7rn76.gvt1.com
r1.sn-q0c7rn76.gvt1.com
r2---sn-q0cedn7s.gvt1.com
r3---sn-q0cedn7s.gvt1.com
r4---sn-q0cedn7s.gvt1.com
update.googleapis.com
docs.google.com
www.googleapis.com
r2---sn-q0cedn7s.gvt1.com
redirector.gvt1.com
www.gstatic.com
www.gstatic.com
clientservices.googleapis.com

10

5

0

0

50

100

150

200

time (s)(a)(b)

Fig. 3. Chrome connections after clicking “start google chrome” in iniital
popup shown in Figure 2 (and also clicking to untick the displayed options
to make chrome the default browser and allow telemetry). Nothing else wasclicked.

V. DATA T RANSMITTTED O N B ROWSER S TARTUP
A. Google Chrome
On first startup Chrome shows an initial popup window, see
Figure 2(b). While sitting at this window, and with nothingclicked, the browser makes a number of network connections,
see Figure 2(a) for the connections reported by appFirewall.
It is unexpected, and initially concerning, to see connections
being made while the popup window asking for permissions isbeing displayed and has not yet been responded to. However,inspection of the content of these connections indicates thatno identifiers or personal information is transmitted to Google,
and so while perhaps not best practice they seem to be innocent
enough.
After unticking the option to make Chrome the default browser
and unticking the option to allow telemetry we then clicked
the“start google chrome” button. The start page for Chrome isdisplayed and another batch of network connections are made,see Figure 3.
Inspection of the content of these connections indicates adevice id value is sent in a call to accounts.google.com, e.g.
GET https://accounts.google.com/ServiceLogin
Parameters:
service: wisepassive: 1209600
continue: https://docs.google.com/offline/extension/frame?ouidfollowup: https://docs.google.com/offline/extension/frame?ouid
ltmpl: homepage
Headers:x-chrome-id-consistency-request: version=1,client_id=77185425430.apps.googleusercontent.com, device_id=90c0f8ccd49a-4d09-a81c-32b7c0f2aae6, signin_mode=all_accounts,
signout_mode=show_confirmation

The URL http://leith.ie/nothingtosee.html is now pasted (nottyped) into the browser top bar. This generates a request
to www.google.com/complete/search with the URL details(i.e. http://leith.ie/nothingtosee.html) passed as a parameterand also two identifier-like quantities (psi and sugkey). The
sugkey value seems to be the same for all instances of
Chrome and also matches the key sent in calls to safebrowsing.googleapis.com, so this is likely an identifer tied to
Chrome itself rather than particular instances of it. The psivalue behaves differently however and changes between fresh
restarts, it therefore can act as an identifier of an instance of
Chrome. The actual request to http://leith.ie/nothingtosee.html(a plain test page with no embedded links or content) is thenmade. This behaviour is reproducible across multiple fresh
installs and indicates that user browsing history is by default
communicated to Google.
The browser was then closed and reopened. It opens to theGoogle search page (i.e. it has changed from the Chrome start
page shown when the browser was closed) and generates aseries of connections, essentially a subset of the connections
made on first startup. Amongst these connections are tworequests that contain data that appear to be persistent identifiers. One is a request to accounts.google.com/ListAccounts
which transmits a cookie that was set during the call toaccounts.google.com on initial startup, e.g.
POST https://accounts.google.com/ListAccounts
cookie: GAPS=1:-qChrMo1Rv\_1fBI0gYpVRkLD\_h89hQ:jJRNg2
Cs370FK-DG

This cookie acts as a persistent identifier of the browser
instance and since is set by the server changing values canpotentially be linked together by the server. The second isa request to www.google.com/async/newtab ogb which sends
an x-client-data header, e.g.
GET https://www.google.com/async/newtab_ogb
x-client-data:
CIe2yQEIo7bJAQjEtskBCKmdygEIvbDKAQiWtcoBCO21ygEI
jrrKARirpMoBGJq6ygE=

According to Google’s privacy documentation[8] the x-clientdata header value is used for field trials:
We want to build features that users want, so a
subset of users may get a sneak peek at new
functionality being tested before it’s launched to
the world at large. A list of field trials that are
currently active on your installation of Chrome will
be included in all requests sent to Google. This
Chrome-Variations header (X-Client-Data) will notcontain any personally identifiable information, andwill only describe the state of the installation of
Chrome itself, including active variations, as well asserver-side experiments that may affect the installation. The variations active for a given installation
are determined by a seed number which is randomly
selected on first run.

connection number

8

15
10
5
0

Once startup was complete, the URL http://leith.ie/
nothingtosee.html was pasted into the browser top bar.
This generates no extraneous connections.

r3---sn-q0cedn7s.gvt1.com
redirector.gvt1.com
a21ed24...rackcdn.com
aus5.mozilla.org
safebrowsing.googleapis.com
accounts.firefox.com
accounts.firefox.com
incoming.telemetry.mozilla.org
snippets.cdn.mozilla.net
snippets.cdn.mozilla.net
incoming.telemetry.mozilla.org
content-signature-2.cdn.mozilla.net
shavar.services.mozilla.com
push.services.mozilla.com
incoming.telemetry.mozilla.org
mozilla.org
www.mozilla.org
firefox.settings.services.mozilla.com
search.services.mozilla.com
firefox.settings.services.mozilla.com
detectportal.firefox.com
location.services.mozilla.com
detectportal.firefox.com

20

0

50

100

The browser was then closed and reopened. Closure resultsin transmission of data to incoming.telemetry.mozilla.org by ahelper pingsender process e.g.

150time (s)(a)(b)

Fig. 4. Firefox connections during first startup, with nothing clicked.

The value of the x-client-data header is observed to change
across fresh installs, which is consistent with this documentation. Provided the same x-client-data header value is shared bya sufficiently large, diverse population of users then its impact
on privacy is probably minor. However, we are not aware of
public information on the size of cohorts sharing the samex-client-data header.
Based on discussions with Google on foot on this work they
consider the call to accounts.google.com/ServiceLogin thatsets the GAPS cookie to be a bug, likely in the Google Docs
extension which is embedded within Chrome, and are currently
investigating12 . We have proposed to Google that an option be
added in the initial popup window to allow users to disablesearch autocomplete before the browser fully launches.
B. Mozilla Firefox
Figure 4(a) shows the connections reported by appFirewall
when a fresh install of Firefox is first started and left sitting at
the startup window shown in Figure 4(b). The data shown isfor startup with mitmproxy running, but an almost identical setof connections is also seen when mitmproxy is disabled (thedifference being additional connections to ocsp.digicert.com
in the latter case).
During startup Firefox three identifiers are transmitted to
Mozilla: (i) impression id and client id values are sent toincoming.telemetry.mozilla.org, (ii) a uaid value sent to Firefox by push.services.mozilla.com via a web socket and echoedback in subsequent web socket messages sent to push.services.
mozilla.com, e.g.
192.168.0.17:62874 <- WebSocket 1 message <push.services.mozilla.com:443/{"messageType":"hello","uaid":"332024
d750734458bc95724268a7b163","status":200,"use_webpush":true,"broadcasts":{}}

These three values change between fresh installs of Firefox
but persist across browser restarts. Inspection of the Firefox
source code [26] indicates that impression id and client id areboth randomised values set by the browser13 . The uaid valueis, however, set by the server.
12 Update 19th March 2020: this bug has been fixed and the GAPS cookie
is no longer set.
13 See function getOrCreateImpressionId() in file browser/components/
newtab/lib/TelemetryFeed.jsm for where impression id is initialised and function doLoadClientID() in file toolkit/components/telemetry/app/ClientID.jsm
for where client id is initialised.

POST https://incoming.telemetry.mozilla.org/submit/
telemetry/03206176-b1b4-a348-853e-502461c488f7/event/Firefox/73.0/release/20200207195153?v=4<...>"reason":"shutdown",<...>"sessionId":"cebba8d1-5a4e-d94a-b137-97979fec8c28","subsessionId":"af1fc2f8-178d-c046-bef9-1d1dea283453",<...>"clientId":"0d0214ec-74d8-5640-ae0e-e3dc8952e6aa",<...>

As can be seen, this data is tagged with the client id identifier
and also contains a sessionId value. The sessionId value isthe same across multiple requests. It changes between restarts
but is communicated in such a way that new sessionId values
can be easily linked back to the old values (the old and new
sessionId values are sent together in a telemetry handovermessage).
Reopening generates a subset of the connections seen on firststart. When the web socket to push.services.mozilla.com is
Firefox sends the uaid value assigned to it during first startup
to push.services.mozilla.com. Messages are sent to incoming.
telemetry.mozilla.org tagged with the persistent impression id
and client id values.
In summary, there appear to be a four identifiers usedin the communication with push.services.mozilla.com andincoming.telemetry.mozilla.org. Namely, (i) client id and impression id values used in communication with incoming.
telemetry.mozilla.org which are set by the browser and persistent across browser restarts, (ii) a sessionId value used withincoming.telemetry.mozilla.org which changes but values canbe linked together since the old and new sessionId values aresent together in a telemetry handover message, (iii) a uaid
value that is set by the server push.services.mozilla.com when
the web socket is first opened and echoed back in subsequent
web socket messages sent to push.services.mozilla.com, thisvalue also persists across browser restarts.
These observations regarding use of identifiers are consistent
with Firefox telemetry documentation [9] and it is clear thatthese are used to link together telemetry requests from thesame browser instance. As already noted, it is not the content
of these requests which is the concern but rather that they carrythe client IP address (and so rough location) as metadata. The
approach used allows the client IP addresses/location to betied together. That does not mean such linking actually takes
place, only that the potential exists for it to be done. The
Firefox telemetry documentation14 says that “When Firefox
sends data to us, your IP address is temporarily collected aspart of our server logs. IP addresses are deleted every 30 days.”
but is silent on the uses to which the IP data is put.
With regard to the uaid value, Firefox documentation [27] for
their push services says uaid is “A globally unique UserAgent
14 See https://support.mozilla.org/en-US/kb/telemetry-clientid

9connection number

20

safebrowsing.brave.com
redirector.brave.com
p3a.brave.com
static1.brave.com
static1.brave.com
crlsets.brave.com
brave-core-ext.s3.brave.com
brave-core-ext.s3.brave.com
tor.bravesoftware.com
componentupdater.brave.com
go-updater.brave.com
go-updater.brave.com
go-updater.brave.com
go-updater.brave.com
go-updater.brave.com
go-updater.brave.com
laptop-updates.brave.com
laptop-updates.brave.com
static1.brave.com
static1.brave.com

15
10
5
0

0

50

100

150

time (s)

(a)

(b)

(a)

(b)

Fig. 5. Brave connections during first startup, with nothing clicked.

Fig. 6. Safari connections during first startup, with nothing clicked.

ID” and “We store a randomized identifier on our server foryour browser”. We could not find a document stating Mozilla’s
policy regarding IP logging in their push service.

set-cookie headers. These cookies are scrubbed and not resent
in later requests to the prefetched pages. However, we also
saw evidence of embedding of identifiers within the prefetched
html/javascript, which may then be passed as parameters(rather than as cookies) in requests generated by clicking on
the displayed icon.

We have requested clarification from Mozilla of the uses towhich the IP metadata logged as part of the telemetry andpush services is put, and in particular whether IP addresses
are mapped to locations, but have not yet received a response.
We have also proposed to Firefox that (i) users are given
the option to disable search autocomplete and telemetry on
first startup and (ii) the uaid value is not sent over the
push.services.mozilla.com websocket until users have registered for one or more push notifications (the web socket itself
is apparently also used for distributing notifications related
to TLS certificates etc but this does not require a unique
identifier).
C. Brave
Figure 5(a) shows the connections reported by appFirewall
when a fresh install of Brave is first started and left sittingat the startup window shown in Figure 5(b). During startup
no perisistent identifers are transmitted by Brave. Calls to
go-updater.brave.com contain a sessionid value, similarly tocalls to update.googleapis.com in Chrome, but with Brave thisvalue changes between requests. Coarse telemetry is transmitted by Brave, and is sent without any identifiers attached [28].
Once startup was complete, the URL http://leith.ie/
nothingtosee.html was pasted into the browser top bar.
This generates no extraneous connections.
The browser was then closed and reopened. No data istransmitted on close. On reopen a subset of the initial startup
connections are made but once again no persistent identifiers
are transmitted.
In summary, we do not find Brave making any use of identifiers allowing tracking by backend servers of IP address overtime, and no sharing of the details of web pages visited withbackend servers.
D. Apple Safari
Figure 6(a) shows the connections reported by appFirewall
when a fresh install of Safari is first started and left sittingat the startup window shown in Figure 6(b). By default
Safari displays a “favorites” page. Resources are fetched foreach of the 12 services displayed. This results in numerous
connections being made, most of which respond with multiple

Once startup was complete, the URL http://leith.ie/
nothingtosee.html was pasted into the browser top bar. In
addition to connections to leith.ie this action also consistently
generated a connection to configuration.apple.com by process
com.apple.geod e.g.
GET https://configuration.apple.com/configurations/pep/
config/geo/networkDefaults-osx-10.14.4.plist
User-Agent: com.apple.geod/1364.26.4.19.6 CFNetwork/978.1
Darwin/18.7.0 (x86_64)
Response is 2.6KB of text/xml

This extra connection sent no identifiers.
Safari was then closed and reopened. No data is transmitted on
close. On reopen Safari itself makes no network connections(the leith.ie page is displayed, but has been cached and sono network connection is generated) but a related processnsurlsessiond consistently connects to gateway.icloud.com onbehalf of com.apple.SafariBookmarksSyncAgent e.g.
POST https://gateway.icloud.com/ckdatabase/api/client/
subscription/retrieve
X-CloudKit-ContainerId: com.apple.SafariShared.
WBSCloudBookmarksStoreX-CloudKit-UserId: _9acd71fb10d466. . .
X-CloudKit-BundleId: com.apple.SafariBookmarksSyncAgentThis request transmits an X-CloudKit-UserId header value
which appears to be a persistent identifier that remains constantacross restarts of Safari. Note that iCloud is not enabledon the device used for testing nor has bookmark syncing
been enabled, and never has been, so this connection is
spurious. From discussions with Apple it appears this request
is unexpected and so may well be a bug.
In summary, Safari defaults to a choice of start page thatleaks information to third parties and allows them to cache
prefetched content without any user consent. Start page aside,
Safari otherwise appears to be quite a quiet browser, making
no extraneous network connections itself in these tests andtransmitting no persistent identifiers. However, allied processes
make connections which appear unnecessary.
We have proposed to Apple that (i) they change Safari’s
default start page and (ii) unnecessary network connections
by associated processes are avoided.

10connection number(a) With nothing clicked

45

40

35

(b) Initial screen

www.microsoft.com
web.vortex.data.microsoft.com
uhf.microsoft.com
edgewelcomecdn.microsoft.com
cs22.wpc.v0cdn.net
edgewelcomecdn.microsoft.com
edgewelcomecdn.microsoft.com
edgewelcomecdn.microsoft.com
edgewelcomecdn.microsoft.com
edgewelcomecdn.microsoft.com
edgewelcomecdn.microsoft.com
microsoftedgewelcome.microsoft.com
go.microsoft.com
go.microsoft.com
ris.api.iris.microsoft.com

140

160

180

200

220

time (s)(c) After clicking “Get Started” button(d) Edge welcome pageFig. 7. Edge connections during first startup.

E. Microsoft Edge
On start up of a fresh install of Edge the browser goes throughan opening animation before arriving at the startup window
shown in Figure 7(b). Figure 7(a) shows the connections
reported by appFirewall during this startup process, withnothing is clicked.
It can be seen that Edge makes connections to a number ofMicrosoft administered domains. The following observations
are worth noting:1) Fairly early in this process the response to a request to
ntp.msn.com includes an “x-msedge-ref” header value
which is echoed by Edge in subsequent requests. Thisvalue changes on a fresh install of the browser and also
across browser restarts, so it seems to be used to tie
together requests in a session. Since this vaue is dictatedby the server (rather than being randomly generated by
the browser) it is possible for the server to also tie
sessions together.
2) Much more troubling, later in the startup process Edge
sends a POST request to self.events.data.microsoft.com
e.g.
POST
https://self.events.data.microsoft.com/OneCollector/1.0/
Headers:
APIKey: 7005b72804a64fa4b. . .
SDK-Version: EVT-MacOSX-C++-No-3.2.297.1
Request Body:)\x033.0I&Microsoft.WebBrowser.SystemInfo.Configq\x80\xb4\xaa\xfc\xaa\xe7\xd9\xd7\x11\xa9"o:7005
b72804a64fa4b2138faab88f877b\xd1\x06\x82\x04\xcb\x15\x01i\x05Apple\x89\x0eMacBookPro15,2\x00\xcb\x16\x01\x00\xcb\x17\x01I&u:0B5E1E28-B2E0-5DE9-848D-0368FB. . .\x00\xcb\x18\x01\x89\x08Mac OS X\xa9\x0710.14.6\x00\xcb\x19\x01\xa99M:com.microsoft.edgemac_80.0.361.48_x86_64!
Microsoft Edge\xc9\x06\x0b80.0.361.48\x00\xcb\x1f\x01I Unmeteredi\x05Wired\x00\xcb\x01)\x1bEVT-MacOSX-C++-No-3.2.297.1I$$
eaf6f216-bca7-a0c9-8b40. . .
\x01i\x0500:00\x00\xcb%\x01\x00\xc9<\x06custom\xcbF\x01-\x10\x0cAppInfo.ETag\x00\x07Channel0\x00\x91\x08\x00\
x0eConnectionTypei\x07Unknown\x00\x04Etag\x00\
x0fEventInfo.Level0\x00\x91\x04\x00\x0cPayloadClassi\
x0bSYSTEM_INFO\x00\x0b$PayloadGUID
i$2f0dbe5e-a940-4842-8fb3-9b61ed5003ad\x00\
x0ePayloadLogType0\x00\x91\x00\x0fappConsentState0\x00\x00\x0bapp_versioni\
x0e80.0.361.48-64\x00 $client_id0\x00\x91\xba\xa1\xa9\
xd4\xef\xc6\xf0\xbc\x04\x00
installSource0\x00\x00\x0cinstall_date0\x00\x91\x80\
x9c\xcb\xe4\x0b\x00
pop_sample0\x08\xa8\x00\x00\x00\x00\x00\x00Y@\x00
session_id0\x00\x91\x02\x00 utc_flags0\x00\x91\x80\
x80\xc0\x80\x80\x80@\x00\x00\x00

This request transmits the hardware UUID reported byApple System Information to Microsoft (highlighted inred). This identifier is unique to the device and neverchanges, thus it provides a strong, enduring user identifier.
This behaviour is consistent with Microsoft documentation [29]. The second block in the request body also contains a number of other identifier-like entries (highlighted
in bold since they are embedded within binary content),
namely the entries PayloadGUID value and client id. It
is not clear how these values are calculated although they
are observed to change across fresh installs.
3) Towards the end of the startup process Edge contacts
arc.msn.com. The first request to arc.msn.com transmits a “placement” parameter (which changes acrossfresh installs) and the response contains a number ofidentifiers. These returned values are then echoed byEdge in subsequent requests to arc.msn.com and also toris.api.iris.microsoft.com.
It is not possible to proceed without pressing the “Get Started”
button on the popup. Clicking on this button displays a newpopup. This new popup has an “x” in the top right corner, andthat was clicked to close it. Edge then proceeds to load its
welcome page, shown in Figure 7(d). The network connections
prompted by these two clicks (the minimal interaction possible
to allow progress) are shown in Figure 7(c.
Loading of the Edge welcome page sets a number of cookies.
In particular, this includes a cookie for vortex.data.microsoft.
com which allows data transmitted to this server to be linked
to the same browser instance e.g.
GET https://web.vortex.data.microsoft.com/collect/v1/t.js
Parameters:<...>-impressionGuid: ’59d59183-cd90-4787-ab0c-8328d0b20e75’<...>
The response sets cookies:
Set-Cookie: MC1=GUID=da7d27b6947c48b8abd43591e780322d&
HASH=da7d&LV=202002&V=4&LU=1581941544000;Domain=.microsoft.
com;Expires=Tue, 16 Feb 2021 12:12:24 GMT;Path=/;Secure;SameSite=None
Set-Cookie: MS0=dc42e1616b0e434e9bef71d2da20f061;Domain=.
microsoft.com;Expires=Mon, 17 Feb 2020 12:42:24 GMT;Path=/;Secure;SameSite=None

The response also includes javascript with the cookie value
embedded:
document.cookie="MSFPC=GUID=
da7d27b6947c48b8abd43591e780322d&HASH=da7d&LV=202002&V=4&LU=1581941544000;expires=Tue,which is used for cross-domain sharing of the cookie (thiscookie set by vortex.data.microsoft.com is shared with www.
microsoft.com).

11

with a fresh browser install, so it acts as a persistent identifierof the browser instance. The response from yandex.ru setsa second cookie and both are sent together in subsequent
requests.

connection number

15
storage.ape.yandex.net
sync.browser.yandex.net
browser.yandex.com
yastat.net
mail.yandex.ru
yandex.ru
api.browser.yandex.ru
sba.cdn.yandex.net
sba.cdn.yandex.net
yastatic.net
bro-bg-store.s3.yandex.net
sba.yandex.net
browser.yandex.com
api.browser.yandex.com

10

5

0

0

50

100

150

time (s)(a)(b)

At this point the browser displays a screen asking the user
to select a search engine, see Figure 8(b). It is not possible
to proceed past this point without selecting one. Clicking on
the Yandex option generates the network connections shownin Figure 8(c) and brings the browser to the Yandex start pageshown in Figure 8(d).
A number of points are worth noting:

(c)

(d)

Fig. 8. On first startup Yandex opens an initial popup. When left unclicked noconnections were observed. After clicking to deselect the “make default” and”send usage stats” options in the popup, and then clicking “launch” Yandex
makes the connections shown in plot (a). Note that Yandex opens a window
asking to choose which search engine to use, shown in plot (b). Plot (c)shows the connections made after selecting Yandex as the search engine, plot(d) shows the window displayed after making this click.

At the Edge welcome page the URL http://leith.ie/
nothingtosee.html was pasted into the browser top bar. Even
this simple action has a number of unwanted consequences:
1) Before navigating to http://leith.ie/nothingtosee.html
Edge first transmits the URL to www.bing.com (thisis a call to the Bing autocomplete API, and so sharesuser browsing history with the Bing service of Microsoft). Edge also contacts vortex.data.microsoft.com(which transmits the cookie noted above).
2) After navigating to http://leith.ie/nothingtosee.html Edge
then transmits the URL to nav.smartscreen.microsoft.
com/, sharing user browsing history with a second Microsoft server.
Edge was then closed and reopened. No data is transmitted
on close. On reopen a subset of the connections from the first
open are made, including the transmission to self.events.data.
microsoft.com of the device hardware UUID for a second time.
F. Yandex Browser
On first startup Yandex opens an initial popup which asks
whether the user would like to make Yandex the default
browser and whether usage statistics can be shared and whichhas “Launch” and “Cancel” buttons. While this popup isdisplayed no network connections were observed.
Figure 8(a) shows the network connections made after clicking
to deselect the two options in the popup and then clicking the“Launch” button. The browser makes connections to a numberof Yandex administered domains. Early in the startup process
the browser sends a cookie on first connecting to yandex.ru. At
this point no cookies have been set by server responses so thisis presumably a cookie generated by the browser itself. The
cookie value is persistent across browser restarts but changes

1) The browser sends the identifying cookies created onstartup to browser.yandex.ru and related domains. As partof this initialisation process a call to browser.yandex.
ru/activation/metrika sets a yandexuid cookie for domain yandex.com and a later call to browser.yandex.ru/
welcome/ also sets this cookie for domain yandex.ru. Thisvalue acts as a persistent identifier of the browser instance(it changes upon a fresh browser install). The two cookies
generated at initial startup and this third yandexuid are
now sent together with subsequent requests.
2) The browsers sends a client id and a machine id value tosoft.export.yandex.ru. The client id value changes acrossfresh installs. The machine id value is an SHA1 hash of
the MAC address of the device’s primary interface andthe device serial number i.e. a strong, enduring device
identifier. These values are transmitted along with the
yandexuid cookie and so they can be tied together.
At the Yandex welcome page the URL http://leith.ie/
nothingtosee.html is pasted into the browser top bar:
1) Before navigating to http://leith.ie/nothingtosee.html Yandex first transmits the URL to yandex.ru (this is a call to
the Yandex autocomplete API, and so immediately leaks
user browsing history to Yandex).
2) After navigating to http://leith.ie/nothingtosee.html Yandex then transmits the text content of http://leith.ie/
nothingtosee.html to translate.yandex.net.
The Yandex browser was then closed and reopened. No datais transmitted on close. On reopen a subset of the connections
from the first open are made, transmitting the various cookie
values.
VI. DATA T RANSMITTTED W HILE B ROWSER I S I DLE
We now look at the connections made while the browsers are
sitting idle for approximately 24 hours. In summary, with thenotable exception of Yandex no identifiers are observed to betransmitted in browser backend requests sent while idle.
A. Google Chrome
Figure 9(a) shows a typical set of connections made by
Chrome reported by appFirewall as the browser sits idle. It canbe seen that connects to safebrowsing.googleapis.com (checking for updates to the list of malware URLs) and clientservices.
googleapis.com (checking for updates to Chrome field trials)

50
45
40
35
30

100

150

200

250

105

firefox.settings.services.mozilla.com
safebrowsing.googleapis.com
shavar.services.mozilla.com

100
95
90

300

500

time (mins)

550

600

55
50
450

500

550

600

95
90
85
80

200
190
180

api.browser.yandex.com
api.browser.yandex.net
collections.yandex.ru
sba.yandex.net
sync.browser.yandex.net

170
160
150
140

450

500

550

600

450

500

550

time (mins)

time (mins)(b) Firefox(a) Edge(b) Yandex

600

Fig. 10. Measurements of browser network connections while browser issitting idle.

safebrowsing.googleapis.com

connection number

connection number

60

go-updater.brave.com
laptop-updates.brave.com
p3a.brave.com
safebrowsing.brave.com
updates.bravesoftware.com

config.edge.skype.com
edge.microsoft.com
smartscreen-prod.microsoft.com

time (mins)

21
65

100

75
450

(a) Chrome105

connection number

55

connection number

connection number

110

clients4.google.com
clientservices.googleapis.com
safebrowsing.googleapis.com
storage.googleapis.com
update.googleapis.com

60

connection number

12

20
19
18
17
16
15
14

500

550

time (mins)

time (mins)(c) Brave(d) Safari

600

Fig. 9. Measurements of browser network connections while browser is sitting
idle.

roughly every 30 minutes. About once an hour it connects
to clients4.google.com (its not clear what the purpose of thisconnection is, but it may be related to push notifications).
More infrequently (no more than every 5 hours), it connects
to update.googleapis.com to check for update to chrome extensions (the connection to storage.googleapis.com shown in Figure 9(a) is on foot of the response from update.googleapis.com
directing Chrome to storage.googleapis.com to download an
update to an extension) and to www.gstatic.com checking forcomponent updates (Flash, Quicktime, certificate revocation
etc).
None of these connections are observed to contain persistent identifers. That said, the connections to clientservices.
googleapis.com (checking for updates to field trials) do seemto be made with undue frequency.
B. Mozilla Firefox
Figure 9(b) shows the connections by Firefox reported by
appFirewall as the browser sits idle. It can be seen that
Firefox connects to safebrowsing.googleapis.com (checking
for updates to the list of malware URLs) roughly every
30 minutes and to shavar.services.mozilla.com (checking for
updates to Firefox’s Tracking Protection blocklists) roughly
once per hour. More infrequently, Firefox connects to firefox.
settings.mozilla.com (Firefox’s remote settiings service [30]for updates to blocklists and for A/B testing and user surveys [10]). These connections occasionally prompt further
connections e.g. the response from firefox.settings.mozilla.
com can prompt connections to blocklists.settings.services.
mozilla.org, services.addons.mozilla.org, aus5.mozilla.org.
None of these connections are observed to contain persistentidentifers.
C. Brave
Figure 9(c) shows the connections by Brave as thebrowser sits idle. It can be see that Brave connects tosafebrowsing.brave.com roughly every 30 minutes. Less frequently Brave connects to p3a.brave.com (sending coarse
telemetry), updates.bravesoftware.com (checking for updates
to Brave), laptop-updates.brave.com and go-updater.brave.com(checking for updates to extensions).
None of these connections are observed to contain persistentidentifers.
D. Apple Safari
Figure 9(d) shows the connections by Safari as the browser
sits idle. It can be see that Safari connects to safebrowsing.
googleapis.com roughly every 30 minutes but otherwise issilent (at least over the 24 hours or so for which the measurements here were collected). Presumably there are no checks
for updates, unlike for other browsers, because this checking
is performed separately by Apple’s AppStore app.
E. Microsoft Edge
Figure 10(a) shows the connections made by Edge as thebrowser sits idle. It can be seen that Edge connects toedge.microsoft.com roughly every 30 mins and to config.
edge.skype.com and smartscreen-prod.microsoft.com roughly
every hour. Two types of request are observed to be madeto edge.microsoft.com, one making a call to what appears
to be a safe browsing API and one checking for updates tobrowser extensions, using a similar request format to Chrome
and Brave. Requests to config.edge.skype.com seem to bechecking for updates to Edge itself. Smartcreen is Microsoft’s
malware/anti-phishing service and so presumably the requests
to smartscreen-prod.microsoft.com relate to that.
None of these connections are observed to contain persistentidentifers.
F. Yandex Browser
Figure 10(b) shows the connections made by Yandex as thebrowser sits idle. It can be seen that Yandex makes connections
rather more frequently than the other browsers studied here.
Connections to collections.yandex.ru and api.browser.yandex.
net are made roughly every 10 minutes, and connections to
sba.yandex.net roughly every 30 mins and connections to
sync.browser.yandex.net roughly once per hour. Intermittently
connections are also made to api.browser.yandex.com.
The connections to collections.yandex.net seem to be checking
for browser updates and transmit the identifying cookies
created during browser startup (see above for details).

13

The connections to api.browser.yandex.net transmit theclient id and machine id identifiers and the purpose of theseconnections is unclear but the URL suggests it is refresh ofconfiguration information.
The connections to sba.yandex.net seem to be calling the
Safe Browsing API, or similar, and send no identifiers. The
connections to sync.browser.yandex.net seem to be checking
for push notifications, and again carry no identfiers.
The connections to api.browser.yandex.com transmit an xyauuid header and the yp cookie (which can be used to identify
the browser instance, see above). Again, the purpose is unclear
but the URL suggests refreshing of browser component display
details.
VII. DATA T RANSMITTTED B Y S EARCH AUTOCOMPLETE
In this section we look at the network connections made bybrowsers as the user types in the browser top bar. As before,
each browser is launched as a fresh install but now rather
than pasting http://leith.ie/nothingtosee.html into the top bar
the text leith.ie/nothingtosee.html is typed into it. We try tokeep the typing speed consistent across tests.
In summary, Safari has the most aggressive autocomplete
behaviour, generating a total of 32 requests to both Google andApple. However, the requests for Google contain no identifier
and those to Apple contain only an ephemeral identifier(which is reset every 15 mins). Chrome is the next mostaggressive, generating 19 requests to a Google server andthese include an identifier that persists across browser restarts.
Firefox is significantly less aggressive, sending no identifierswith requests and terminating requests after the first word, so
generating a total of 4 requests to Google. Better still, Brave
disables autocomplete by default and sends no requests at all
as a user types in the top bar.
In light of these measurements and the obvious privacy concerns they create, we have proposed to the browser developersthat on first start users be given the option to disable search
autocomplete.
A. Google Chrome
Chrome sends text to www.google.com as it is typed. A request
is sent for almost every letter typed, resulting in a total of 19
requests. For example, the response to typing the letter “l” is:["lewis burton","liverpool","love island","linkedin","littlewoods","lotto","lidl","laura whitmore","lighthousecinema","livescore","liverpool fc","lifestyle","little women","liverpool fixtures","leeds united","love holidays","lewis
capaldi","lotto.ie","lifestyle sports","ladbrokes"]

Each request header includes a psi value which changes acrossfresh installs but remains constant across browser restarts i.e. it
seems to act as a persistent identifier for each browser instance,
allowing requests to be tied together.
B. Mozilla Firefox
Firefox sends text to www.google.com as it is typed. A request
is sent for almost every letter typed, but these stop after the
first word “leith” (i.e. presumably after the dot in the URL is

typed) resulting in a total of 4 requests (compared to 19 for
Chrome and 32 for Safari). No identifier are included in therequests to www.google.com.
C. Brave
Brave has autocomplete disabled by default and makes no
network connections at all as we type in the top bar.
D. Apple Safari
Safari sends typed text both to a Google server clients1.google.
com and to an Apple server api-glb-dub.smoot.apple.com.
Data is initially sent to both every time a new letter is typed,
although transmission to clients1.google.com stops shortly
after the first word “leith” is complete. The result is 7 requests
to clients1.google.com and 25 requests to api-glb-dub.smoot.
apple.com, a total of 32 requests
No identifier are included in the requests to clients1.
google.com. However, requests to api-glb-dub.smoot.apple.
com include X-Apple-GeoMetadata, X-Apple-UserGuid and
X-Apple-GeoSession header values. In our tests the valueof X-Apple-GeoMetadata remains unchanged across freshbrowser installs in the same location, the X-Apple-UserGuid
value changes across fresh installs but remains constant acrossrestarts of Safari. The X-Apple-GeoSession value is also
observed to remain constant across browser restarts. Fromdiscussions with Apple the X-Apple-UserGuid and X-AppleGeoSession values are randomised values generated by theuser device which are both reset every 15 minutes (by aprocess external to Safari, hence why they may not change
across restarts/fresh installs of Safari that occur within a
15min interval), and this is also consistent with Apple documentation [31]. We have proposed to Apple that this fixed
15min interval be replaced by a randomised interval sinceotherwise the potential exists to relink identifiers, and so searchsessions, by noting which identifiers change within 15 minsof each other (the chance being slim of two devices behindthe same gateway choosing exactly the same update time).
The X-Apple-GeoMetadata value appears to encode “fuzzed”
location [31] but we were unable to verify the nature of the
fuzzing used or the (in)accuracy of the resulting location value.
E. Microsoft Edge
Edge sends text to www.bing.com (a Microsoft search service)as it is typed. A request is sent for almost every letter typed,
resulting in a total of 25 requests. Each request contains
contains a cvid value that is persistent across requests although
it is observed to change across browser restarts. Based on
discussions with Microsoft, in fact its value changes between
search sessions i.e. after the user presses enter in the top bar.
Once the typed URL has been navigated to Edge then makes
two additional requests: one to web.vortex.data.microsoft.com
and one to nav.smartscreen.microsoft.com. The request tonav.smartscreen.microsoft.com includes the URL entered andforms part of Microsoft’s phishing/malware protection service [29], while the request to web.vortex.data.microsoft.com
transmits two cookies. From discussions with Microsoft thislatter call to web.vortex.data.microsoft.com is made uponnavigating away from the welcome page and so does not occur
every time a user navigates to a new page.

14

F. Yandex Browser
Yandex sends text to yandes.ru/suggest-browser as it is typed.
A request is sent for every letter typed, resulting in a totalof 26 requests. Each request is sent with a cookie containing
the multiple identifiers set on Yandex startup. Once the typed
URL has been navigated to Yandex then makes two additionalrequests: one to yandex.ru and one to translate.yandex.ru. The
request to yandex.ri sends the domain of the URL entered
while the request to translate.yandex.ru sends the text content
of the page that has just been visited.
VIII. C ONCLUSIONS
We study six browsers: Google Chrome, Mozilla Firefox,
Apple Safari, Brave Browser, Microsoft Edge and Yandex
Browser. For Brave with its default settings we did not findany use of identifiers allowing tracking of IP address overtime, and no sharing of the details of web pages visited withbackend servers. Chrome, Firefox and Safari all share details
of web pages visited with backend servers. For all three thishappens via the search autocomplete feature, which sends web
addresses to backend servers in realtime as they are typed.
In Chrome a persistent identifier is sent alongside these web
addresses, allowing them to be linked together. In addition,
Firefox includes identifiers in its telemetry transmissions thatcan potentially be used to link these over time. Telemetry canbe disabled, but again is silently enabled by default. Firefox
also maintains an open websocket for push notifications thatis linked to a unique identifier and so potentially can also
be used for tracking and which cannot be easily disabled.
Safari defaults to a choice of start page that potentiallyleaks information to multiple third parties and allows themto preload pages containing identifiers to the browser cache.
Safari otherwise made no extraneous network connections
and transmitted no persistent identifiers, but allied iCloud
processes did make connections containing identifiers.
From a privacy perspective Microsoft Edge and Yandex are
qualitatively different from the other browsers studied. Bothsend persistent identifiers than can be used to link requests(and associated IP address/location) to back end servers. Edge
also sends the hardware UUID of the device to Microsoft
and Yandex similarly transmits a hashed hardware identifier toback end servers. As far as we can tell this behaviour cannot
be disabled by users. In addition to the search autocomplete
functionality that shares details of web pages visited, bothtransmit web page information to servers that appear unrelated
to search autocomplete.
R EFERENCES[1] S. Englehardt and A. Narayanan, “Online tracking: A 1-millionsite measurement and analysis,” in Proceedings of the 2016 ACM
SIGSAC Conference on Computer and Communications Security, 2016,
pp. 1388–1401. [Online]. Available: https://doi.org/10.1145/2976749.
2978313[2] W. Meng, B. Lee, X. Xing, and W. Lee, “Trackmeornot: Enablingflexible control on web tracking,” in Proceedings of the 25th
International Conference on World Wide Web, 2016, pp. 99–109.
[Online]. Available: https://doi.org/10.1145/2872427.2883034[3] N. Bielova, “Web tracking technologies and protection mechanisms,” inProceedings of the 2017 ACM SIGSAC Conference on Computer andCommunications Security, 2017, pp. 2607–2609. [Online]. Available:
https://doi.org/10.1145/3133956.3136067[4] G. Aggarwal, E. Bursztein, C. Jackson, and D. Boneh, “An analysis ofprivate browsing modes in modern browsers,” in Proceedings of the 19th
USENIX Conference on Security. USENIX Association, 2010.
[5] N.Tsalis, A.Mylonas, A.Nisioti, D.Gritzalis, and V.Katos, “Exploring
the protection of private browsing in desktop browsers,” Computers &Security, 2017.
[6] “Google Safe Browsing API (v4),” 2020. [Online]. Available:
https://developers.google.com/safe-browsing/v4[7] “Chrome App AutoUpdate API,” 2020, accessed 21 Feb 2020. [Online].
Available: https://developer.chrome.com/apps/autoupdate[8] “Chrome Privacy White Paper (January 09, 2020),” 2020. [Online].
Available: https://www.google.com/chrome/privacy/whitepaper.html[9] “Firefox Telemetry API,” 2020, accessed 21 Feb 2020. [Online].
Available: https://firefox-source-docs.mozilla.org/toolkit/components/
telemetry/[10] “Firefox Normandy API,” 2020, accessed 21 Feb 2020. [Online].
Available: https://mozilla.github.io/normandy/[11] L. Sweeney, “k-anonymity: A model for protecting privacy,” International Journal of Uncertainty, Fuzziness and Knowledge-Based Systems,
vol. 10, no. 05, pp. 557–570, 2002.
[12] A. Machanavajjhala, D. Kifer, J. Gehrke, and M. Venkitasubramaniam,“l-diversity: Privacy beyond k-anonymity,” ACM Transactions on Knowledge Discovery from Data (TKDD), vol. 1, no. 1, pp. 3–es, 2007.
[13] G. P. and P. K, “On the Anonymity of Home/Work Location Pairs,” inPervasive Computing, 2009.
[14] M. Srivatsa and M. Hicks, “Deanonymizing mobility traces: Using social
network as a side-channel,” in Proceedings of the 2012 ACM conference
on Computer and communications security, 2012, pp. 628–637.
[15] Z. Weinberg, E. Y. Chen, P. R. Jayaraman, and C. Jackson, “I stillknow what you visited last summer: Leaking browsing history via userinteraction and side channel attacks,” in 2011 IEEE Symposium on
Security and Privacy. IEEE, 2011, pp. 147–161.
[16] ?ukasz Olejnik, C. Castelluccia, and A. Janc, “Why johnny can’t browse
in peace: On the uniqueness of web browsing history pattern,” in In Hot
topics in Privacy Enhancing Technologies, 2012.
[17] “appFirewall (v2.02),” 2020, accessed 21 Feb 2020. [Online]. Available:
https://github.com/doug-leith/appFirewall[18] “QUIC, a multiplexed stream transport over UDP,” 2020, accessed 21
Feb 2020. [Online]. Available: https://https://www.chromium.org/quic[19] A. Cortesi, M. Hils, T. Kriechbaumer, and contributors, “mitmproxy: A
free and open source interactive HTTPS proxy (v5.01),” 2020. [Online].
Available: https://mitmproxy.org/[20] “Yandex Safe Browsing API,” 2020. [Online]. Available: https://tech.yandex.com/safebrowsing/[21] T. Gerbet, A. Kumar, and C. Lauradoux, “A Privacy Analysis of Google
and Yandex Safe Browsing,” in Proceedings of 46th Annual IEEE/IFIP
International Conference on Dependable Systems and Networks (DSN).
The publisher of the proceedings, 2016, pp. 347–358.
[22] H. Cui, Y. Zhou, C. Wang, X. Wang, Y. Du, and Q. Wang, “PPSB:An Open and Flexible Platform for Privacy-Preserving Safe Browsing,”
IEEE Transactions on Dependable and Secure Computing, 2019.
[23] “Chromium Source Code,” 2020, accessed 21 Feb 2020. [Online].
Available: https://github.com/chromium/chromium[24] “Reference Implementation for the Usage of Google Safe Browsing
APIs (v4),” 2020, accessed 21 Feb 2020. [Online]. Available:
https://github.com/google/safebrowsing[25] “Issue 103243: Cookies no longer sent with safebrowsing,”
2011. [Online]. Available: https://bugs.chromium.org/p/chromium/issues/detail?id=103243[26] “Firefox Source Code (v 73.0),” 2020, accessed 21 Feb 2020. [Online].
Available: https://archive.mozilla.org/pub/firefox/releases/73.0/[27] “Firefox Push API,” 2020, accessed 21 Feb 2020. [Online]. Available:
https://mozilla.github.io/application-services/docs/push/welcom.html

15[28] “Brave P3A Telemetry API,” 2020, accessed 21 Feb 2020. [Online].
Available: https://github.com/brave/brave-browser/wiki/P3A[29] “Microsoft Edge Privacy Whitepaper,” 2020, accessed 6 March 2020.
[Online]. Available: https://docs.microsoft.com/en-us/microsoft-edge/
privacy-whitepaper[30] “Firefox Remote Settings API,” 2020, accessed 21 Feb 2020.
[Online]. Available: https://firefox-source-docs.mozilla.org/main/latest/
services/common/services/RemoteSettings.html[31] “Apple Privacy Features: Suggestions in Search and Safari,” 2020,
accessed 6 March 2020. [Online]. Available: https://www.apple.com/
privacy/features/