Section: Technology & AI Author: V Reading time: ~27 min Sources and further reading: 22 items Topics: smartphone, privacy, apps, operator, GDPR, Apple, Google, NÚKIB SEO / working title: What does your mobile phone know about you?
What does your mobile phone know about you? The question sounds simple only until we notice that we are not comparing one thing. A device can have an IMEI and the account can still survive a change of handset. Timeline location can be off and a location from another activity can still remain. An operator may, under Czech law, retain traffic and location data for 6 months and still not read the content of an end-to-end chat.[13] A seven-day App Privacy Report can show microphone accesses without being a picture of the whole history since purchase.[7] The following text therefore does not ask what “the phone knows”. It asks which layer knows what — and which controller to ask.
1. Takeout, seven days of a report, and an extract from the operator are not one file
Imagine one person and three exports. First they download data from their Google account through Takeout. Then, on an iPhone, they turn on App Privacy Report and for a week watch apps’ accesses to location, camera, microphone and contacts. Finally they ask the operator, under Article 15 GDPR, for data that relate to their contract and traffic.[3][7][15]
At first glance this is one dispute: what the phone knows about them. In fact each output answers a different question. Takeout describes the account and the services the user chooses to export. App Privacy Report describes app accesses and network activity for the last 7 days after the report is turned on; Apple states that the data are encrypted on the device and that the report is deleted when it is turned off.[7] The operator describes the subscriber relationship, traffic data and location data in the regime of the Electronic Communications Act.[13]
They can therefore all be partly right and the shared sentence still wrong. A user who sees search history in Takeout is right that an account can contain a sensitive trail. A user who sees frequent location accesses in the report is right that apps can reach sensors. The operator is right that it does not retain the content of messages under the regime of § 97(3). The error arises only when these layers are made into one all-knowing file.
The first distinction is therefore not whether the phone is smart. It is who is the controller of a particular layer. That is not word-play. If we ask the wrong controller, we get a correct answer to someone else’s question.
The phone does not know everything. Different layers know — and each has a different controller.
— Jiný Kontext
2. A phone has at least six layers
When people say “mobile”, they usually picture an object in a pocket. In data terms it is not one object. It is a node between the operating system, apps, an account, the network, advertising measurement, backups and other devices. Each layer has a different technical mechanism and a different law.
The first layer is the operating system and the sensors. GPS, Wi-Fi, Bluetooth, accelerometer, camera, microphone and the address book are not one socket. The system holds permissions over them. An app usually does not ask for “everything”, but for a particular access: location while in use, camera, microphone, contacts. For App Privacy Report, Apple describes that the report shows accesses to sensitive data and sensors and also the domains contacted over the last 7 days.[7]
The second layer is apps and their libraries. An app need not be only the programmer’s own code. It can contain an SDK for advertising, analytics, maps or sign-in. NÚKIB therefore recommends downloading apps from authorised stores and watching what they reach, especially in the case of suddenly popular apps.[10]
The third layer is a Google or Apple account. An account can survive a change of phone. It can be open in a browser, on a tablet and on a new device. Takeout is therefore not an extract “from the phone”, but an export of account data from selected services.[3]
The fourth layer is the operator’s network. Here the SIM, the subscriber contract, identification on the network, traffic and location data, and billing appear. Czech § 97(3) ZoEK works with a period of 6 months for the retention of defined data, but at the same time expressly separates the content of messages.[13]
The fifth layer is advertising and measurement. The Android Advertising ID is a resettable and deletable identifier; after deletion, according to Google’s documentation, zeros are returned.[6] Apple IDFA is, after iOS 14.5, available for tracking across third-party apps only after consent in the App Tracking Transparency regime.[8]
The sixth layer is backup and other devices. Photographs can be in the cloud, messages in a backup, a sign-in in the browser, devices in a family or company profile. The phone in the hand need not show the whole trail until we look at the account and the backups.
3. The best overview is the one whose gap you see before someone else’s request
Users often look for one switch and one extract. That is understandable, but incomplete. One location switch will not cancel every possible source of location information. One report for 7 days will not show history from before it was turned on. One request under the GDPR does not cover all controllers, because the data subject sends it to a particular person or institution, not to “the phone”.[15][16]
| Type of failure | What it looks like | How to test | What limits the harm |
|---|---|---|---|
| Confusion of layers | Takeout, the report and the operator are read as one profile | Compare three outputs of the same person | Always address the request to a particular controller |
| One location switch | Timeline is off, location remains in another activity | Check app permissions, Timeline, and Web & App Activity | Read Google’s notices about other location settings |
| The report as a complete history | A seven-day window is taken as data since purchase | Turn the report on and read it as a measurement after it is turned on | Do not infer a past that the report did not collect |
| Advertising ID as a permanent identity | AAID or IDFA is confused with IMEI or IMSI | Reset or delete the advertising ID, check ATT | Separate advertising from the network and the device |
| Chat content at the operator | It is expected that the operator has the WhatsApp text | Separate metadata under ZoEK from the content of the app | Do not attribute to the network keys that it does not have |
| Hygiene as a reset of the network | Uninstalling an app is taken as erasure at the operator | Compare NÚKIB’s recommendations with § 97 ZoEK | Reduce the risk of apps and deal with the network separately |
Interpretive scheme: This is not a ranking of risks. It is a map of places where one controller is often taken for another.
That changes the practical question. We do not ask whether we have enough data about ourselves. We ask whether we know which data are missing from the overview. An overview is useful precisely when it does not raise a false sense of completeness.
A good overview should therefore not end with the export. It should end with a question about absence. In Takeout I do not see the operator’s traffic data; that is not a failure of Takeout. In App Privacy Report I do not see what an app sent before the report was turned on; that is not proof that it did not happen. In an extract from the operator I do not see the body of an end-to-end chat; that is not a gap in the network, but a property of a separate app. Every output should be read not only for what it contains, but also for what it cannot, in principle, contain.
4. The device is not the account
IMEI identifies a mobile device. GSMA, in the standard TS.06, describes IMEI as a unique identifier of mobile equipment; it is the identity of a handset in the technical layer of the network, not a person’s name in civic life.[19] A Google or Apple account is a different kind of identity. It signs the user into services, backups, photos, history and purchases. It can move to a new phone, and the old handset can be wiped.
From that it does not follow that IMEI is meaningless. It follows that it does not answer the same question as an account. When an operator sees a device on the network, that does not mean it sees the whole content of a Google account. When Google allows an account to be exported through Takeout, that does not mean it provides an extract of everything that happened on the operator’s radio network.
The practical error is simple. A person sells a phone, buys a new one, and believes they are starting from zero. The handset can be new. The account is not. History in the account, synchronised contacts, photos and settings can continue. Conversely a person can wipe the phone and still have data in the account. The same word “mobile” here covers two different things.
A cleaner sentence is: the device is a carrier and a party to technical relationships; the account is a longer-lived identity of a service. Sometimes they overlap. They are never the same thing.
5. The OS is not the app
The operating system sets the frame. It manages permissions, shows warnings, and allows accesses to be granted, limited or withdrawn. An app in this frame asks for a particular capability. It may need it for a legitimate function. Maps without location work differently from maps with location. A video call without a camera stops being a video call.
That does not mean every permission is reasonable. A torch app does not need contacts. A game need not necessarily know a precise location. In its recommendation on suddenly popular apps, NÚKIB points precisely to caution with permissions that are unrelated to the purpose of the app, and to the choice of authorised stores.[10]
For App Store privacy labels, Apple distinguishes data used to track, data linked to the user, and data that are not linked to the user.[9] That is not a guarantee of the faultlessness of every app. It is an attempt to describe the data flow beyond the “allow” button itself. And that is where the next layer begins: the developer, an analytics SDK, an advertising network and a server.
The OS is therefore not the app. The system can force a question and show a report. It need not itself know the commercial reason why an app collects data, nor how its operator will use them after they are sent to a server. When checking one’s own phone it is therefore necessary to read both columns: what the system allowed, and who the app belongs to.
The same permission icon can mean different situations. A navigation app may need location for a route. A weather app may make do with a city. A loyalty-programme app may want location for marketing. The system dialogue usually does not tell the whole business model. It says which technical gate is opening. Whether the opening is proportionate, the user must judge from the purpose of the service, the trustworthiness of the developer, and whether the permission can be narrowed.
6. Location has more switches than one toggle shows
Location is among the data for which we most quickly create a false certainty. We turned off location history, so Google no longer stores location. Google’s documentation, however, warns that turning off Timeline or location history by itself need not stop the storing of location data from other settings and sources, for example from Web & App Activity, from Maps, from photos or from an IP address.[4][5]
This is not one secret trick. It is a property of layers. An app’s precise location, an account Timeline, a location inferred from search, and a location from an IP address are not the same switch. Each arises differently and each is managed somewhere else.
CZSO, in the VŠIT 2025 survey, reports that 52% of persons aged 16+ in the Czech Republic have at least once changed access to the geographic location of a device.[1] That figure measures a declared change of access among persons 16+ in private households in 2025. It does not measure whether they currently have location on, how many apps use it, or whether it is precise or approximate location.
How to test location
On one’s own phone it makes sense to go through three places. First, Location permission on individual apps. Second, Timeline or location history in the Google account. Third, Web & App Activity. If some overview claims that “location is off”, it is necessary to ask: which location, in which account, and for which service?
One location switch is not enough. Google says so expressly.
— Jiný Kontext
7. An advertising ID is not a birth number
An advertising identifier is useful precisely because it is not the same thing as a permanent device number. The Android Advertising ID can be reset or deleted; Google Play policy states that after deletion apps are returned zeros.[6] Apple IDFA is, in the App Tracking Transparency regime from iOS 14.5, iPadOS 14.5 and tvOS 14.5, tied to consent to tracking across third-party apps and websites.[8]
From that it does not follow that advertising disappears. It follows that a particular path of tracking is limited or must have consent. An app can show contextual advertising, can measure its own service, can work with a signed-in account. ATT is not a ban on advertising. It is a rule for certain tracking across apps and data brokers.
Likewise an advertising ID is not IMEI, IMSI or a telephone number. IMEI belongs to the device.[19] IMSI belongs to the SIM and the network. A telephone number belongs to the subscriber relationship. An advertising identifier is a layer of measurement and advertising. When these layers are mixed, an alarm sentence appears that one app knows “the identity of the phone”. Sometimes it knows an account. Sometimes an advertising ID. Sometimes a permission. Each case has to be taken apart separately.
Google Play also forbids using other permanent identifiers as a substitute for the advertising ID for advertising purposes if the user has reset or deleted the advertising ID.[6][21] That is a rule of an ecosystem, not a law of nature. Its meaning stands on enforcement, audit and the behaviour of particular apps.
8. App Privacy Report is not a forensic image
App Privacy Report on an iPhone is a strong tool for one’s own inventory. It shows apps’ accesses to location, photos, camera, microphone, contacts, and the domains with which apps communicate. Apple describes it for iOS and iPadOS 15.2 and later; the report concerns the last 7 days, the data are encrypted on the device, and collection starts only after it is turned on.[7]
Precisely this precision is its limit. Seven days is not since the phone was bought. The report is not a record of everything an app has ever sent to a server. Turning the report off deletes the data.[7] When a user therefore turns the report on on Monday and on Wednesday sees no suspicious activity, they can say only this much: in this window and with this use, the given activity did not show.
That is not a weakness of the tool. It is a correct description of its scope. A forensic image would address other questions, other authorisation and other procedures. This text is not a guide to circumventing a lock, a PIN or encryption. App Privacy Report belongs to the inventory of one’s own device. It helps one see which apps reach sensitive places, but it does not replace a request to the operator of an app, nor an export of an account.
What needs to be tested
On an iPhone it makes sense to turn the report on and use the phone in the ordinary way for a whole week. On Android it is necessary to go through app permissions and the advertising ID in settings. In both cases the test measures one’s own trail. Not someone else’s device, not the circumvention of someone else’s account, not police work.
9. A backup is not the phone
A phone can be empty and an account full. It can be broken and a backup alive. It can be in a pocket while photographs are meanwhile synchronising to the cloud. That is why it is misleading to ask only what is physically in the device.
Google Takeout allows data to be exported from selected services of an account.[3] Apple offers overviews and tools within the privacy and security of an account.[9] The user thus sees a different layer from when they open the phone’s settings. They may find data that are no longer on the device, or conversely find that something remains only locally.
A backup also changes the security question. When content is protected end-to-end, the service controller need not have readable content available. When it is not protected, or when the user uses an older setting, the scope can be different. This article does not add new figures on the share of backups or on the number of gigabytes, because the dossier does not contain such data. That is more precise than an estimate.
The practical sentence is: if I am interested in the phone, I must also ask about the account and the backup. If I am interested in the account, I must not automatically infer from it the state of every device.
A backup is also a frequent place of family misunderstanding. One person deletes a photograph from the phone and means “I deleted it”. Another finds it on a tablet or in the web interface of the same account. Both can be right according to the layer they are looking at. It is therefore more precise to speak of deletion on the device, in the account, in the service’s bin and in the backup separately. The GDPR knows a right to erasure under conditions, but even there the request is aimed at a controller and a particular processing, not at the physical feeling that we are holding one handset.[15][20]
10. The operator does not read WhatsApp
The operator sees the network layer. It keeps a subscriber contract, billing, traffic data and defined location data. Czech § 97(3) of the Electronic Communications Act requires providers to retain traffic and location data for 6 months; at the same time, in this regime, it is expressly not a matter of retaining the content of messages.[13]
That is a substantial cut. Metadata of a call, an SMS or a data connection are not the body of a message in a chat app. End-to-end encryption separates content from the network that carries packets. An operator can provide connectivity and still not have the key to the content of a conversation in WhatsApp.
From that it does not follow that metadata are innocent. Who communicates, when, from where and how often can be sensitive even without the text of a message. It does follow, however, that the sentence “the operator reads WhatsApp” confuses the network and the app. If someone is dealing with the content of a chat, they must ask the app, the account, the device and the encryption settings. If they are dealing with a traffic trail, they look at the network.
This distinction also matters for a GDPR request. A request to the operator under Article 15 is aimed at data that the operator processes as controller.[15][16] It is not a request for an extract from someone else’s app.
11. Blanket retention of metadata is not the same as a duty from the Union
The Czech data-retention regime has its own legal dispute. The Supreme Court, in a press release on judgment 30 Cdo 2556/2025 of 8. 1. 2026, stated that the Czech blanket arrangement for retaining data on electronic communication is contrary to Union law.[14] A commentary by Iuridicum Remedium reminds us that such a decision does not itself mechanically rewrite the text of the Act or every practice of operators.[22]
That means two things at once. It is not precise to say that “the European Union requires the blanket retention of metadata”. The dispute is aimed precisely against blanketness. It is not precise either to claim that, from the Supreme Court’s press release, no network layer of retention exists. As of September 2026 the dossier works from the premise that the text of § 97(3) ZoEK formally still stands.[13][14][22]
For this article the main point is the separation of layers. Even if the operator’s legal regime changed, that would not make App Privacy Report into an extract from the operator, or Takeout into access to the network. One layer would change. Not the whole phone.
12. Takeout is access to an account. It is not access to the whole phone
The right of access under the GDPR is a strong tool, but not a magic key to all data in a digital life. Article 15 gives the data subject the right to obtain from the controller confirmation and information about processing; Article 12(3) provides for a reply without undue delay and as a rule within 1 month, with a possible extension of up to 2 months for more complex or numerous requests.[15]
The controller is particular. Google answers for selected services of an account. Apple for its services and account. The operator for the subscriber relationship and traffic data. The developer of an app for its own processing in the app and on the server. The EDPB, in its guidelines on the right of access, examines precisely the relationship between the data subject and the controller; it does not assume that there is one universal controller of “the phone”.[16]
Takeout is a practical example. Google describes it as a way to download data from an account and selected services.[3] It is not an image of the phone’s flash memory. It is not access to the operator’s data. It is not a guarantee that every third-party app will issue everything in the same way.
A good request therefore does not start with the sentence “send me what the mobile knows about me”. It starts with a map of controllers. To whom is the request aimed? Which account, contract or app is the subject? Which period and which category of data is sought? Precision in the query raises the chance that the answer will not be correct only formally.
13. Downloading an app does not measure what an SDK sends
CZSO in VŠIT 2025 reports that at least one app was downloaded in the last 3 months by 57.3% of smartphone users; in absolute terms that is 4,269.7 thousand persons, which corresponds to 49.1% of all persons aged 16+ in the given survey.[1] The figure is useful. It says that installing apps is an ordinary activity among a substantial part of smartphone users in the Czech Republic in 2025.
It does not say how many SDKs are in an average app. It does not say how many permissions users granted. It does not say whether an app sent data to a developer, an advertising network or an analytics service. And it does not say whether it was an app from an official store, or a sideload.
That is precisely why it makes sense to read NÚKIB’s recommendation beside the statistic. The statistic describes the extent of use. NÚKIB recommends caution with apps, authorised stores, updates, and restraint with permissions that are unrelated to the purpose of the app.[10][11][12]
The EDPB, in guidelines 2/2023 on the technical scope of Article 5(3) of the ePrivacy Directive, reminds us that the rule does not concern only cookies in a browser, but access in general to information in a terminal device and its storage.[17][18] Mobile apps are therefore not a legal vacuum merely because they are not a web cookie banner.
14. NÚKIB hygiene reduces the app layer. It does not reset the network
Security hygiene makes sense. Downloading apps from official stores, updating the system, reading permissions, deleting unused apps and watching suddenly popular services is reasonable. NÚKIB repeats these recommendations in materials for safe movement in cyberspace and for travel.[10][11][12]
The error arises when hygiene of one layer is read as the erasure of all layers. Uninstalling an app can reduce the risk of its further access. It need not delete data already sent to developers. It does not change the subscriber contract with the operator. It does not change the statutory regime for retaining traffic and location data under § 97(3) ZoEK.[13]
Likewise, resetting an advertising ID will reduce the continuity of advertising measurement in the given regime. It will not change the IMEI of the device, the SIM on the network, or a sign-in to an account. Turning off one location history does not mean that all location data in all services have disappeared.[4][5]
That is not a reason to give up. It is a reason to name what we are doing just now. App hygiene is work on the app layer. An account export is work on the account layer. A request to the operator is work on the network layer. Each has its own sense and its own gap.
This is precisely where good advice is told from false certainty. Good advice says which layer it reduces and which it leaves alone. False certainty promises that one step will erase a whole digital life. Neither uninstallation, nor a reset of an advertising ID, nor one location toggle can do that.
15. Figures on phone use do not measure the content of data
CZSO in VŠIT 2025 reports that a mobile phone was used by 99.1% of persons aged 16+ in private households in the Czech Republic, that is 8,610.0 thousand persons.[1] A smartphone was used by 85.8% of persons 16+, that is 7,456.3 thousand persons.[1] The internet on a mobile phone was used by 82.7% of persons 16+, that is 7,185.0 thousand persons.[1]
These figures have a clear strength and a clear limit. They measure the spread of devices and the use of the internet in 2025 in a defined population. They do not measure the content of data in phones. They do not measure the number of apps on an average device. They do not measure the share of iOS and Android in the Czech Republic in the tables the dossier read. They do not measure how much data is in a backup.
The age cut shows a further caution. At age 65–74 a smartphone was used by 67.5% of persons in the cohort and a button phone by 33.1% of persons in the same cohort.[1] For persons 75+ the dossier reports a smartphone in 34.8% in 2025, against 14.5% in 2019.[1] That is growth and a minority at the same time. Without this reservation, older persons could easily be described either as digitally excluded or as fully on smartphones. Neither figure by itself is enough.
A CZSO press release of 11. 11. 2025 reports that the internet was used daily by 81% of persons 16+ in the 2nd quarter of 2025 and, in the context of the release, recalls that the most frequent device is the phone.[2] Even that, however, is not a measurement of what the phone knows. It is a measurement of internet use.
16. An inventory of one’s own layers will say more than the sentence that the phone knows everything
A practical test is not meant to teach the circumvention of someone else’s lock, someone else’s account, or statutory procedures. It is meant to help a person find their way in their own trail. A safe inventory starts where the user has a right and access: at their own account, their own device and their own operator.
Three tests of one’s own trail
The first test is an account export. At Google that is Takeout and a choice of the services the user has in their account.[3] At Apple it is overviews and privacy settings in the account and on the device.[9] The result must be read as an account layer, not as the whole phone.
The second test is the device. On an iPhone, App Privacy Report can be turned on and the phone used in the ordinary way for a week; the output will show the last 7 days after the report is turned on.[7] On Android it makes sense to go through app permissions and the advertising ID, including the possibility of a reset or deletion.[6]
The third test is the network. A request under Article 15 GDPR is aimed at one’s own operator and concerns data that it processes as controller; the reply period under Article 12(3) is as a rule 1 month, with a possible extension of up to 2 months.[15][16] It is not a request about someone else’s subscriber.
If one controller really fused the operating system, the store, the account, advertising, the network and the backup into one file available from one request, the main thesis would weaken. The documentation of Google, Apple and ZoEK does not describe such one file.[3][7][13]
17. The hidden cost is one handset that we read as one file
A smartphone is practical precisely because the layers disappear from view. With one tap we open a bank, maps, messages, photos, a work chat, a shop, a backup and navigation. The user experience joins what is not joined in law and in technology.
From that a hidden cost arises. When something goes wrong, we do not know where to ask. A suspicion about an app we take to the operator. A location in an account we look for in a device toggle. An extract from the operator we read as the content of communication. A report for the last 7 days we read as a history since purchase. And a statistic on the spread of smartphones we read as a statistic on the content of data.
There is no need to claim that the phone is innocent. There is no need to claim either that it knows everything. The right question is more precise and less comfortable: which layer knows what, under which rule, at which controller, and how do we recognise what is missing from the answer?
Such a question is slower than an alarm headline. It has, however, one advantage. It leads to an action that can actually be performed: download one’s own account, go through permissions, turn on a report, reset an advertising ID, ask a controller, and note what each step does not address.
At the moment we hold a phone in the hand, we are holding a device. At the moment we ask about data, we enter a network of accounts, apps, advertising identifiers, operators and backups. And then the question is no longer: “What does your mobile phone know about you?”
It is: which controller holds which trail — and which layer have you just forgotten to check?
Related texts in this series
- How long does the operator retain data about your phone? — network metadata, not chat content.
- May the police search your mobile phone? — three regimes of seizure, content and interception.
- What is a digital footprint… — the phone is one layer, not a biography.