Google Location Services: does fortune still favor the brave?

In August, documents from the Google vs Arizona case were published. Many sections of these documents have been redacted but some interesting emails went though. In one of these emails a Google Software Engineer is puzzled by the way Android keeps prompting users to enable Google Location Services (a.k.a Google Location Accuracy). In this post, I detail how Google nudges Android users toward its own location service in order to collect their location data. Beyond the question of using nudges to collect more data, I discuss the compliance of these with EU regulation. Finally, by this self-preferencing services through which they collect location data, Google get an edge over competing Android location-based services.


Android phones have more than one location settings, one of these settings is the main switch that controls if the phone can estimate its location and there are 5 other settings that control more specific options which most users don’t care about. One of these neglected settings control the “source” used to estimate the device location :

  • GPS works great outdoor, but not so well indoor
  • Google Location Services (GLS) are more sophisticated : they combine GPS with information from mobile networks and the device sensors. GLS are part of the Google Play Services, a set services and APIs that are installed on most Android smartphones and on thoses smartphones, GLS are enabled by default.

To sum-up: the Android Location setting controls if your phone can estimate its location and the Google Location Services setting controls how your phone determine its location : GPS or GLS .

The GLS provides a faster and more accurate device location (at least according to Google), but there is a price to pay for that and not surprisingly, this price is paid with data : through the Google Location Services, Google collects location data that are used to improve its location-based services. Also not so surprisingly, users are nudged towards the Google Location Services instead of GPS. Enabling GLS by default is one of these nudges, but it’s not the only one.

Easily opt-ing in, not so easily opting-out

The Google Location Services are enabled by default on most Android phones and it is quite hard to disable them. The fastest way is to turn off the Android Location settings but that means loosing the benefit of all location based services and apps. The other solution is to switch from GLS to GPS but it’s more complicated and, to some extent, it feels like it has been harder with every new Android version.


On Android 10 from your home screen, it takes at least 5 clicks to opt-out from Google Location Services.

Here is the Android 10 walk-through to switch from GLS to GPS: open the Android Settings, then the Location Settings, and then the Advanced Settings, then click on “Google Location Accuracy” and finally disable the Google Location Services.

That’s at least five “clicks” with one that could clearly have been avoided: the settings hidden under “Advanced Settings” section are not more advanced than the “Wifi and Bluetooth scanning” option that is directly visible in the location section. It is not clear to me why those settings are not directly visible in the location setting.

As a matter of fact, device manufacturers have modified the location menu and show directly all the settings, thus saving you one click. I tested devices of a few brands in a retail store: devices from Oppo, Xiaomi and Samsung directly show all the settings in the location menu. Devices from Sony, OnePlus and Nokia kept the original location settings organization thus requiring 5 clicks to opt-out.

GLS consent popup

Much simpler to opt-back in : just clicking OK on a popup appeared in a middle of an app re-enable GLS almost permanently.

As noted by a Google engineer, it is too easy to enable Google Location Services, even when you don’t want to. Even users who’ve managed to opt-out of Google Location Services are likely to opt-back in when they use apps that need access to the location. When the Android Location setting is off, enabling location within an app such as Google Maps, Waze or even Citymaper will make a small popup appear asking you to confirm that you want to “turn on device location which uses Google Location Services”. Sometimes, this popup will appear if you just visit Google Search.

If you click “OK”, the Android Location setting AND the Google Location Services will be enabled permanently (i.e. not limited to the time you use the app). Even after you disable the Android location setting, GLS will remain the selected source to determine the device location. The first time you click OK, you may see an additional popup, explaining that Google may collected anonymous data and asking you to confirm, but this popup may appear only once on a given device.

The first time a user re-enabled the GLS, a popup may appear with more details about the fact that enabling GLS implies that Google may collect data and use them in an anonymous way. It seems that this popup appears only one time on a given devices, in my experience the popup never re-appeared.

Once you’ve click “OK”, the location will be enabled and the GLS as well. To switch back from GLS to GPS you’ll have to go through the 5 clicks again.

Minimal information

Not only it is much simpler to enable GLS than to disable them, but the information users get before they re-enabling GLS is amazingly poor. Yet this consent box triggers the collection of users location data by Google. It is worth analyzing the two layers of information provided by Google.

Google Location Services popup appearing within an app. The”details” (on the right screen) appear after clicking on the arrow on the left screen.

When the pop-up is displayed, the text only says “To continue turn on device location, which uses Google location services”. This text appears even when the devices is configured to use GPS instead of the Google Location Services, so the text should be “Continuing will turn on device location and uses Google’s Location Service instead of GPS“. That small imprecision is just a detail though.

Users have to click on the small “arrows” at the end of the sentence to learn that, if they click on OK, “Google may collect location data periodically and use this data in an anonymous way to improve location accuracy and location-based services [emphasize mine] . Two details are worth discussing in this sentence:

  1. The data are collected and processed for two different purpose : First, they are used to improve the location accuracy (i.e. the service requested by the user). Second, Google uses them to improve their location-based services. These purposes are bundled, it’s not possible to have one without the other.
  2. The location data collected by Google are not anonymous, they are used in an anonymous way.

Google should obtain a valid consent

While GDPR does not require all processing to be based on consent, in the case of location data the ePrivacy directive applies. Especially article 9.1 :

“Where location data other than traffic data, relating to users or subscribers of public communications networks or publicly available electronic communications services, can be processed,such data may only be processed when they are made anonymous, or with the consent of the users or subscribers to the extent and for the duration necessary for the provision of a value added service [emphasize mine].”

Unless they are anonymizing the data (they probably don’t, see the Privacy Nerd section bellow), Google has to obtain a valid user consent to the processing of his location data. It’s not clear to me that the popup displayed within apps is enough to obtain an informed consent.

“Scale helps make [Google] product better”

With GLS, Google certainly collects more data than any other Android location services and uses them to improve location-based services. Some of these services are good for everyone like the earthquake detection system released in 2020. But Google most certainly also uses these data to improve drive to store accuracy (although drive to store is only reported for users who enabled location history), to predict traffic and suggest itineraries.

As Google explained it in 2009

“Ever since GPS location started coming to mainstream devices, people have been thinking of ways to use it to figure out how fast the traffic is moving. But for us to really make it work, we had to solve problems of scale (because you can’t get useful traffic results until you have a LOT of devices reporting their speeds)[emphasize mine]”

A competing location-based service running on Android is very unlikely to get access to more location data than Google. Indeed, it is very complicated for an incumbent to obtain Android location data without Google being in the loop. Clearly, Google is leveraging its control over Android to collect location data in order to improve its services. The prevalence of the Google Location Services gives Google an edge over all other location based services ranging from traffic prediction to location based advertising.

As conceded by Google in the 2009 blogpost:

“Google is fortunate to have a lot of people using our products, and that scale helps make our products better.”

Fortune favor the brave. Back in 2009, Google may have been fortunate, but now it seems Google products are favored by the operating system.

Thanks to Franck Baudot for reviewing a draft,

For privacy nerds: hints that these data are not anonymized

Google could delete the data right after they estimated the device location, but to “improve location based services” they need to keep these data for a while. So if they want to keep them without consent, they have to anonymize them.

Very little documentation explains what data is processed by GLS. In a response to Senators Richard Blumenthal and Edward J. Markey enquiry, Google explained in 2018 that “GLS is linked to a temporary and rotating device identifier that is not used by or shared with other services”.

Let’s pause on this for a moment. When you use Google Location Services you send your accurate location to Google but it won’t be attached to your ID, it’s linked to “a temporary device ID”. How temporary is this device ID is quite important: if this ID remains the same for a few hours, it’s clear that it can be linked back to your identity, especially by Google who already collects a lot of data.

The second hint that GLS data are not anonymized is a subtle change in the language used to describe the GLS. Between 2017 and 2018 Google rephrased the description of the data collected by GLS and replaced the sentence “anonymous location data” by “data used in an anonymous way”. While, subtle, this change tends to confirm that Google no longer consider that data processed in the context of the Google Location Services are anonymous.

We can observe this change by comparing the “location popup” appearing on older version of android (on the left) with the details that appear in current versions (on the right).

A similar change in the way things are phrased can be observed between the setup screens of the Pixel 2 smartphone in 2017 and of the Pixel 3 XL which was released in 2018.

This changed may have been caused by the entry in application of GDPR which definition of “personal data” is more extensive than the one used so far in some EU counties and includes location data. Considering the GDPR definition of “personal data”, Google may have realized that they were not processing anonymized location data.

Could P2B force Apple to be more transparent about iOS APIs?

The Platform-To-Business regulation started to apply on July 12th. This regulation aims to shed more light on the relations between platforms and companies P2B. The regulation scope includes app stores. In this post I am interested in P2B’s impact on Apple’s app store and iOS APIs.

The regulation “promoting fairness and transparency for business users of online intermediation services” (aka Platform-To-Business or P2B)[1] was adopted in June 2019 and started to apply on July 12th 2020. As its name suggests, this regulation tries to strike a bit of a balance between platforms (i.e. online intermediation services and search engines) and businesses. The scope of the regulation is relatively broad and behind the term online intermediation services, we find hotel booking platforms (e.g. booking, hotels, …), goods marketplaces (e.g. marketplaces of amazon, fnac, …) and application stores. The regulation also covers search engines.

As pointed out by Arcep[2], this regulation is a first step towards device neutrality. Yet, P2B’s impact on device seems limited since APIs are quite explicitly excluded from the scope of the Regulation … except where they are directly connected to an online intermediation service :

Technological functionalities and interfaces that merely connect hardware and applications should not be covered by this Regulation, as they normally do not fulfil the requirements for online intermediation services. However, such functionalities or interfaces can be directly connected or ancillary to certain online intermediation services and where this is the case, the relevant providers of online intermediation services should be subject to transparency requirements related to differentiated treatment based on these functionalities and interfaces [emphasize mind].

Some iOS APIs could be within the scope of the regulation because the possibility for an app to use certain APIs is decided when it is submitted to the App Store

The App Store as an API control point

To develop an application on iOS, developers are restricted in the APIs they can use: only public APIs are documented and open to third-party developers. There are private APIs that offer more functionalities but there are supposed to only be used by Apple applications.

Apple verifies that no private API is used at the time an app is submitted to the App Store. In the past, some apps have been able to bypass this verification but have subsequently been removed from the App Store[4] for violating the App Store’s terms of use[5].

The issue of opening these APIs is important since some of them may give a competitive advantage to Apple’s apps[3] but if they were open to everyone, it could harm iOS security and stability.

Some APIs (both private and public) require explicit permission from Apple (called “entitlement”) at the time the application is submitted to the App Store. If an entitlement called by an apps is not granted, iOS will not let the application use the protected API[6].

Thus, these APIs can be considered as directly connected to the App Store since it is the latter that acts as a control point.

One could then consider that the P2B regulation applies to the use of private or entitlement based APIs. In particular, Article 7 of the regulation requires platforms to describe the differentiated treatments they give:

  1. Providers of online intermediation services shall include in their terms and conditions a description of any differentiated treatment which they give, or might give, in relation to goods or services offered to consumers through those online intermediation services by, on the one hand, either that provider itself or any business users which that provider controls and, on the other hand, other business users. That description shall refer to the main economic, commercial or legal considerations for such differentiated treatment.
  2. […]
  3. The descriptions referred to in paragraphs 1 and 2 shall cover in particular, where applicable, any differentiated treatment through specific measures taken by, or the behaviour of, the provider of online intermediation services or the provider of the online search engine relating to any of the following: […]
(d)access to, conditions for, or any direct or indirect remuneration charged for the use of services or functionalities, or technical interfaces, that are relevant to the business user or the corporate website user and that are directly connected or ancillary to utilising the online intermediation services or online search engines concerned.

P2B’s article 7 could apply to APIs; if these APIs were used for privileged treatment, they could in some cases be subject to more transparency.

However, in as we will see below, this provision may only apply in a few cases.

The UBER case

UBER’s iOS app was given a privileged treatment: in 2017, it was discovered that Apple had granted UBER an entitlement for a private API allowing the app to read the screen content [7]. This exemption shows that it is possible for Apple to selectively offer privileges to certain apps without modifying its OS.

Apple did not particularly explain this decision and if it happened again today it could look like a textbook case for P2B, but surprisingly P2B could not apply. Indeed, P2B only applies to differentiated treatment that benefits the platform operator (either the provider itself or any user company controlled by that provider). Since Uber is not controlled by Apple, this privilege would not have to be justified according to P2B.

The Apple Pay investigation

Last June, DG-Competition opened two investigations about potential abuse of a dominant position by Apple [8]. One of them concerned Apple’s refusal to open the “tap and go” functionality to Apple Pay’s competitors. Indeed, only Apple Pay can benefit from this functionality and competitors consider themselves unfairly disadvantaged.

Unlike Uber, the service put forward (i.e. Apple Pay) is controlled by the company that deploys the online intermediation service. However, P2B only covers processing in relation to goods or services offered to consumers through these online intermediation services, and Apple Pay being integrated into iOS and is not accessible from the App Store.

In this context, it is not clear whether the P2B Regulation can apply.

Using Bluetooth in the background

Contact tracing applications that wished to use Bluetooth to detect proximity have found themselves limited on iOS due to the fact that applications can hardly use Bluetooth when they are in the background. States found themselves forced to make a choice: develop an application that would work less well on iPhone or use the API common to Apple and Google even if it did not correspond to their needs [9] and is only supported with the latest version of iOS (thus excluding 10% of iPhones users [10]).

For many, Apple’s motivation was to protect users’ privacy, but there is no evidence that this objective weighed well in Apple’s refusal. On the one hand, applications that tried to circumvent Apple’s restriction (and were accepted on the App Store) either undermined the security of smartphones by prompting users to leave them unlocked [11] or were more intrusive by using geolocation [12]. On the other hand, all official Apple documentation indicates that the restrictions were motivated by the desire to reduce the consumption of resources (battery [13] and memory [14]) of iPhones.

As of now, Apple’s design motivation remains unknown since the company did not communicate on the subject and therefore never justified its choice. Hence applying P2B regulations could be relevant.

Indeed, Apple allows access to several pre-installed applications from the app store. Even if the applications cannot be installed from the app store, they are nevertheless visible and compete with the services offered by third party developpers [15]. Moreover, some of these applications use Bluetooth even when running in background. This is notably the case of the “Find My” application which uses BLE in the background to allow iPhones to be found [16]. In these circumstances, Apple may have to justify restricting access to the Bluetooth functionality in the background.

A need for more transparency

The debate on contact tracing apps clearly demonstrates the value of transparency: justifying the architectural choices of the OSs. Indeed, Apple did not justify its choice to refuse to open access to BLE to contact tracing applications. This silence has not been criticized since the company has been set up as a white knight protecting privacy against the states. But in the absence of explanation, this posture is questionable. If it turns out that made that Apple’s design is justified by iPhones reserving or is not even justified at all, the debate would not be the same.

Featured image by Jay Goldman


[2] « Platform-to-Business » : un premier pas vers les terminaux ouverts dans le règlement européen !

[3] « Apple frees a few private APIs, makes them public »

[4] « Apple bans over 250 apps that secretly accessed users’ personal info »

[5] See section 2.1.5 on software requirements

[6] See section 2.3 of ,«iRiS: Vetting Private API Abuse in iOS Applications » par Zhui Deng, Brendan Saltaformaggio, Xiangyu Zhang, Dongyan Xu

[7] « Uber App Has Access to Special iPhone Functions That Can Record Your Screen »

[8] DG-Comp opened an investigation on access restrictions to NFC features:

[9] « Two reasons why Singapore is sticking with TraceTogether’s protocol »

[10] Apple’s Exposure Notification API requires iOS 13 whereas the French (StopCovid) and the Singaporean (TraceTogether) apps respectively works with iOS 11 and iOS 10

[11] « iOS a ‘major hurdle’ to contact tracing app »


[13] « Because performing many Bluetooth-related tasks require the active use of an iOS device’s onboard radio—and, in turn, radio usage has an adverse effect on an iOS device’s battery life—try to minimize the amount of work you do in the background. »

[14] « WWDC 2017: Because while your application is running in the background, the system may terminate it if it needs to free up more memory for the foreground application. » ( )

[15] « Apple Dominates App Store Search Results, Thwarting Competitors »

[16] « The Clever Cryptography Behind Apple’s ‘Find My’ Feature » /

Who pay for my data processing?

Last November I submitted a data access request to Google. One month later (which is the maximum delay to provide a first answer), Google informed me that my request would take some time process. Two months later Google offered another answer … and told me that they won’t be able to respond to my request.

The main objective of my data request, which is available bellow, is to obtain information about how I’m targeted on Google services. Ideally, I’d like to know which advertisers are using Google services to target me, how they are targeting me and eventually how much it costs them. Indeed, I’d like to put some “pressure” on the advertiser that rely on platforms which are not compliant with EU regulation. The best way to do it is to stop buying from these companies, hence the need to list them.

The reason I’m targeting advertisers is because they are the only stakeholders which can trigger immediate reaction from platforms like Google and Facebook. At the end of the day, they are the one paying the platforms  and I wanted to know who’s paying for the processing of my data.

Three months to get a PDF

My first observation is about when Google decided to respond: they always use the full extent of the delay allowed by the GDPR (see article 12-3).  While I could have understood that Google waited three months to process my request and retrieved the data, in they came back almost empty handed.

The only element that Google provided me is the list of advertisers that targeted me through “Customer Match” (i.e. the advertiser that uploaded my contact info to target me on Google). As far as I know, there is no simple way to get this data on Google, and indeed Google did not provide my a nice json file as it does on Takeout, but a pdf listing six advertisers. Funny enough, the document is marked “Google Confidential and Proprietary ».

When it comes to ad transparency, Google fares poorly compared to Facebook. The ad section of Facebook tells you a lot about the ads you’ve seen and how you’ve been targeted. The information may not be exhaustive as some ads are still missing, but at least, it’s quite simple to know who’ve targeted you using your contact info whereas Google just oppose a pdf file without much detail.

Nothing on the “Reminder ads”

Google does not offer any answer the the rest of my request. According to the response, the list of advertisers that are retargeting me on Google service is available on the “Ads Settings” page. I see no mention of such retargeting on this page. Actually, the page only contains a list of interests, almostall of them have been inferred from my use of Google services. The remaining of the answer explains me that it “does not maintain a database of every advertisement seen by a specific user. Account holders can visit My Activity to see the websites and apps they’ve visited on which Google ads were shown”.

So Google does not say that they don’t have the data I asked, they simply argue that it’s not sitting in a database. I guess, they know for each ad if I have seen it or not but it would be very resource consuming to go through all ads and check if my “cookie” saw the ad. While I understand that they did not search exhaustively which ads I have seen, they could have answered that sooner, it was not necessary to exhaust the legal delay.

Any idea?

Google did not provide me the data I was looking for but there could be other way to obtain the list of advertisers targeting me. Technically, it is possible to write a browser extension that would collect all the ads that I “see” on Google and would compile a nice page (like AdAnalyst for Facebook).

I will also request data more accurately. For instance, I could ask for each service separately, which advertiser targeted me. I’ll also ask what are the cookie IDs that were associated to my account and then ask which advertiser targeted these cookies.

Image de couverture par Jay Goldman

More on Chrome updates and headers

I’m not the only one who has been unpleasantly surprised by the way Chrome now handles logins on Google services (more on Techmeme). This new feature was unexpected, it was also not announced in Google post about the Chrome update, there is no simple opt-out, it makes the Chrome Privacy Policy outdated and it confusingly as creates different user experiences on Android and on desktop. Indeed, for your browsing activity to be linked to your Google account you must sign-in on the browser and enables browser synchronization. On desktop, signing-in to the browser is almost mandatory but synchronization is off by default, on Android sign-in is off by default, but as soon as you sign-in synchronization is enabled. This are about to get even more complicated as Google introduce a new features that sends data to Google even when synchronization is off.

The only document which announced all changes is the Chrome privacy whitepaper. I doubt many people read it, but it’s a treasure trove of info about Chrome features and interactions with Google services.

Google service integration

As, the Verge already explained, Chrome is turning into the new IE6 (in case you wonder, that’s not a compliment). Not only is Google making some services running faster on Chrome, the browser also sends information only to Google. Indeed, Google developed several headers that are only sent to Google to make the integration with the services even smoother.

You can see headers on Chrome using the developper tool. To see all headers, you’ll have to “Copy all headers” as HAR and past the result in a text editor (thanks to Gunes Acar for the tip), otherwise you’ll see only provisional header.

The x-client-data header

This is probably the most problematic header and I did not see it mention anywhere else than in the whitepaper. Most users are not aware of it but this is header sent with every request sent Google services (and only Google services) to do A/B testing. Google services include most Google domains, including Doubleclick. Even when Google is a third party, the header is sent. Because it’s a header and not a cookie, it is sent even when you block cookies. The only way to not send it is to turn-on “Incognito Mode”.

If you have disabled usage statistics and crash reports, this header might not be used to track you without additional info. But the whitepaper is unclear about how this header is updated to describe “server-side experiments“ so I wouldn’t bet on it.

So not only this header may have some privacy implications, it makes the browser not neutral as it gives more data to Google services.

See for more details

Consistency/Connected headers

As mention in the chrome whitepaper, this header is sent to some Google servers. Most of the time, this header does not contain any identifier and is a low entropy cookie.

Only from time to time it includes your Google account number. Looking at Chromium source we get more details about how this header is used: it is used to redirect some action to the browsers UI instead of the content.

It may not have privacy implications yet, but it means that Chrome will benefit from integration with Google services that other services could not have.

New settings

The latest update mentions two features that are only tested on a subset of users. These features are more or less on opt-in basis (see bellow) and send data to Google when you’re signed-in, even when synchronization is off. These data are used to make personalized suggestions and improve the “general browsing experience”.


Actually, no need to be in the test group. You can use this feature on Chrome Canary. Once you’ve installed the browser, just sign-in and you’ll see this “opt-in” dialogue. If you accept or click on “Settings”, you’ll have access to the “Sync and Google services” section in the settings page.

Notice that if you click on “Settings”, all settings will be on by default, including sync.


By “forcing” users to sign-in to Chrome and by using custom headers, Google is less and less dependant of third party cookies. I would not be surprised if Chrome started to block third party cookies. Actually this may be in Google financial interest to do that.

Finding a balance between access to info and privacy

Disclaimer: Until September 2017 I was a Technologist at  (CNIL) the French DPA working on the technical aspects of issues like the right to be forgotten.

On June 28, a decision of European Court of Human Rights reanimated the debate about the Right To Be Forgotten. The court rejected the request to delete some content on a website, considering that the right to access to information prevailed. The court made an interesting distinction with the Right To Be Forgotten applied to search engines. Search engines and publishers have different purpose so the ECtHR refers to ECJ decision for the search engines.

Because the decision on the Right To Be Forgotten is sometimes misunderstood, I try to explain why, in my opinion, the Right to be forgotten as proposed by ECJ should not interfere with access to information.


The right to be forgotten and public’s right to access lawful information


In its decision about the right to be forgotten, the ECJ anticipated the risk that this right could limit access to information and asked for a balance between the personal right to privacy and the public right to access information. In ECJ words, right to be forgotten should not apply if it appeared, for particular reasons, such as the role played by the data subject in public life, that the interference with his fundamental rights is justified by the preponderant interest of the general public in having, on account of its inclusion in the list of results, access to the information in question.”


Sure, finding the balance is not always easy, but CNIL and Google tend to agree on cases where the right to be forgotten should not apply. As a matter of fact, in the first case that Google mentions in its post, Google is not the defendant: CNIL is. Indeed, the case were rejected by Google and the concerned persons sent a complaint to CNIL, but CNIL agreed with Google that this was going against interest of the general public in having access to information.

So while many fear that an extended right to be delisted will impede on access to information, this fear is not founded. The ECJ decision clearly strikes a balance between the right to be delisted and the right to access information. The objective of the decision is not to force information to be deleted, it is to prevent unwanted – and often out of context – search results from popping up when you Google someone.  The results are still available on Google and will appear as usual if you search anything but the name for which the results have been delisted. As a matter of fact, the information is not censored, it remains available on the website publishing it but it won’t appear out of the blue when you’re just googling someone’s name. This is somehow coherent with ECtHR decision: publishers are fully covered by freedom of expression but search engines main goal is not to publish information but to compile information about someone (paraphrasing p.97 of ECtHR decision).

The case ECtHR had to judge is an edge case and it seems that when it comes to RTBF applied to search engines, most cases are way more simple. If you want to understand the reality of what is at stake here, have a look at data provided by Google: the top 10 websites for which Google delisted results are social networks. Most of the complaints concern people asking to have comments, pictures and posts removed from social networks. In some cases the content is hosted by Google itself (e.g. Google Plus, YouTube) so individuals have no other remedy than asking Google to delist its own content when it’s inappropriate. Would platforms prefer to directly suppress such content?

Most impacted websites according to Google.


Google shall no longer be the only place where we look for information


Google no longer oppose the Right to Privacy to Freedom of speech (as it used to) but to the public right to access information. Despite the goal of Google to “organize the world information”, Google shall no longer be the only place where you look for information. Search engines algorithms are not meant to find true information, but to find information provided by authoritative sources. That’s why algorithm ranking failures have been observed repeatedly over a year.

Wall Street Journal’s Jack Nicas listed some failures of the featured snippets which are supposed to be the most trusted results provided by Google. Just a year ago, Google was displeased by top results provided by its algorithm and had to deploy patches hastly . While the company should be lauded for its reactivity, it should be noted that this reaction has been triggered by journalists discussing highly visible problems. Obviously, some reaction had to be triggered, but addressing only the cases reported by the press leaves the main problem pending. In fact, Google picks and chooses the search results that it believes are wrong and thus Google no longer consider the page authority to decide what are the most relevant results, it relies on media attention.  It’s not the first time that Google had to update its algorithm hastily. In 2013, reporters highlighted that mughshot websites were highly ranked by Google and were doing some extorting ex-convicted: individuals had to pay for their records not to appear on top of Google search results. A right to be delisted would clearly have had an interest there, but Google shortcut the regulators and updated its algorithm to « fix » the problem shortly after the NYT reported the matter. Last November, Eric Schmidt declared that Google will “derank” Sputnik and Russia today (two Russian websites).  Another patch developed promptly to postpone problem and hide it in the “next” result pages. Individually, these decisions seem laudable. However the big picture shows Google judging what is right and what is wrong and hide the « wrong » results  by ranking them in such a way that it cannot be discovered without clicking next a couple of additional times.


Google is not the Internet (and it’s not the Web either)

If you worried that article with very low ranks will not be seen you’re right, Google never returns more than 1000 search results per query. Practically, if people rarely see the 11th result they never see the 1001th: results following the 1000 results are as good as delisted. So among the millions of results that Google found (and you can see the exact number just below the search bar), Google will only show you 1000. Therefore it’s not because information is not available on Google that you should not keep searching for it.

Google shows only the top 1000 search results ranked by their algorithm.

Google is not the internet. The vast majority of internet websites are hosted by and operated through service providers other than Google. The entities with the technical ability to remove websites or content from the internet altogether are the websites’ owners, operators, registrars, and hosts—not Google. Removing a website link from the Google search index neither prevents public access to the website, nor removes the website from the internet at large. Even if a website link does not show up in Google’s search results, anyone can still access a live website via other means, including by entering the website’s address in a web browser, finding the website through other search engines (such as Bing or Yahoo), or clicking on a link contained on a website (e.g.,, or in an email, social media post, or electronic advertisement. <- These are not my words, they are the words of Google’s lawyer in the Equustek case (see 15 & 16).

The point is that there are other sources of information: other search engines either concurrent or just integrated on news website. If you’re really looking for public information about someone, you should search his name on a newspaper website or on Wikipedia. A Google search may not return the information you’re looking for and is likely to return out of context information.

Wanted: A right to be forgotten

By merely patching PageRank issues, Google postponed the big debate that the ECJ is now forcing it to have. Many individuals have problems with search results about them appearing on Google but cannot expect a miraculous algorithm update to solve it. These people have to rely on the « right to be delisted» to remove offensive, defamatory our outdated and often untrue search results. The right to be delisted decision highlights the need for a balance between right to simply discover information and privacy, while not questioning the access to information on the web. Beyond the big cases reported by journalist and civic society, many individuals have more private problems with defamatory search result page, revenge porn, old comment that they wrote, pictures they should not have shared. There are not enough journalist and civic society associations to cover all these cases and most of them are not willing to have their complaints exposed by journalists.



Credits: Featured Image  is “Outside the European Court of Justice” by katarina_dzurekova (Creative Commons)

How Google is tracking Safari users on third party sites

A couple of weeks ago, google started to stop redirected users from to localized versions of the search engine. This rather innocuous change is likely to have effect on the way safari anti tracking protection copes with Google cookies. Indeed, Safari now deletes cookies of sites you have not interacted with over the last 24 hours [1]. If you type and then are redirected to, you actually don’t interact with  So Safari does not give Google a 24h permission to track you on other domains of the search engine.That won’t happen if Google stop redirecting users and just let them on where they will interact with the search bar and other elements.

Why this is ironic

This is not the first change Google made to the way they handle localized domains. Google made an initial announcement, a couple of months ago, to tell users that localized domains would not be that relevant anymore [2]. Now Google seems to be deprecating local URLs to put everything under the domain. This is quite ironic, because up to last year, they were arguing in a French Right to be forgotten case that and were providing significantly different services [3]. The French court did not follow the reasoning. At that time Google was arguing that only 3% of European were searching on while the remaining 97% were using localized version [4]. Today it seems that it’s actually 60-40 [5].

How Google is tracking Safari

Previously, Google advertising cookies on third party websites were only set from Users hardly interact with so it was likely that Safari would block doubleclick cookies. Since September, Google has also started to set an advertising cookie from its domain. You can track the change of Google cookies explanation page via webarchive, and it seems that Google added the description of the ANID cookie in September [6]. However, you may not have noticed this new cookie in your browser. Indeed, I did a couple of tests to see this cookie but, oddly enough, Google is only setting this cookie on Safari browser. I did a couple of tests using Chrome and Edge developper tools, to emulate different mobile browsers: all iOS devices had the ANID cookie set, none of the other device did receive the ANID cookie.  Hence, Google is giving a special treat to Safari users, similarly to what Google did in 2012 in bypassing Safari tracking protection.

This may help other advertisers to track you

That being said, Google is only following Facebook here. Both are big first parties that – unlike mostly third party websites – were expected not to be impacted by Safari’s measure. It does not seem illegitimate for Google to take the same stance than its major competitor in the online advertising market. Yet, the ramifications of Google moves are more critical.

Unlike Facebook, Google is a major Web ad-exchange platform. It means that Google is hosting auctions where buyers get an opportunity to show an ad on your browser and to synchronize their cookies with those of Google. So if Google is in capicity to bypass Safari tracking protection and to keep cookies on user’s browsers, it’s likely that it will also benefit to all the ad-auction participants. Through Google cookies, third parties will be in capacity to recognize users even though their own cookies have been deleted by Safari. The stability of the Google cookie will technically allow third parties to track browsers over more than 24 hours.

In some sense, this is worse than before, when Safari was blocking all third party cookies and when Google was only serving ads and hosting auctions from the domain. If Google is in capacity to leverage this advantage, it could be a significant blow to the competing ad-exchange marketplaces who are not in capacity to track Safari users over more than 24 hours.


Vincent Toubiana (@vtoubiana)

[1] “Intelligent Tracking Prevention”,

[2] “Making search results more local and relevant”

[3] “Au Conseil d’État, la portée territoriale du droit à l’oubli sur Google”,

[4]”Google says non to French demand to expand right to be forgotten worldwide “,

[5] “The end of google.{your country}?” ,

[6] “Types of cookies used by Google”,

[7] “Google Busted With Hand in Safari-Browser Cookie Jar”,

Cross checking IAB’s numbers

It looks like on Mobile the numbers  IAB’s reports are based on mostly reflect the dynamic of Google and Facebook advertising revenues, not those of average App developpers.


Like many people interested by privacy, I keep an eye on #ePrivacy on Twitter. This hashtag, is used by both people advocating for more privacy (consent as the main legal basis, stronger default settings, no cookie walls) and those pushing for legitimate interest, cookie walls, no default settings,…. Both sides have arguments and I’m obviously more receptive to the former group of people but I try to look at the argument of the other side as well. During the last few weeks, IAB Europe representatives quoted several reports that, according to them, show the importance of the ‘data-driven’ advertising in Europe  (I put ‘data-driven’ into quotes because this refers in fact to almost any type of advertising)

I wanted to analyze the number behind the reports, especially behind the report called “The economics of contribution of digital advertising in Europe”. I tried couple of times to get more info about some of these numbers but did not get a response so far. So I had a closer look to the document. It is an update of a previous 2015 IHS report . Interestingly, in this report the definition of publisher is very broad:

”Publishers, or media outlets, who serve audiences by providing them with content, and serve advertisers by supplying them with audiences. In this report, ‘publisher’ includes any type of company where audience attention and content meet.”

So publisher includes search engines (Google , Yahoo, Bing) and social networks (Facebook, Twitter and Linked). It means that the figures showing the publisher revenues are likely to include the revenues of this company which are largely higher than average publisher revenues.

The mobile ecosystem

While the figures are not false, these figures will certainly not correspond to the revenues of average European publishers or app developper. For instance when reading the figure on mobile advertising revenue, the reader may not be aware that Facebook advertising in Europe is 5,4 €bn (see 2016 Facebook earnings) and that during the 4th quarter of 2016, 84% of its revenues comes from mobile. Meaning that Facebook mobile advertising revenue in Europe is about 4.5 €bn, more than a third of the mobile advertising revenue estimated by IAB.

Facebook advertising revenues (source:


Google’s share is even bigger. So it is likely that if your remove Facebook and Google revenues from the figure, you will be left with at most a third of the 11 €bn made in 2016. And so  mobile advertising will not be the main revenue on mobile. As far as I know, there is no such dominant players in the app ecosystem, so app revenues made of paid apps and in-app purchase will be more equally spread.

What’s behind these numbers

I should add that it’s not simple to know what these numbers reflect from an app developer point of view as it just compares the global revenue without show the cut that the developer receive. Considering the number of intermediates, the global market revenue tells little about the revenue received by the developer.

Finally, it’s hard to get more details on these number and to know exactly what they reflect as there several revenue sources for app developpers. For instance a 2014 GigaOM report shows that added In-App purchase and Paid App revenues make up 4,5 €bn  when the IAB report shows that, during the same year, these revenue sources were neck and neck with mobile advertising.

Revenues charts from different sources shows significantly different revenues in 2013

Final words

These reports are quite opaque so it’s complicated to know where these numbers come from. I’m not arguing that IAB Europe numbers are wrong but they may be misunderstood and as probably do not reflect the reality of average app developers who  probably get more revenues from paid-app and in-app purchases than from advertising.

The missing clauses in Google’s “Customer Match”

In September Google announced “Customer Match”, a new tool for advertisers to target their existing customer using their email addresses. “Customer match” is almost like Facebook’s “Custom Audiences” but Google and Facebook seem engaged in “a privacy race to the bottom” and Google may have taken the lead.

Targeting email addresses

Advertisers aim at targeting prospects and existing customers. While remarketing offers them the opportunity to target potential buyer, advertisers were so far not able to differentiate between their existing  customers and new prospects. They also lacked the possibility to target their “loyal” clients (i.e. those who have subscribed to a loyalty card) because there is no link between the cookie IDs assigned to their browser by ad-networks and their loyalty card number or even their online customer account. “Custom Audience” and “Customer Match” (thereafter “Customer targeting”) create a bridge between the email addresses  used to create a “Best Buy” account or CVS loyalty card and Google and Facebook accounts.

Via “Customer targeting”, advertiser will be able to pull the information they gathered about your shopping habits and leverage it to target you on Facebook and on Google. The advertiser won’t send directly ads that they want to show you and attach it to your address. Instead they will create group of “audiences” by creating groups of email addresses of  their customers. They will send those hashed email addresses to Facebook (or Google) which will check to see if those hashed email addresses match those of registered users.

Technically, Facebook does not see the email address but just the hash. So if you’re not in their user database they will not be able to know that you’re a “Best Buy” customer. That being said, the technical guarantee may not be sufficient considering the computational  resources of giants like Google and Facebook that could generate many hashes to brute force the hashed email address and retrieve the lists of customers. In fact, in another context Google seems to admit this and required that Google Analytics user don’t send hashed identifier like email addresses or phone numbers.

Therefore the only guarantees are contractual; they are the engagements that Google and Facebook take when they receive email addresses (or phone numbers). Facebook and Google are committed to not retrieving the email addresses of people that are not registered to their services. Similarly their contractual clauses prevents them from keeping those lists of hashed identifiers for more than a week (that would remain largely enough for them to break most of them).

Facebook ToS

Facebook Terms of Service are quite constraining for Facebook itself as they more or less prohibit Facebook from doing anything with the hashed email addresses other than using them to help an advertiser reach its audience. Therefore, Facebook cannot add information to the profile of its users. In fact Facebook specifically forbid appending “Custom Audience” data to users’ profiles. Furthermore, Facebook won’t let an advertiser target the audience of another advertiser. For instance “Target” should not be capable to target “Best Buy” customers. Facebook adopts a data processor position with respect to Custom Audience, the advertiser being the data controller.

Except of "Custom Audience ToS"

Except of “Custom Audience ToS”


Google Customer Match

Google took another approach with its service. Google did not include clauses to prevent them from appending “Customer Match” data to user’s profiles. The restrictions only impact the list of email addresses , but there is no restrinction on the use of the list of matched profiles which can therefore be used by Google.

Customer Match conditions from

“Customer Match” conditions from


In fact, Google implicitly admitted that these data will be appended to user profiles when it modified its Privacy Policy in August to include data obtained from partners in Google Accounts data.While the change remained unnoticed then, it became clearly more critical after “Customer Match” was announced.

Change made to google's privacy policy on August 19th

Change made to Google’s privacy policy on August 19th


Consequences of Google posture

Google’s decision to include “Customer Match” data in its user accounts will impact user’s privacy and also advertiser’s competition.

  • Since the data will be included in the account, it means that Google will have a more comprehensive view of its users which is a big step to merge offline and online data (also known as data onboarding). This may have significant negative impact as it puts Google at the center of all these data-flows… until Facebook announces its riposte.
  • On the up-side, this could be beneficial for transparency because users could be made aware of the advertisers targeting them if Google shows these data on privacy dashboards (that’s a big if).
  • However, because Google is a data controller with respect to ‘Customer Match”, advertisers may be reluctant to share information about their customers knowing that it could potentially be re-used by competitors or by Google itself. Not only Google could share these data with other advertisers, thus allowing competitors to target each others audience to stir-up the demand and thus the price, but Google could also be tempted to use the data for its direct benefit.


Thanks to Armand Heslot for providing feedback on a draft.

Implementing cookie consent with “Content Security Policy”

In this post I briefly explain how “Content Security Policy” could be used to enforce the cookie consent regulation by blocking third parties content.

Cookie Consent

EU cookie regulation imposes to website editors to obtain the informed  consent of visitors before setting cookies. Therefore, a website should first check that it has consent before dropping its own (unnecessary) cookies and so should the third parties that are called by the website. While it’s fairly simple for a first party to check that it has obtained consent (e.g. storing the consent in a cookie) third parties are in a different situation because they cannot read the first party cookies to deduce if consent has been granted.
Therefore the responsibility sort of shift to the first parties which are in a position to inform and obtain consent; yet they have to prevent third parties from setting cookies as long as consent has not been obtained. Tag managers are elegant solutions that can be deployed to do that. A less elegant solution is to rely on “Content Security Policy” to prevent external resources setting cookies from being loaded by the browser.

Overview of Content Security Policy

A “Content Security Policy” is a “declarative policy that lets the authors (or server administrators) of a web application inform the client about the sources from which the application expects to load resources”. This policy can be viewed as a white list of resources that can be loaded by the browser when requesting page. Content security policies can be conveyed in two forms, either through an HTTP header or in a http-equiv meta tag in the header of the HTML document .

Implementation of the policy

To comply with the cookie consent regulation, a website may simply use a “Content Security policy” to block any third party from loading content and subsequently setting cookies as long as consent has not been granted. Notice that this solution is not specific to cookies; it prevent all types of resources from being loaded thus effectively preventing all types of fingerprinting by third parties.
A quick “cookie consent” implementation is to set to check when a GET request is received if the “consent” cookie is set and to adapt the “Content-Security-Policy”: if consent has not been granted block all third parties, otherwise set the usual policy.
The easier implementation is to use JavaScript to insert the http-equiv tag in the HTML (although this is not recommended), website editors can just add the following JavaScript tag in their pages and that should do the trick:

if ( document.cookie.indexOf('hasConsent') < 0 ) {
 var hostname = window.location.hostname;
 if (hostname.indexOf("www.") ===0) hostname = hostname.substring(5);
 var meta = document.createElement('meta');
 meta.httpEquiv = "content-security-policy";
 meta.content = "script-src 'self' 'unsafe-inline' *." + hostname + "; img-src *." + hostname + "";

A slightly more complicated solution is to set the HTTP header. The code is fairly similar but the complexity depends of the type of server you’re running. If you’re using PHP, you could do it like that:

if(!isset($_COOKIE["hasConsent"])) {
 $allowed_hosts = "*";
 header("Content-Security-Policy: script-src 'self' 'unsafe-inline' " . $allowed_hosts . "; img-src 'self' " . $allowed_hosts);

Browser Support

Content security policy is still a working draft document so the feature is not supported equally by all browsers. As far as I can tell, Chrome and Safari implement all the required features, including support of the http-equiv tag. Firefox enforces policies that are set through the header but there is currently no support of the http-equiv tag. Finally Internet Explorer offers only very limited support of CSPs through  iframe sandbox property.


I’ve used BURP proxy to preview what websites would look like with content security policies blocking third parties, here are the results :


Content-Security-Policy: script-src 'self' 'unsafe-inline' * *; img-src * *

Content-Security-Policy: script-src ‘self’ ‘unsafe-inline’ * *; img-src * *

Content-Security-Policy: script-src 'self' 'unsafe-inline' * *; img-src * *

Content-Security-Policy: script-src ‘self’ ‘unsafe-inline’ * *; img-src * *

Content-Security-Policy: script-src 'self' 'unsafe-inline' *  *; img-src *  *

Content-Security-Policy: script-src ‘self’ ‘unsafe-inline’ * *; img-src * *



This solution is far from perfect, the main reason is that it is not supported by all browsers. Yet it provides a simple solution for website editors to block third party resources until  consent is obtained. Such solution is complementary to the tags provided on CNIL’s website that can be used to obtain consent before setting Google Analytic first party cookies.