Someone cares about cookies in Android bloatware. And DPAs ?

L'analisi è riservata agli iscritti. Segui la newsletter dell'Osservatorio oppure il Podcast iscrizione gratuita 30 giorni

-

Eestimated reading time: 23 min 1 Cookies, Identifiers and Other Data That Google Silently Stores on ...

 

Testo riservato. Per iscriversi: all'Osservatorio - al Podcast (30 gg gratuito)

es on Android Handsets D.J.Leith
Trinity College Dublin, Ireland Feb 13th 2025
Abstract —We report on the results of a measurement study
investigating the cookies, identifiers and other data stored on
Android handsets by Google Play Services, the Google Play
store and other pre-installed Google apps. We find that multiple
cookies and identifiers are sent by Google servers and stored on
the handset, even when no Google apps have ever been opened
by the user. This includes advertising analytics/tracking cookies,
links and device identifiers. No ....... .. ...... ... ....... ...
of this data and there is no opt out. To the best of our knowledge,
this study is the first to cast light on the ....... ... ...... ..
pre-installed Google apps.
I. IN T RO D U C T I O N
This paper presents the results of a measurement study on
the cookies, identifiers and other data sent by Google servers
and stored on Android handsets by pre-installed Google apps,
including the Google Play Services and Google Play store
apps. To the best of our knowledge this is the first such study
and the first time that the data stored by these apps has been
publicly documented.
In summary, we find that:
1)Advertising analytics cookies, links to track clicks/views
of adverts, and device identifiers associated with advertising
are downloaded and stored on the handset.
2)Tracking ....... ... .......... ... ...... .. ... ......
Play store app, and then transmitted to Google servers along-
side analytics data reporting user interactions with the Play
store app (searches, page views etc).
3)The Google Android ID is sent by Google servers and
stored to the handset by Google Play Services. Previous
studies have shown this identifier is widely used in Google
Play Services and Google Play store transmissions to Google
servers (see, e.g. [1], [2]) and acts as a persistent device and
user identifier.
4)Analytics ....... .... ... ./. ....... .. ....... ..
Google apps are downloaded and stored on the handset by
Google Play Services, and then transmitted alongside app
telemetry data to Google servers.
5)Multiple other ....... ... ........... ..... ... ... ..
uniquely identify the handset and/or user are also downloaded
and stored on the handset.
No ....... .. ...... .. ..... ... ....... ... .. ..... .......
and other data, the purposes are not stated and there is no
opt out from this data storage. Most of this data is stored
even when the device is idle following a factory reset and no
Contact email: doug.leith@tcd.ie Google apps have ever been opened by the user i.e. they are
not set in response to services explicitly requested by the user.
The work reported here is inevitably limited in nature. A great
many different Google connections are made even when a
handset is lying idle, and we have analysed only a subset
of them (we focussed on those which tend to be frequently
recurring). Nevertheless, our measurements are already enough
to raise concerns that Google is violating EU data privacy
regulations, which generally require explicit and informed user
consent before data can be stored on a handset.
While this study focusses on Android handsets, this work
naturally raises questions regarding the data stored by pre-
installed Apple apps on iPhones. We leave that to future work,
but clearly there is an urgent need for such a study.
A. EU Data ....... ...........
We report on a technical study here, not a legal one, and we are
not legally qualified. Nevertheless, as already noted, the data
storage that we observe by Google raises obvious questions
regarding the EU e-Privacy Directive and perhaps also the
GDPR data protection regulations (the measurements were all
carried out within Ireland using handsets purchased in Ireland
and so it is Irish/European data regulations that apply).
1) EU e-Privacy Directive: The e-Privacy Directive was in-
troduced in 2002 1
and amended in 2009 2
. Article 5(3) of the
Directive is sometimes referred to as the “cookie law”. It
“recognises that the devices of users of electronic communica-
tions networks and any information stored on their devices are
part of their ’private sphere’ and that they require protection” 3
and was implemented in Irish law by Statutory Instrument No.
336 of 2011 4
. Its Article 5(3) restricts storage of data on a
handset, stating that “A person shall not use an electronic
communications network to store information, or to gain
access to information already stored in the terminal equipment
of a subscriber or user, unless (a) the subscriber or user has
given his or her ....... .. .... ..., ... (.) ... ..........
or user has been provided with clear and comprehensive
information in accordance with the Data Protection Acts which
(i) is both prominently displayed and easily accessible, and (ii)
includes, without limitation, the purposes of the .......... ..
1https://eur- lex.europa.eu/LexUriServ/LexUriServ.do?uri=CELEX:
32002L0058:en:HTML 2https://eur- lex.europa.eu/legal- content/EN/TXT/?uri=celex:32009L0136
3 https://www.dataprotection.ie/en/faqs/cookies/what- law- use- cookies,
accessed Jan 7th 2025. 4https://www.dataprotection.ie/en/who- we- are/data- protection- legislation,
accessed Jan 7th 2025.

2
the information” [3]. Exceptions are allowed when the storage
is “for the sole purpose of carrying out the transmission of a
communication over an electronic communications network”
or “strictly necessary in order to provide an information
society service explicitly requested by the subscriber or user”.
It is important to note that this regulation applies to any
information storage on a handset, not just cookies, trackers or
personally identifying/sensitive data, and that distribution of
tracking links to a handset constitutes storage [4]. European
Data Protection Board (EDPB) guidelines [4] also clarify
that (amongst other things): “terminal equipment” includes
smartphones and “storage” does not depend on the medium
and includes both RAM and SSDs nor is there any upper/lower
limit on the length of time that information needs to be stored
in order for it to count. Studies by regulators have highlighted
that the “strictly necessary” exemption should not be leniently
interpreted [5], and the .... ......... [.] .... ... .... .. .....
(i) the user must have taken a positive action to request a
service and (ii) the service does not work if the storage is
disabled.
2) GDPR: Roughly speaking, there are three main basis
under .... ... .... .......... .
: (i) the data is anonymised,
i.e. cannot reasonably be linked to an individual person,
and so is not personal data, (ii) with ....... ... . .......
purpose and (iii) for the legitimate interests of Google. Data
processing includes data storage and personal data includes
pseudonymous data if it is easy to identify someone from it 5
.
B. Data Storage By Google Apps
Table I summarises some of the data the we observed being
stored on a mobile handset by Google apps. Sometimes we
can reasonably infer the purpose by analysis of the data stored
and of the relevant Google app, in which case we have noted
this in the table. The table also gives the app, or apps, which
store the data and whether the data is unique to the individual
handset and/or user and so acts as a device/user identifer.
1) No Consent: Specific ....... .. ....... ...... ... .....
for the data stored by the Google apps that we observe, and
there is no opt out.
2) Purpose Not Stated: In almost all cases there is no Google
public documentation stating the purpose of the data storage.
The exceptions are the DSID and NID cookies, although the
public documentation relates to web browsers not Google
Android apps and we found the stated purposes vague and
unhelpful.
3) Not Strictly Necessary: Hardly any of the data in Table
I is strictly necessary for a service explicitly requested by
the handset user. The only exceptions are the Auth/Bearer
tokens used to authorize usage of Google services following
login to the user’s Google account. However, even in this
case we observe Auth/Bearer tokens being stored for (i) apps
which the user did not request and has never used, including
Gmail, Google Docs, Google Videos, Google Search, Google
Calendar and Google Chrome and (ii) Google Play Services
advertising ( DSID), telemetry ( Clearcut) and A/B testing
( Experiments ) subsystems which the user has never re-
quested.
5E.g. see https://gdpr.eu/what- is- gdpr/, accessed Jan 7th 2025. Name Type App Device/User
Identifer DSID Advertising Analyt-
ics Cookie Google Play Services,
Firebase Analytics ✓
AdAttest ..... ........... ......
ID Google Play Services ✓
Ad URLs Advert View/Click
Tracking Google Play store ✓
ServerLogs Analytics Cookie,
incl. adverts Google Play store ✓
Google
Android ID Persistent Device
Identifier Google Play Services,
Google Play store ✓
NID Cookie Google Play Services,
Google Search, Gmail,
Google Messages,
Google Files ✓
deviceKey Persistent Device
Identifier Google Play Services ✓
Auth/Bearer
Tokens User & Device
Identifier Google Play Services ✓
auth tokens Device Identifier Google Firebase ✓
GCM ID Device Identifier Google Play Services ✓
Widevine Key Device Identifier Google Play Services,
Google Chrome ✓
Experiment To-
kens A/B Testing Analyt-
ics Cookie Google Play Services ?
Server Tokens A/B Testing Cookie Google Play Services ?
App settings A/B Testing Google Play Services ?
TABLE I: Some of the data stored on handset by Google Apps.
4) Lack of Anonymity: As noted in Table I, much of the data
stored can act a device and/or user identifier and therefore
likely counts as personal information. .... ......... ......
applies as well as the e-Privacy Directive.
C. Response From Google
The Google Play Services and Google Play store apps studied
here are in active use by hundreds of millions of people. We
informed Google of our findings, and delayed publication to
allow them to respond. They gave a brief response, stating
that they would not comment on the legal aspects (they were
not asked to comment on these). They did not point out any
errors or mis-statements (which they wereasked to comment
on). They did not respond to our question about whether they
planned to make any changes to the ....... ... ...... .. .....
software.
D. Mitigations
Users currently have little control over the data that apps store
on an Android handset. It is possible to use the Settings app to
clear the data stored by an app. This deletes all the data in the
app’s data folder, and is akin to re-installing the app. There
is no ability to selectively delete ....... ..., ...... ......
a web browser, and no ability to prevent their storage in the
first place. The main mitigations are therefore to (i) disable
Google Play Services (not all handsets allow this), and (ii)
disable the Google Play store app. However, these are not
practical options for most users since third-party apps may
depend on Google Play Services and the Google Play store is
used by most people as the primary way to install third-party
apps.
E. Related Work
Since the introduction the EU e-Privacy Directive there has
been much interest in the presence/absence, validity and ef-
fectiveness of cookie ....... ....... .... ... ... ...........

3
studies [7], [8], [9] and investigations by the Irish Data
Protection Commissioner [5] and European Data Protection
Board [10]. There have also been several large-scale mea-
surement studies documenting the ....... ... .. ... .....,
e.g. see [11], [12], [13]. In contrast, there have been few
studies on the ....... ...... .. ....... ........ [..], ...
to the best of our knowledge none at all on the cookies
stored by Google apps and the Google Play Services app
in particular. Previous measurement studies on Android have,
instead, mainly focussed on analysing web traffic to detect
transmissions to tracking services or detect transmission of
sensitive personal identifiers e.g. see [15], [16], [17], [18],
[19], [1], [20], [2], [21].
II. EX P E R I M E N TA L SE T U P
A. Hardware and Software Used
Google Pixel 7 running Android 14 (build
AP4A.241205.013/12621605, the latest available) with
Google Play Services ver. 244738035 and Google Play store
app version 44.0.28-31 [0] [PR] 705297086; rooted using
Magisk v28.1. Frida server v16.5.7, Mitmdump v11.0.0.dev.
B. Measurement Data & Additional Material
An Additional Material document, the full measurement
data and the software tools we developed to analyse it
are available anonymously at https://github.com/doug-leith/
cookies-etc-stored-by-google-android.
C. Decrypting HTTPS Connections
We route handset traffic via a WiFi access point (AP) that
we control, configure this AP to use mitmdumpas a proxy
[22] and adjust the firewall settings to redirect all WiFi
HTTP/HTTPS traffic (other traffic is blocked) to mitmdump so
that the proxying is transparent to the handset. When a process
running on the handset starts a new network connection,
the mitmdump proxy pretends to be the destination server
and presents a fake certificate for the target server. This
allows mitmdump to decrypt the traffic. It then creates an
onward connection to the actual target server and acts as an
intermediary, relaying requests and their replies between the
app and the target server while logging the traffic. System
processes typically carry out checks on the authenticity of
server certificates received when starting a new connection
and abort the connection when these checks fail. For Google
apps and services, installing the mitmproxy CA cert as a
trusted certificate causes these checks to pass. We installed
the mitmproxy CA cert as a user cert and used the Magisk
trustusercerts module 6
to promote this to a system cert.
D. Analysis Tools Developed
1) Decoding & Tracing Received Data: Many of the re-
sponses from Google servers are encoded as protobufs.
Protobufs can be decoded without knowledge of the mes-
sage schema using the Google Protobuf compiler with the
--decode_raw option. However, this means that the in-
terpretation of values is missing and there is also sometimes
6https://github.com/lupohan44/TrustUserCertificates ambiguity as to interpretation of the value types. Since there
is no public documentation, to determine the meaning of
observed values we (i) decompile the Google app that receives
the data, (ii) identify the protobuf schema used to decode the
network response within the decompiled code (this step is
non-trivial since a Google app typically contains thousands of
distinct protobufs 7
) and then (iii) trace back within the code to
determine how the value of each entry in the protobuf schema
is used, whether and where it is stored on the handset disk,
and whether it is transmitted in later connections. This analysis
often reveals informative error and log message strings which
can help understand the data. When the data is named in such
message strings, we use that Google name here.
This is a fairly laborious process that is difficult to fully
automate since the code is obfuscated (classes, methods, fields
and variables all have randomised names) and due to (i) the
extensive use of multiple nested abstract and interface classes
within Google apps, (ii) the wide use of async abstractions
(Google’s extensions to Java futures) which spread processing
amongst multiple classes and break strong typing (data is
passed into async callables as generic Java objects, complicat-
ing variable tracing), (iii) serialising protobufs to byte strings
and arrays and .......... .... .. .... ... ...., .........
merging with other protobufs.
The software we have written to decode network requests and
responses (and which embodies much of the protobuf analysis
work carried out) is available on github https://github.com/
doug-leith/android-protobuf-decoding.
2) Exposing Google Auth ..... ..... .. .............:
When a user logs in to their Google account, Google apps and
subsystems ask Google Play Services to download authoriza-
tion tokens which are then used, for example, to gain access to
user data stored on Google servers. Google servers encypt the
tokens using a public key, previously sent to them by Google
Play Services. When it receives the tokens, Google Play
Services decrypts them using its private key. After decryption
the ..... .. . ...... ....... ........ .... ........ ........
HMAC content, which makes tracking of the linkage back
to the authorizing user account sllightly complicated since
the base64 ..... ........ ........... ........ .. .........
exposed the chain of authorization as follows. The private
decryption key is inacessible in the hardware keystore, so
we decompiled the Google Play Services, identified the Java
method carrying out the decryption and wrote a custom Frida
tool to dump out tokens before and after decryption. We then
decoded the ..... ........, .......... ... ......... .... ......
within it which acts as the actual basis for authorization, and
tracked that across network connections. See the Additional
Material for much more detail. The tools that we developed
are available in the anonymous dropbox folder.
3) Firebase Analytics Test App: To investigate transmission
of the DSID cookie we created a Google Firebase Analytics
account and an Android app linked to the account based on
Google’s exemplar analytics app. This app is available in the
7The protobufs themselves are encoded within the app in
compact protobuf format, which is undocumented although there
are useful comments embedded in the Android source code, see
https://cs.android.com/android/platform/superproject/+/master:external/
protobuf/java/core/src/main/java/com/google/protobuf/RawMessageInfo.java

4
anonymous dropbox folder. The Firebase Analytics dashboard
settings used were as follows: Google signals data collection
enabled, granular location and device data collection enabled,
user data collection acknowledged.
E. Test Design
1) Device Settings: At the start of each test we factory reset
the handset. Following this, the handset reboots to a welcome
screen and the user is then presented with a number of option
screens. We collected data for two choice of settings. Firstly,
to mimic a ....... ......... ...., .. ......... ... .. ...
options that asked to share data and only agreed to mandatory
terms and conditions. Specifically, we deselected the (i)“Use
location” option, (ii) “Allow scanning” option and (iii) the
“Send usage and diagnostic data” option. Note that there is no
option to deselect automatic updates which must be accepted
to continue. Secondly, we left all the options at their default
values i.e the (i)“Use location” option, (ii) “Allow scanning”
option and (iii) the “Send usage and diagnostic data” option
were left enabled. However, we did not observe any great
difference in the data stored on the handset for these two
choices of settings and mainly report results only for the
privacy conscious user. We did not log in to a Google user
account during the onboarding process. The handset had a
SIM card inserted, with an expired data plan so no cellular
data was sent.
Later in the tests we log in to a Google user account using the
Google Play store app (which cannot be used without logging
in). During onboarding after login, (i) at the “Welcome” screen
we click "I agree" (the only option), (ii) at the “Google
Services” screen the ....... ......... .... .... "......
device data" off (the default user leaves it on) then clicks
“Accept”. The Google user account settings were “Web &
App Activity” on, “Timeline” and “Youtube History” paused,
personalized ads and search personalization set off, location
sharing off.
2) Testing Protocol: The e-Privacy Directive allows data
storage for services explicitly requested by the handset user.
To avoid raising this issue, in our tests we make min imal use
of the handset. Folllowing factory reset of the handset the
user goes through the onboarding process and then leaves the
handset idle i.e makes no explicit service requests at all. After
about 24 hours the user logs in to a Google account using the
Google Play store app. This makes a request for service by that
app, but no more than that. The Google Play store app is of
particular interest since it is the primary means by which users
install other apps on the handset, and so fundamental to the
usefulness of the handset. We also opened the Google Dialer
app (used to make/receive phone calls), the Google Messages
app (used to send/receive SMS messages), the Google Files
app (used to access files on the handset) and the Settings app
(used to see Google account settings).
In more detail, we: (i) factory reset the handset, (ii) go through
the onboarding process, (iii) enable developer options in the
Settings app, use adb to install the Magisk app and reboot, (iv)
install the mitmproxy CA cert as a user cert, use the Magisk
trustusercerts module to promote this to a system cert and
reboot, (v) connect the handset to a WiFi access point running
mitmdump to log network connections and their content, and GET
https://googleads.g.doubleclick.net/pagead/drt/m?is_lat=0 Request Headers:
authorization: Bearer ya29.m.Cqk...GZR // linked to user's Google account
user-agent: com.google.android.gms/244738035 // Google Play Services
Response Headers:
set-cookie: DSID=ACZ...kL4; expires=Fri, 03-Jan-2025 00:00:00 GMT; path=/;
domain=.doubleclick.net; Secure; HttpOnly; SameSite=none Fig. 1: Example showing response to
DSIDconnection that
sets the DSID cookie. POST
https://android.googleapis.com/auth Request Headers:
user-agent: com.google.android.gms/244738035 // Google Play Services
POST Body:
androidId=3c315701d87ecc5d&lang=en-IE&google_play_services_version=244738035&
sdk_version=35&device_country=ie&it_caveat_types=2&app=com.google.android.gms&
oauth2_foreground=1&Email=dougleith23sep@gmail.com&pkgVersionCode=244738035&
token_request_options=CAA4AVABYAA=&client_sig=389...788&
Token=aas_et/AKp...hrjr0=&consumerVersionCode=244738035&check_email=1&service=
oauth2:https://www.googleapis.com/auth/emeraldsea.mobileapps.doritos.cookie&
system_partition=1&assertion_jwt=eyJ...sPA&callerPkg=com.google.android.gms&
check_tb_upgrade_eligible=1&callerSig=389...788
Response Data:
grantedScopes=https://www.googleapis.com/auth/mobileapps.doritos.cookie
it=AVo...llg
TokenEncrypted=1
<...>
Fig. 2: Example showing
Authconnection fetching authoriza-
tion/bearer ..... .... .. ..... ...............
then leave the handset idle and connected to power for about
24 hours. On the second day we log in to a Google account
using the Google Play store app and observe the effect on
the network connections made. In more detail, we (i) use adb
to run a Fridaserver8
on the handset and launch a custom
tool to dump out Authtokens after they are decrypted within
the Google Play Services app, (ii) open the Google Play store
app and login, (iii) perform some searches with the Google
Play app, (iv) open the Google Dialer app and try to make
a phone call, (v) open the Google Messages app and try to
send a message, (vi) open the Google Files app and navigate
to the Downloads folder, (vii) open the Settings app and use
it to view Google account settings, (viii) use adb to install a
custom Firebase Analytics test app and open the app.
III. ME A S U R E M E N T RE S U LT S
To aid the expositiion, a brief summary is given at the end of
each section below.
A. ....... ..... ........... ...... .. ...... .... ........
1) DSID Advertising Tracking Cookie: Shortly after the user
logs into their Google account, Google Play Services makes a
DSID connection to googleads.g.doubleclick.net/pagead/drt/m
which sets a DSID cookie, e.g. see Figure 1. The cookie is
stored in file shared_prefs/social.account_doritos.xml within
the Google Play Services app’s data folder /data/users/0/com.
google.android.gms.
The DSID request which fetches the cookie sends an http
authorisation header. This header contains a bearer
token, which is sent to the handset in response to an earlier
Auth connection to https://android.googleapis.com/auth, see
Figure 2. This Authconnection sends the user’s Google
account email together with an authentication ..... ...... ..
the account (it is sent to the handset by Google servers during
the account login process, see Additional Material for more
details). The DSID cookie is therefore directly linked to the
8Frida https://frida.re/ uses the Android system debugger API to facilitate
interception of Java function calls.

5
POST
https://region1.app-measurement.com/a Request Headers:
user-agent: com.google.android.gms/244738035 // Google Play Services
POST Body (decoded):
<...>
event_code: "_vs" // screen_view
event_timestamp: 1734728927324
<...>
event_code: "_e" // user_engagement
event_timestamp: 1734728932076
<...>
package_name: "com.google.firebase.quickstart.analytics_notset"
google_ad_id:"d4a1aab9- f57a- 43f0- a138- 60fd1af33913"
cookie: "DSID=ACZ...kL4"
Fig. 3: Example showing Firebase Analytics connection trans-
mitting the DSID cookie, together with the Google Ad Id.
user’s Google account. Inspection of the Google Play Services
code also confirms that the DSID cookie is directly linked to
the Google user account (e.g. it is retrieved from the handset
storage by presenting the user account name).
The DSID cookie is almost certainly the primary mechanism
via which Google links analytics and advertising events (e.g.
ad views and clicks) to an individual user. To demonstrate
its operation we created a Google Firebase Analytics account
and an Android app linked to the account based on Google’s
exemplar analytics app. When the Google Signals option is
enabled on the account dashboard, we observe that the DSID
cookie is sent in Firebase Analytics connections logging user
interactions with the app. See, for example, Figure 3. The
DSID cookie allows the event (in this case the user viewing
a screen within the app) to be linked to an individual user
via their Google account. It can be seen that the Google
Advertising Id is also sent alongside the DSID cookie.
Google”s public documentation on the Google Signals option
and the DSID cookie is, unfortunately, rather vague and
is not as helpful as it might be. A Google cookie policy
document 9
states that “Some ....... ... ....... ............
used for advertising are for users who sign in to use Google
services. For example, the ‘DSID’ cookie is used to identify
a signed-in user on non-Google sites so that the user’s Ads
Personalisation setting is respected accordingly”. A Google
Analytics 4 “Activate Google signals for Google Analytics
properties” help page 10
states that “Google signals are session
data from sites and apps that Google associates with users who
have signed in to their Google accounts, and who have turned
on Ads Personalization. This association of data with these
signed-in users is used to enable cross-device remarketing,
and cross-device key events export to Google Ads”.
No ....... .. ...... .... ... .... ...... ....... ... ....
cookie on the handset, and there is no opt out. The DSID
cookie is used for marketing/advertising analytics. Since the
DSID cookie is personally identifying, .... ...... ........
DSID advertising analytics cookie, sent by googleads.g.
doubleclick.net and stored by Google Play Services in
shared_prefs/social.account_doritos.xml, transmitted in Fire-
base Analytics connections. Stored after user logs in to
Google account. 2) Google Android ID Persistent Device Identifier:
Following
a factory reset and with the user not logged in, the Google
9https://policies.google.com/technologies/cookies, accessed 4th Jan 2025.
10 support.google.com/analytics/answer/9445345, accessed 4th Jan 2025. POST
https://android.googleapis.com/checkin POST Body (decoded):
imei: "358287589858647" // identities handset sim slot
hardwareSerialNumber: "36141FDH20008V" // identifiers handset
androidId: 0 // iniitally zero, later updated
securityToken: 0 // iniitally zero, later updated
accountCookie: "" // iniitally empty, later user Google a/c email, NID cookie