├── images ├── mdl-one.png ├── mdl-two.png ├── mdl-three.png ├── geo-example.png ├── prt_explainer_fig1.png └── prt_explainer_fig2.png ├── CONTRIBUTING.md ├── Supported-Countries.md ├── security-privacy-questionnaire.md ├── Explainer-IP-Geolocation.md ├── LICENSE ├── prt_explainer.md └── README.md /images/mdl-one.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/GoogleChrome/ip-protection/HEAD/images/mdl-one.png -------------------------------------------------------------------------------- /images/mdl-two.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/GoogleChrome/ip-protection/HEAD/images/mdl-two.png -------------------------------------------------------------------------------- /images/mdl-three.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/GoogleChrome/ip-protection/HEAD/images/mdl-three.png -------------------------------------------------------------------------------- /images/geo-example.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/GoogleChrome/ip-protection/HEAD/images/geo-example.png -------------------------------------------------------------------------------- /CONTRIBUTING.md: -------------------------------------------------------------------------------- 1 | # Contributing 2 | 3 | We are not accepting contributions to the explainer at this time. 4 | -------------------------------------------------------------------------------- /images/prt_explainer_fig1.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/GoogleChrome/ip-protection/HEAD/images/prt_explainer_fig1.png -------------------------------------------------------------------------------- /images/prt_explainer_fig2.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/GoogleChrome/ip-protection/HEAD/images/prt_explainer_fig2.png -------------------------------------------------------------------------------- /Supported-Countries.md: -------------------------------------------------------------------------------- 1 | Some Privacy Sandbox technologies are being phased out. Please see our 2 | [Update on Plans for Privacy Sandbox Technologies](https://privacysandbox.com/news/update-on-plans-for-privacy-sandbox-technologies/). 3 | 4 | [Privacy Sandbox feature status](https://privacysandbox.google.com/overview/status) 5 | provides more information about the status of individual APIs and platform features. 6 | 7 | This repository will be archived and no longer updated. 8 | 9 | # IP Protection Supported Countries 10 | 11 | This list contains the countries where Google Chrome currently supports IP 12 | Protection. 13 | 14 | Country Code | Country 15 | ------------ | ------------------------ 16 | AD | Andorra 17 | AL | Albania 18 | AM | Armenia 19 | AS | American Samoa 20 | AT | Austria 21 | AX | Åland Islands 22 | AZ | Azerbaijan 23 | BA | Bosnia & Herzegovina 24 | BD | Bangladesh 25 | BE | Belgium 26 | BG | Bulgaria 27 | BN | Brunei 28 | BT | Bhutan 29 | CA | Canada 30 | CH | Switzerland 31 | CK | Cook Islands 32 | CY | Cyprus 33 | CZ | Czechia 34 | DE | Germany 35 | DK | Denmark 36 | EE | Estonia 37 | ES | Spain 38 | FI | Finland 39 | FO | Faroe Islands 40 | FR | France 41 | GB | United Kingdom 42 | GE | Georgia 43 | GG | Guernsey 44 | GI | Gibraltar 45 | GR | Greece 46 | GU | Guam 47 | HK | Hong Kong 48 | HR | Croatia 49 | HU | Hungary 50 | ID | Indonesia 51 | IE | Ireland 52 | IM | Isle of Man 53 | IS | Iceland 54 | IT | Italy 55 | JE | Jersey 56 | JP | Japan 57 | KG | Kyrgyzstan 58 | KH | Cambodia 59 | KR | South Korea 60 | KZ | Kazakhstan 61 | LA | Laos 62 | LI | Liechtenstein 63 | LK | Sri Lanka 64 | LT | Lithuania 65 | LU | Luxembourg 66 | LV | Latvia 67 | MC | Monaco 68 | MD | Moldova 69 | ME | Montenegro 70 | MK | North Macedonia 71 | MM | Myanmar (Burma) 72 | MN | Mongolia 73 | MO | Macao 74 | MP | Northern Mariana Islands 75 | MT | Malta 76 | MV | Maldives 77 | MX | Mexico 78 | MY | Malaysia 79 | NC | New Caledonia 80 | NL | Netherlands 81 | NO | Norway 82 | NP | Nepal 83 | NU | Niue 84 | PF | French Polynesia 85 | PH | Philippines 86 | PK | Pakistan 87 | PL | Poland 88 | PT | Portugal 89 | RO | Romania 90 | RS | Serbia 91 | SE | Sweden 92 | SG | Singapore 93 | SI | Slovenia 94 | SK | Slovakia 95 | SM | San Marino 96 | TH | Thailand 97 | TJ | Tajikistan 98 | TL | Timor-Leste 99 | TM | Turkmenistan 100 | TR | Türkiye 101 | TW | Taiwan 102 | US | United States 103 | UZ | Uzbekistan 104 | VA | Vatican City 105 | XK | Kosovo 106 | -------------------------------------------------------------------------------- /security-privacy-questionnaire.md: -------------------------------------------------------------------------------- 1 | Some Privacy Sandbox technologies are being phased out. Please see our 2 | [Update on Plans for Privacy Sandbox Technologies](https://privacysandbox.com/news/update-on-plans-for-privacy-sandbox-technologies/). 3 | 4 | [Privacy Sandbox feature status](https://privacysandbox.google.com/overview/status) 5 | provides more information about the status of individual APIs and platform features. 6 | 7 | This repository will be archived and no longer updated. 8 | 9 | # Self-Review Questionnaire: Security and Privacy 10 | *Last updated: April 18, 2025* 11 | 12 | **1\. What information does this feature expose, and for what purposes?** 13 | 14 | It doesn’t expose any new information. Instead, it masks the source IP for eligible 3rd-party 15 | traffic (i.e., 16 | [Masked Domain List](https://github.com/GoogleChrome/ip-protection/blob/main/Masked-Domain-List.md)) 17 | to improve user privacy. 18 | 19 | **2\. Do features in your specification expose the minimum amount of information necessary to 20 | implement the intended functionality?** 21 | 22 | Yes 23 | 24 | **03\. Do the features in your specification expose personal information, personally-identifiable 25 | information (PII), or information derived from either?** 26 | 27 | No 28 | 29 | **04\. How do the features in your specification deal with sensitive information?** 30 | 31 | N/A 32 | 33 | **05\. Does data exposed by your specification carry related but distinct information that may not 34 | be obvious to users?** 35 | 36 | No 37 | 38 | **06\. Do the features in your specification introduce state that persists across browsing 39 | sessions?** 40 | 41 | No 42 | 43 | **07\. Do the features in your specification expose information about the underlying platform to 44 | origins?** 45 | 46 | No 47 | 48 | **08\. Does this specification allow an origin to send data to the underlying platform?** 49 | 50 | No 51 | 52 | **09\. Do features in this specification enable access to device sensors?** 53 | 54 | No 55 | 56 | **10\. Do features in this specification enable new script execution/loading mechanisms?** 57 | 58 | No 59 | 60 | **11\. Do features in this specification allow an origin to access other devices?** 61 | 62 | No 63 | 64 | **12\. Do features in this specification allow an origin some measure of control over a user agent's 65 | native UI?** 66 | 67 | No 68 | 69 | **13\. What temporary identifiers do the features in this specification create or expose to the 70 | web?** 71 | 72 | None 73 | 74 | **14\. How does this specification distinguish between behavior in first-party and third-party 75 | contexts?** 76 | 77 | This feature only proxies [certain third-party traffic](https://github.com/GoogleChrome/ip-protection/blob/main/Masked-Domain-List.md) 78 | (when in a first- or third-party context), if the user is in Incognito mode. 79 | 80 | 81 | **15\. How do the features in this specification work in the context of a browser’s Private Browsing 82 | or Incognito mode?** 83 | 84 | The feature only works when in Incognito mode. 85 | 86 | **16\. Does this specification have both "Security Considerations" and "Privacy Considerations" 87 | sections?** 88 | 89 | N/A 90 | 91 | **17\. Do features in your specification enable origins to downgrade default security protections?** 92 | 93 | No 94 | 95 | **18\. What happens when a document that uses your feature is kept alive in BFCache (instead of 96 | getting destroyed) after navigation, and potentially gets reused on future navigations back to the 97 | document?** 98 | 99 | Nothing special. 100 | 101 | **19\. What happens when a document that uses your feature gets disconnected?** 102 | 103 | Nothing special. 104 | 105 | **20\. Does your spec define when and how new kinds of errors should be raised?** 106 | 107 | No. There are no new relevant errors. 108 | 109 | **21\. Does your feature allow sites to learn about the user's use of assistive technology?** 110 | 111 | No 112 | 113 | **22\. What should this questionnaire have asked?** 114 | 115 | Did you discover https://github.com/w3c/security-questionnaire/blob/main/questionnaire.markdown 116 | before or after manually copying question headers from https://w3c.github.io/security-questionnaire/? 117 | -------------------------------------------------------------------------------- /Explainer-IP-Geolocation.md: -------------------------------------------------------------------------------- 1 | Some Privacy Sandbox technologies are being phased out. Please see our 2 | [Update on Plans for Privacy Sandbox Technologies](https://privacysandbox.com/news/update-on-plans-for-privacy-sandbox-technologies/). 3 | 4 | [Privacy Sandbox feature status](https://privacysandbox.google.com/overview/status) 5 | provides more information about the status of individual APIs and platform features. 6 | 7 | This repository will be archived and no longer updated. 8 | 9 | # Explainer: IP Geolocation Approach for IP Protection 10 | 11 | ## Context and Goals 12 | 13 | Location can be a key identifier for understanding what content is relevant for users. As Chrome prepares to [offer users an informed choice on third-party cookies](https://developers.google.com/privacy-sandbox/cookies/prepare/overview), the Chrome team wants to ensure that we are taking appropriate steps to improve privacy on the web while also maintaining key use cases. We have [shared our proposal](https://github.com/GoogleChrome/ip-protection) for masking IP addresses for certain third party domains on the web. This comes with additional implications, like how IP addresses are used to understand the location of [GitHub - GoogleChrome/ip-protection](https://github.com/GoogleChrome/ip-protection) web users. This document outlines our initial proposal for how IP Protection will implement IP geolocation mappings. 14 | 15 | It’s worth noting that IP geolocation—with or without IP Protection—only provides approximate and coarse location information and that there are ways in which users can obfuscate this data. With this proposal, we aim to improve user privacy while maintaining most of the existing uses of IP geolocation as a coarse location signal. Addressing pre-existing accuracy issues of IP geolocation is not a goal and generally, this proposal will inherit the prior limitations of IP as a source of location information. 16 | 17 | ## How IP geolocation information will be shared 18 | 19 | Geo assignments of the IP addresses exposed by IP Protection are shared publicly via a geofeed file. Our geofeed can be found [here](https://www.gstatic.com/ipprotection/geofeed). The geofeed uses the format defined in [[RFC 8805](https://datatracker.ietf.org/doc/html/rfc8805)], and provides city-level mappings. These city-level mappings correspond to top cities, each representing a geographic area around that city. 20 | 21 | ## Defining and Dividing Geographies 22 | 23 | We have divided the entire geographic area where IP Protection might be available into areas with large enough populations of Internet users to ensure individual users remain anonymous. We aimed to define areas where we observe at least one million users over a two week period across Google properties, which we use as a proxy for the number of Internet users in that region. Note that this estimation can differ significantly from census population data or other sources due to a range of factors, for example the presence of temporary visitors or if a person uses multiple digital profiles or accounts. For example, in the US this leads to a subdivision of the country into ~700 geographic areas. Since the U.S. has approximately 330 million people, this would equate to roughly 470,000 people per geo on average. 24 | 25 | Each geographic area is represented in the geofeed by its most populous city. We have aimed to preserve the most popular cities across the globe by Internet population, in order to maximize the utility of the IP geolocation data while improving user privacy. Note that, since we aim for the areas to have a minimum size in terms of Internet users, the areas will be geographically smaller in size in very densely populated areas and larger in sparse areas. 26 | 27 | Note that the assigned IP geolocation for a user would maintain country borders to our best knowledge based on the user’s original IP. For example, a user that appears in Windsor (Canada) according to their original IP address would not be assigned to Detroit (US), despite the geographical proximity. This rule applies for all countries, including those that may have a total population below the established threshold. 28 | 29 | !["The map is subdivided into areas delimited by the blue boundaries in the US and green boundaries in Canada. Users within a certain area will be assigned an IP address that is mapped to the top city of that area, marked with the pin. An area will never cross a country border."](./images/geo-example.png) 30 | 31 | _Image 1. Illustrative mapping of Detroit area. The image shows how country boundaries with Canada are preserved while also indicating unique Geos for certain regions._ 32 | 33 | 34 | 35 | ## Country, State, and Sub-Country Mapping 36 | 37 | As mentioned earlier, IP geolocation can be useful as a coarse location signal but it is not exactly precise and there have always been mechanisms for users to obfuscate this data. As a result, IP geolocation can’t be used to guarantee country, state or other sub-country divisions with 100% accuracy. This limitation is also true of IP Protection, and it remains the responsibility of companies to ensure they are meeting any applicable regulations or other obligations in each jurisdiction. 38 | 39 | Having said that, we have designed our geo mappings to provide best effort accuracy in terms of country and region mappings, while preserving privacy by ensuring sufficiently large geographic areas at the sub-country level. 40 | 41 | As illustrated in the chart above, our geo mappings would preserve country borders to our best knowledge based on users’ original IP addresses. In addition to the country, users will be assigned to an IP that represents the top city in their geographic area, which can then be mapped to a state in the US or relevant region in other countries. These sub-country mappings would also generally hold, although some inaccuracies should be expected, particularly near the regional borders. 42 | 43 | ## Assigning Users to Geos 44 | 45 | Users will be assigned to a geographic area based on their pre-proxy IP address representing their current location. At any time, a geo area will only be used if we can ensure sufficient anonymity for the users who are assigned to it. That is, the IPs representing that geo are being used by a sufficiently large number of users to prevent IP-based tracking. If this condition isn’t met, the user will be defaulted to a less granular geo. We don’t expect this to occur frequently, except potentially in initial rollout phases. 46 | 47 | ## Preserving Privacy and Utility 48 | 49 | We have designed our IP geolocation approach to balance privacy expectations while trying to preserve the maximum utility for the various uses of IP geolocation, such as ads personalization, analytics or compliance. 50 | 51 | In order to ensure a highly privacy-preserving approach, we propose a threshold of one million unique web cookies (over a two week period) to determine the geographic areas that users will be mapped to. We estimate that, at this size, the regions are big enough to preserve privacy such that individual users can’t be tracked or identified based on the IPs that are being assigned to their requests when using the IP Protection system. We’ve also taken into account location privacy considerations, such that the precision revealed by IP geolocation aligns with users’ expectations, even in densely populated areas. 52 | 53 | 54 | ## Have feedback? 55 | 56 | We welcome your feedback on this proposal. Please use the following links to provide your input in our GitHub repository: 57 | * [Impacts of proposed IP geolocation granularity](https://github.com/GoogleChrome/ip-protection/issues/3) 58 | * [Impacts of proposed IP geolocation granularity for regulatory & contractual use cases](https://github.com/GoogleChrome/ip-protection/issues/2) 59 | 60 | -------------------------------------------------------------------------------- /LICENSE: -------------------------------------------------------------------------------- 1 | 2 | Apache License 3 | Version 2.0, January 2004 4 | http://www.apache.org/licenses/ 5 | 6 | TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION 7 | 8 | 1. Definitions. 9 | 10 | "License" shall mean the terms and conditions for use, reproduction, 11 | and distribution as defined by Sections 1 through 9 of this document. 12 | 13 | "Licensor" shall mean the copyright owner or entity authorized by 14 | the copyright owner that is granting the License. 15 | 16 | "Legal Entity" shall mean the union of the acting entity and all 17 | other entities that control, are controlled by, or are under common 18 | control with that entity. For the purposes of this definition, 19 | "control" means (i) the power, direct or indirect, to cause the 20 | direction or management of such entity, whether by contract or 21 | otherwise, or (ii) ownership of fifty percent (50%) or more of the 22 | outstanding shares, or (iii) beneficial ownership of such entity. 23 | 24 | "You" (or "Your") shall mean an individual or Legal Entity 25 | exercising permissions granted by this License. 26 | 27 | "Source" form shall mean the preferred form for making modifications, 28 | including but not limited to software source code, documentation 29 | source, and configuration files. 30 | 31 | "Object" form shall mean any form resulting from mechanical 32 | transformation or translation of a Source form, including but 33 | not limited to compiled object code, generated documentation, 34 | and conversions to other media types. 35 | 36 | "Work" shall mean the work of authorship, whether in Source or 37 | Object form, made available under the License, as indicated by a 38 | copyright notice that is included in or attached to the work 39 | (an example is provided in the Appendix below). 40 | 41 | "Derivative Works" shall mean any work, whether in Source or Object 42 | form, that is based on (or derived from) the Work and for which the 43 | editorial revisions, annotations, elaborations, or other modifications 44 | represent, as a whole, an original work of authorship. For the purposes 45 | of this License, Derivative Works shall not include works that remain 46 | separable from, or merely link (or bind by name) to the interfaces of, 47 | the Work and Derivative Works thereof. 48 | 49 | "Contribution" shall mean any work of authorship, including 50 | the original version of the Work and any modifications or additions 51 | to that Work or Derivative Works thereof, that is intentionally 52 | submitted to Licensor for inclusion in the Work by the copyright owner 53 | or by an individual or Legal Entity authorized to submit on behalf of 54 | the copyright owner. For the purposes of this definition, "submitted" 55 | means any form of electronic, verbal, or written communication sent 56 | to the Licensor or its representatives, including but not limited to 57 | communication on electronic mailing lists, source code control systems, 58 | and issue tracking systems that are managed by, or on behalf of, the 59 | Licensor for the purpose of discussing and improving the Work, but 60 | excluding communication that is conspicuously marked or otherwise 61 | designated in writing by the copyright owner as "Not a Contribution." 62 | 63 | "Contributor" shall mean Licensor and any individual or Legal Entity 64 | on behalf of whom a Contribution has been received by Licensor and 65 | subsequently incorporated within the Work. 66 | 67 | 2. Grant of Copyright License. Subject to the terms and conditions of 68 | this License, each Contributor hereby grants to You a perpetual, 69 | worldwide, non-exclusive, no-charge, royalty-free, irrevocable 70 | copyright license to reproduce, prepare Derivative Works of, 71 | publicly display, publicly perform, sublicense, and distribute the 72 | Work and such Derivative Works in Source or Object form. 73 | 74 | 3. Grant of Patent License. Subject to the terms and conditions of 75 | this License, each Contributor hereby grants to You a perpetual, 76 | worldwide, non-exclusive, no-charge, royalty-free, irrevocable 77 | (except as stated in this section) patent license to make, have made, 78 | use, offer to sell, sell, import, and otherwise transfer the Work, 79 | where such license applies only to those patent claims licensable 80 | by such Contributor that are necessarily infringed by their 81 | Contribution(s) alone or by combination of their Contribution(s) 82 | with the Work to which such Contribution(s) was submitted. If You 83 | institute patent litigation against any entity (including a 84 | cross-claim or counterclaim in a lawsuit) alleging that the Work 85 | or a Contribution incorporated within the Work constitutes direct 86 | or contributory patent infringement, then any patent licenses 87 | granted to You under this License for that Work shall terminate 88 | as of the date such litigation is filed. 89 | 90 | 4. Redistribution. You may reproduce and distribute copies of the 91 | Work or Derivative Works thereof in any medium, with or without 92 | modifications, and in Source or Object form, provided that You 93 | meet the following conditions: 94 | 95 | (a) You must give any other recipients of the Work or 96 | Derivative Works a copy of this License; and 97 | 98 | (b) You must cause any modified files to carry prominent notices 99 | stating that You changed the files; and 100 | 101 | (c) You must retain, in the Source form of any Derivative Works 102 | that You distribute, all copyright, patent, trademark, and 103 | attribution notices from the Source form of the Work, 104 | excluding those notices that do not pertain to any part of 105 | the Derivative Works; and 106 | 107 | (d) If the Work includes a "NOTICE" text file as part of its 108 | distribution, then any Derivative Works that You distribute must 109 | include a readable copy of the attribution notices contained 110 | within such NOTICE file, excluding those notices that do not 111 | pertain to any part of the Derivative Works, in at least one 112 | of the following places: within a NOTICE text file distributed 113 | as part of the Derivative Works; within the Source form or 114 | documentation, if provided along with the Derivative Works; or, 115 | within a display generated by the Derivative Works, if and 116 | wherever such third-party notices normally appear. The contents 117 | of the NOTICE file are for informational purposes only and 118 | do not modify the License. You may add Your own attribution 119 | notices within Derivative Works that You distribute, alongside 120 | or as an addendum to the NOTICE text from the Work, provided 121 | that such additional attribution notices cannot be construed 122 | as modifying the License. 123 | 124 | You may add Your own copyright statement to Your modifications and 125 | may provide additional or different license terms and conditions 126 | for use, reproduction, or distribution of Your modifications, or 127 | for any such Derivative Works as a whole, provided Your use, 128 | reproduction, and distribution of the Work otherwise complies with 129 | the conditions stated in this License. 130 | 131 | 5. Submission of Contributions. Unless You explicitly state otherwise, 132 | any Contribution intentionally submitted for inclusion in the Work 133 | by You to the Licensor shall be under the terms and conditions of 134 | this License, without any additional terms or conditions. 135 | Notwithstanding the above, nothing herein shall supersede or modify 136 | the terms of any separate license agreement you may have executed 137 | with Licensor regarding such Contributions. 138 | 139 | 6. Trademarks. This License does not grant permission to use the trade 140 | names, trademarks, service marks, or product names of the Licensor, 141 | except as required for reasonable and customary use in describing the 142 | origin of the Work and reproducing the content of the NOTICE file. 143 | 144 | 7. Disclaimer of Warranty. Unless required by applicable law or 145 | agreed to in writing, Licensor provides the Work (and each 146 | Contributor provides its Contributions) on an "AS IS" BASIS, 147 | WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or 148 | implied, including, without limitation, any warranties or conditions 149 | of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A 150 | PARTICULAR PURPOSE. You are solely responsible for determining the 151 | appropriateness of using or redistributing the Work and assume any 152 | risks associated with Your exercise of permissions under this License. 153 | 154 | 8. Limitation of Liability. In no event and under no legal theory, 155 | whether in tort (including negligence), contract, or otherwise, 156 | unless required by applicable law (such as deliberate and grossly 157 | negligent acts) or agreed to in writing, shall any Contributor be 158 | liable to You for damages, including any direct, indirect, special, 159 | incidental, or consequential damages of any character arising as a 160 | result of this License or out of the use or inability to use the 161 | Work (including but not limited to damages for loss of goodwill, 162 | work stoppage, computer failure or malfunction, or any and all 163 | other commercial damages or losses), even if such Contributor 164 | has been advised of the possibility of such damages. 165 | 166 | 9. Accepting Warranty or Additional Liability. While redistributing 167 | the Work or Derivative Works thereof, You may choose to offer, 168 | and charge a fee for, acceptance of support, warranty, indemnity, 169 | or other liability obligations and/or rights consistent with this 170 | License. However, in accepting such obligations, You may act only 171 | on Your own behalf and on Your sole responsibility, not on behalf 172 | of any other Contributor, and only if You agree to indemnify, 173 | defend, and hold each Contributor harmless for any liability 174 | incurred by, or claims asserted against, such Contributor by reason 175 | of your accepting any such warranty or additional liability. 176 | 177 | END OF TERMS AND CONDITIONS 178 | 179 | APPENDIX: How to apply the Apache License to your work. 180 | 181 | To apply the Apache License to your work, attach the following 182 | boilerplate notice, with the fields enclosed by brackets "[]" 183 | replaced with your own identifying information. (Don't include 184 | the brackets!) The text should be enclosed in the appropriate 185 | comment syntax for the file format. We also recommend that a 186 | file or class name and description of purpose be included on the 187 | same "printed page" as the copyright notice for easier 188 | identification within third-party archives. 189 | 190 | Copyright [yyyy] [name of copyright owner] 191 | 192 | Licensed under the Apache License, Version 2.0 (the "License"); 193 | you may not use this file except in compliance with the License. 194 | You may obtain a copy of the License at 195 | 196 | http://www.apache.org/licenses/LICENSE-2.0 197 | 198 | Unless required by applicable law or agreed to in writing, software 199 | distributed under the License is distributed on an "AS IS" BASIS, 200 | WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. 201 | See the License for the specific language governing permissions and 202 | limitations under the License. 203 | 204 | -------------------------------------------------------------------------------- /prt_explainer.md: -------------------------------------------------------------------------------- 1 | Some Privacy Sandbox technologies are being phased out. Please see our 2 | [Update on Plans for Privacy Sandbox Technologies](https://privacysandbox.com/news/update-on-plans-for-privacy-sandbox-technologies/). 3 | 4 | [Privacy Sandbox feature status](https://privacysandbox.google.com/overview/status) 5 | provides more information about the status of individual APIs and platform features. 6 | 7 | This repository will be archived and no longer updated. 8 | 9 | # Probabilistic Reveal Tokens 10 | 11 | ## Introduction 12 | 13 | [IP Protection](https://github.com/GoogleChrome/ip-protection) aims to provide 14 | better protection against cross-site tracking in Incognito mode, however, it 15 | could also impact sites' ability to measure and prevent fraud if done without 16 | appropriate mitigations for this use case. Many websites rely on IP addresses to 17 | defend against fraudulent and spammy behavior, so they can focus on providing a 18 | safe experience to their users. To ensure that all businesses can continue to 19 | estimate the amount of fraud on their systems, train models to defend against 20 | fraud, and analyze emerging fraudulent behavior while still mitigating the 21 | ability to track users at scale using IP addresses, we propose to introduce a 22 | delayed IP sampling mechanism called Probabilistic Reveal Tokens (PRTs) 23 | alongside IP Protection. PRTs attempt to drastically reduce the availability of 24 | IP addresses to websites that present a high risk of tracking, while preserving 25 | the ability to estimate fraud and gain visibility into new attack patterns. 26 | 27 | PRTs will be included on proxied requests in a new HTTP header added by the 28 | browser for domains that indicate they want to receive them via a signup 29 | process. Each PRT will contain a ciphertext, generated by an Issuer and 30 | re-randomized for unlinkability by the browser prior to the request, that the 31 | recipient can decrypt after a delay. Google will be the issuer for Chrome's 32 | implementation. A minority of the decrypted PRTs contain the client's pre-proxy 33 | IP address (i.e. non-masked, and as observed by the token issuer), while the 34 | remaining PRTs provide no information about the client's original IP address. 35 | This results in only a small percent of PRTs containing and revealing the user's 36 | IP. 37 | 38 | Clients will be able to verify the reveal rate by decrypting the PRTs they 39 | receive using the private keys published by the key coordinator at the end of 40 | each epoch's delay period. 41 | 42 | ## Goals 43 | 44 | - Enable proxied services to measure invalid traffic (IVT) in aggregate 45 | - Enable actionable insights, like understanding if a publisher or content 46 | provider has a particularly high rate of invalid traffic 47 | - Enable services to update publisher reputation indicators for their traffic, 48 | that may be applied on un-proxied traffic 49 | - Enable fraud and spam detection while minimizing IP reveal rate 50 | - Ensure that cross-site tracking is not re-enabled by this mechanism 51 | 52 | ## Non-Goals 53 | 54 | - Provide a new mechanism for cross-site tracking 55 | - Provide insights for ad measurement beyond IVT detection 56 | - Provide IVT annotations on all masked traffic 57 | - Provide real time IVT detection 58 | - Provide a mechanism to reveal the IP on chosen requests 59 | 60 | ## Use Cases 61 | 62 | Many organizations use IP addresses as critical signals for identifying and 63 | mitigating fraud. This signal is used widely across industries and verticals, 64 | and is useful in preventing a variety of attacks like denial of service, account 65 | takeovers, spamming, payment fraud, etc. 66 | 67 | For general fraud detection use cases, organizations can supplement their fraud 68 | detection pipelines by updating logs with the revealed IP addresses, and 69 | rerunning models or heuristics to generate fraud insights and reports. Although 70 | only a small percentage of requests will be annotated with an IP address, this 71 | sampled data can be used for manual analysis and help identify new threats. 72 | 73 | The initial application of PRTs focuses on the use cases most likely to be 74 | impacted by IP Protection: domains embedded in a third-party context and on the 75 | [Masked Domain List](https://github.com/GoogleChrome/ip-protection/blob/master/Masked-Domain-List.md) 76 | (MDL). Many companies on the MDL are in the business of serving ads, ads 77 | targeting, measuring ad effectiveness, or commerce related activities. These use 78 | cases may rely on detecting fraudulent ad activity through identification of 79 | invalid traffic, bots, or blocklisted IPs. PRTs offer the ability to detect ad 80 | fraud at scale while ensuring that IP Protection works effectively for users. 81 | Embedded third parties on the MDL, like advertisers, remain unable to observe 82 | the IP during a browsing session, and can detect and measure fraud after the 83 | fact using sampled data, all while continuing to help publishers monetize their 84 | sites and continuing to allow users to browse privately. 85 | 86 | ## Proposed Solution 87 | 88 | Probabilistic Reveal Tokens help organizations measure fraud and investigate new 89 | types of attacks while respecting users' privacy during IP-protected browsing. 90 | PRTs utilize re-randomizable ElGamal encryption to make tokens, and repeated 91 | uses of the same issued token, unlinkable. 92 | 93 | ### Participants 94 | 95 | - **Issuer** - The issuer is an internet-facing service from which the browser 96 | fetches PRTs. Following the end of the epoch and some delay period, the 97 | issuer collects the secret key from the key coordinator and publishes it 98 | along with its HMAC key for token validation. 99 | - At launch, Google will be the token issuer 100 | - **Key Coordinator** - The key coordinator generates the cryptographic 101 | keypair necessary for token encryption and decryption, and is responsible 102 | for keeping the secret key material secret while tokens are eligible to be 103 | spent. This may be implemented as part of the issuer. 104 | - **Public Key Repository** - Location where secret keys are published to by 105 | the issuer. Should keep a history of all previously published keys. 106 | - Google's issuer will publish secret keys to GitHub 107 | - **Browser** - The browser fetches tokens from the issuer, re-randomizes them 108 | to prevent linkability, and sends the tokens to websites. After the key 109 | material is published, the browser provides tools to allow discerning users 110 | to validate the privacy properties of the tokens. 111 | - **Websites** - Receive tokens from the browser. After the key material is 112 | published, websites validate the legitimacy of the tokens and leverage 113 | sampled signals. 114 | 115 | ### Probabilistic Reveal Token Generation 116 | 117 | Each epoch will last for one day. Prior to the start of each epoch, the key 118 | coordinator will generate a new ElGamal keypair for encryption, and the issuer 119 | will generate a secret HMAC key necessary for token validation. The public key 120 | will be available at the start of the epoch, and the secret cryptographic key 121 | and HMAC key will be published some time after participants have rotated to a 122 | different set of keys. This delayed release of secrets controls when the PRT can 123 | be decrypted and analyzed. To avoid a thundering herd problem at epoch change, 124 | there will be a small overlap in the active epochs, avoiding all clients having 125 | to fetch new tokens at the same time. 126 | 127 | ![image](images/prt_explainer_fig1.png) 128 | 129 | When a client requests a batch of Probabilistic Reveal Tokens, the issuer will 130 | record the client's IP address from the inbound connection. Within a batch of 131 | tokens, some percentage (based on the reveal rate) will contain the client's 132 | observed pre-proxy IP address. The remaining tokens will contain a NULL value 133 | instead of the IP address. The issuer will then generate a message containing 134 | the chosen IP address or NULL, some low-entropy metadata including a token 135 | version, token ordinal, and an HMAC of the token contents. Finally, the issuer 136 | will encrypt each token using ElGamal encryption and return the batch of tokens 137 | to the client. 138 | 139 | ### Sending Probabilistic Reveal Tokens 140 | 141 | When the client creates a request that will be proxied, it checks whether the 142 | destination origin is in the 143 | [registration list](?tab=t.0#heading=h.e7nq9uro0ytn). If the destination is in 144 | the registration list, the client checks whether the top level site already has 145 | an associated PRT. If the client has already associated a PRT with the top level 146 | site and this PRT has not expired, the token's cipher text is re-randomized and 147 | attached to the request. If there is no PRT associated with the top level site 148 | or the PRT is expired, the client randomly picks a PRT from pre-fetched PRTs, 149 | re-randomizes it, and associates it with the top level origin. \ 150 | The client includes re-randomized PRTs in the 151 | [Sec-Probabilistic-Reveal-Token](https://source.chromium.org/chromium/chromium/src/+/main:net/http/http_network_transaction.cc;drc=0302427cb7d80ae6b980f50ae7eb5801bde36004;l=1298) 152 | header. Values are [Structured Header Byte 153 | Sequences](https://www.rfc-editor.org/rfc/rfc8941.html#section-3.3.5) and hold a 154 | [TLS Presentation Language](https://datatracker.ietf.org/doc/html/rfc8446#section-3) 155 | serialized `PRTStruct` defined below. 156 | 157 | ``` 158 | struct { 159 | uint8 version; 160 | /* size of u and e depends on version, size is 33 for version 1 */ 161 | opaque u<0..2^16-1>; 162 | opaque e<0..2^16-1>; 163 | /* Used to identify the corresponding key/secrets to decrypt */ 164 | opaque epoch_id[8]; 165 | } PRTStruct; 166 | ``` 167 | 168 | ``` 169 | Sec-Probabilistic-Reveal-Token: :AQAhA0YcSOPXwN8JkGJz2Rxe349sEOzwLcXnrU0/e5P1QUEEACECjvPnzEReeDlIkrDocZA5ZtiIptiG02YOOaNMJKyKZTdIXbE63QJtYA==: 170 | ``` 171 | 172 | If there are no valid PRTs to attach when composing a proxied request, 173 | the client will make the proxied request without the header. A 174 | well-behaved client should only fail to attach a PRT in exceptional 175 | circumstances, e.g. Issuer unavailability. As the lack of an attached PRT will 176 | not prevent a request from being proxied, the volume of exceptional 177 | circumstances must be minimized to ensure that a website can treat any 178 | non-trivial amount of proxied traffic missing a PRT as suspicious. 179 | 180 | ![image](images/prt_explainer_fig2.png) 181 | 182 | ### Making use of Probabilistic Reveal Tokens 183 | 184 | After each epoch's delay period, the issuer will publish the private key needed 185 | to decrypt the corresponding batch of PRTs and the HMAC key used to sign 186 | contents. Any interested party can decrypt the PRTs they received during the 187 | corresponding period and verify the reveal rate, ensuring that the issuer is 188 | behaving honestly. 189 | 190 | For Google's implementation of the PRT issuer, we will publish keys to Github. 191 | We will update the explainer with the Github repository at launch. 192 | 193 | When an origin receives a PRT, it will store the PRT until the corresponding 194 | private key and HMAC secret are published by the issuer. The origin can then 195 | decrypt the PRT to recover either the client's true IP address or a NULL IP 196 | address. Origins can verify the contents of the token via the HMAC, and ensure 197 | clients are, in aggregate, selecting them randomly from tokens that were issued 198 | to them. Significant deviations from a uniform distribution of ordinal values is 199 | one indicator of potential malicious client activity. The origin can use the 200 | revealed IP addresses as input to their fraud detection pipeline to estimate the 201 | amount of fraud associated with different publishers or other entities and 202 | create denylists to mitigate that fraud. 203 | 204 | For more technical information on PRT tokens, [please see here](https://github.com/explainers-by-googlers/prtoken-reference). 205 | 206 | ### Requesting access 207 | 208 | By default, PRTs are not included on proxied requests. Organizations on the MDL 209 | must sign up to receive the header as part of the proxied requests using 210 | a forthcoming form. Google will verify that the domain is on the MDL, but will 211 | otherwise not restrict any organization that signs up to receive the tokens. 212 | 213 | We use registration to avoid sending PRTs automatically on every proxied 214 | request. The encryption scheme, although performant, uses client resources. As 215 | sites will need to make additional investments to log and analyse PRTs, sending 216 | them automatically would likely waste client resources. 217 | 218 | Requiring sites to request tokens for each client, e.g. through an HTTP request 219 | header, also doesn't match the expected usage. A site that makes use of PRTs 220 | likely wants them on all proxied connections, and cannot receive them on 221 | un-proxied connections. 222 | 223 | ### Tunable Parameters 224 | 225 | #### Reveal rate 226 | 227 | We are [seeking feedback](https://github.com/GoogleChrome/ip-protection/issues/81) on what a reasonable starting reveal rate should 228 | be. The reveal rate can be modified over time, and a stated goal is to minimize 229 | the reveal rate without impacting sufficient IVT measurement. Given 230 | organizations likely will have a large portion of their traffic unmasked as 231 | non-IP-protected traffic, we may be able to start at a reasonably small reveal 232 | rate around 5-15%.The reveal rate must be high enough to enable reasonable 233 | detection of attacks occurring exclusively in masked traffic. 234 | 235 | #### Epoch & Delay Period length 236 | 237 | We expect the epoch and delay period lengths to begin at one day each, but are 238 | open to feedback on reasonable lengths of time. Please leave your feedback in 239 | [this github issue](https://github.com/GoogleChrome/ip-protection/issues/82) to explain your rationale for the timing. The delay 240 | period should be long enough such that it is impractical to associate revealed 241 | tokens back to a current user session, but not so long in combination with the 242 | epoch length that it is difficult to reprocess events and compile fraud 243 | measurements. 244 | 245 | ## Privacy & Security Considerations 246 | 247 | ### Ciphertext Re-randomization 248 | 249 | The ability to re-randomize a token's ciphertext, without changing the 250 | underlying contents (a property of the ElGamal encryption scheme used), 251 | underpins many of the security and privacy properties of PRTs. The issuer cannot 252 | link a re-randomized token's ciphertext back to any tokens it issued, and 253 | origins that receive re-randomized versions of the same token cannot link them 254 | together. 255 | 256 | Before sending a token on a connection to a particular 1P/3P pair, the client 257 | re-randomizes the ciphertext for that token to make it unlinkable to any other 258 | usage of the token for other 1P/3P pair requests. The client will cache the 259 | cyphertexts for each 1P/3P pairing and reuse them on subsequent requests while 260 | the underlying token remains valid. Received tokens may be stored by origins in 261 | partitioned storage, and so more granular re-randomization (e.g. per request) is 262 | unnecessary. 263 | 264 | As re-randomization is a non-trivial computational operation the client may, 265 | without loss of privacy or security, choose to pre-randomize tokens, ready for 266 | attaching to connections. 267 | 268 | ### PRT affinity to Top-Frame Site During a Delay Period 269 | 270 | A single issued PRT is assigned to a top-frame site during a user session to a 271 | maximum of the delay period length, and all proxied requests to the embeds on 272 | the site will have the same PRT. As the delay period is much longer than typical 273 | user sessions, effectively all embedded origins will either see the revealed IP 274 | or receive NULL (at roughly the reveal rate) for that session. A user session is 275 | defined by the lifetime of site accessible storage, which in Chrome will be the 276 | length of the Incognito session. 277 | 278 | If the client were to choose independent PRTs for each proxied request and 279 | embedded domain, it would be possible for websites to improve their odds of 280 | getting a PRT with the user's original IP address by increasing the number of 281 | origins they have on a page, i.e., multiple requests with PRTs attached, or by 282 | partnering with other embedded domains and sharing their data. 283 | 284 | Although every embedded origin will receive the same underlying token, the 285 | re-randomization of the token's ciphertext ensures that these tokens remain 286 | unlinkable outside the context of the page. Within the context of a page, 287 | origins may choose to share via 288 | [postMessage()](https://developer.mozilla.org/en-US/docs/Web/API/Window/postMessage) - 289 | but because of the 1P affinity, they do not gain any additional information by 290 | doing so. 291 | 292 | ### Token Ordinal Metadata 293 | 294 | Token ordinals prevent a malicious client from choosing one token and 295 | re-randomizing it an arbitrary number of times. This would enable an attacker to 296 | generate an unbounded set of tokens that *all* either reveal the IP, or NULL. 297 | The attacker will *not know which* property the set of tokens has, but being 298 | able to know that they all share *the same* property, would make some attacks 299 | more feasible. 300 | 301 | To mitigate these types of attack, for each requested batch of tokens, the 302 | issuer will record the order of the token as the token's "ordinal" (i.e. the 303 | first token has ordinal 1, the second token ordinal 2, etc.) and then shuffle 304 | the tokens. This field does not convey information about the client requesting 305 | tokens, since each batch of tokens has the full set of ordinal IDs. An origin 306 | can keep the complete set of unique token ciphertexts it receives during an 307 | epoch (noting that ciphertexts are reused on requests for the same 1P/3P pair), 308 | and look at the total, and per top frame, ordinal value distribution. 309 | 310 | Websites will expect a uniformly random distribution of token ordinal values 311 | across their users and spikes of specific token ordinals may be indicative of an 312 | attacker re-randomizing the same token across different sessions they control. 313 | Websites can then apply additional scrutiny to activities associated with these 314 | spikes in the distribution. We expect token batch sizes (and so the maximum 315 | ordinal) to initially be 100, which will enable websites that receive thousands 316 | of tokens to build meaningful distributions. 317 | 318 | ### IP Address Mismatch 319 | 320 | The IP address a client fetches tokens from, and so is seen to the issuer and 321 | probabilistically included in tokens, may be different from the IP address used 322 | to later connect to un-proxied origins, or the IP proxy itself. There are many 323 | reasons this could occur, from a user changing WiFi networks, to an ISP 324 | dynamically assigning a new IP. This drift in IP address may result in a PRT 325 | revealing an IP address that is unexpected from the user's perspective (e.g. the 326 | user's work vs. personal network IP address). 327 | 328 | Browsers can reduce the chance of IP address mismatch by fetching tokens close 329 | to when they are spent, and closely aligned with user expectations. In Chrome, 330 | tokens will be fetched at the start of each new Incognito session. 331 | 332 | ### Timing Attacks 333 | 334 | Web APIs that rely on allocating resources to a specific site must take care not 335 | to introduce any timing attacks. Specifically it is critical to ensure that 336 | there is no observable timing difference between retrieving an already allocated 337 | PRT and allocating a new PRT. Implementations should make sure that the pathways 338 | for retrieving already assigned tokens and allocating new random tokens are 339 | indistinguishable timing wise. Similarly, implementations should ensure that new 340 | PRT batches are automatically requested sufficiently in advance of a new epoch 341 | to ensure that allocating a PRT is always a constant-time operation. 342 | 343 | ## Browser-Specific Considerations 344 | 345 | ### User Control 346 | 347 | PRTs are only sent when IP Protection is enabled, and only on requests that IP 348 | protection causes to be proxied. When a user disables IP Protection this also 349 | disables PRTs. The ability to detect and act on fraud using our additional 350 | privacy protections is a key component of responsibly launching those 351 | protections. 352 | 353 | ### Developer Tools & Token Inspection 354 | 355 | Developers and users can view PRTs passed in the header for proxied requests, if 356 | passed, using the Network tab of Developer Tools. 357 | 358 | Some advanced users may wish to record their own PRT activity for better 359 | transparency. When the `IPPrivacyStoreProbabilisticRevealToken` 360 | [feature flag](https://chromium.googlesource.com/chromium/src/+/HEAD/docs/how_to_add_your_feature_flag.md) 361 | is enabled, Chrome stores all PRTs received in the 362 | `IPPrivacy/ProbabilisticRevealToken/` directory. Chrome will store this to the 363 | disk even in incognito sessions. As this data reveals information about 364 | Incognito usage, exported data will be limited to the fetched tokens themselves, 365 | and not any information about where they were sent. This feature is disabled by 366 | default. We will release tools that make this analysis easier. 367 | 368 | ### Have Feedback? 369 | 370 | We welcome your feedback on this proposal. Please use the following link to 371 | provide your input in our GitHub repository: 372 | 373 | https://github.com/explainers-by-googlers/prtoken-reference 374 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | Some Privacy Sandbox technologies are being phased out. Please see our 2 | [Update on Plans for Privacy Sandbox Technologies](https://privacysandbox.com/news/update-on-plans-for-privacy-sandbox-technologies/). 3 | 4 | [Privacy Sandbox feature status](https://privacysandbox.google.com/overview/status) 5 | provides more information about the status of individual APIs and platform features. 6 | 7 | This repository will be archived and no longer updated. 8 | 9 | # IP Protection 10 | 11 | ## Introduction 12 | 13 | IP Protection is a feature that limits availability of a user’s original IP 14 | address in third party contexts in Incognito mode, enhancing Incognito's 15 | protections against cross-site tracking when users choose to browse in this 16 | mode. 17 | 18 | IP addresses are essential to the basic functioning of the web, notably for 19 | routing traffic and to prevent fraud and spam. However, like third-party 20 | cookies, they can also be used for tracking. For Chrome users who choose to 21 | browse in Incognito mode, we wanted to provide additional control over their IP 22 | address, without breaking essential web functionality. 23 | 24 | To strike this balance between protection and usability, this proposal focuses 25 | on limiting the use of IP addresses in a third-party context. To that end, this 26 | proposal uses a list-based approach, where only domains on the masked domain 27 | list (MDL) in a third-party context will be impacted. 28 | 29 | As mentioned, the scope of this proposal is limited to Chrome’s Incognito mode. 30 | 31 | ## Proposal 32 | 33 | Chrome is introducing an updated proposal to protect users’ IP addresses on 34 | qualifying traffic when browsing in Incognito mode. This protection applies to 35 | domains on the MDL in a third-party context, when users are signed into their 36 | Google account in the Chrome browser before starting an Incognito session. 37 | 38 | **Goals** 39 | 40 | * To improve user privacy by protecting users’ IP addresses in Incognito mode. 41 | * To minimize disruption to the normal operations of servers, including the use 42 | of IP addresses for anti-fraud and anti-spam use cases, until there are 43 | alternative mechanisms in place. 44 | 45 | ### Privacy Proxy 46 | 47 | #### Core requirements 48 | 49 | * Destination origins on the masked domain list don’t see the client’s original 50 | IP address. 51 | * Google can’t see the origin that clients interact with. 52 | * No single proxy can see the origins that clients interact with and the 53 | clients' original IP address. 54 | * IP addresses of the proxies cannot be used for cross-site identification. 55 | * We are [using a list-based 56 | approach](#identifying-domains-and-the-masked-domain-list-mdl) and only 57 | domains on the list in a third-party context will be impacted. 58 | 59 | To meet these requirements, this proposal routes connections via a two-hop proxy 60 | system that masks the user's original IP address and exposes a different masked 61 | IP address to domains. The masked IP address retains IP-based geolocation 62 | information down to a user’s coarse location (including country), but it can't 63 | be used to track an individual user across websites over time. 64 | 65 | On a technical level, the IP Protection proxy infrastructure is designed to 66 | ensure that none of the entities operating the system can access both a user’s 67 | original IP address and the domain their traffic is being sent to. As a result, 68 | the entities operating the system aren't gaining access to users' traffic 69 | information. This privacy property is achieved by leveraging a two-hop proxy 70 | architecture and a blinded authentication scheme. Google will run the first 71 | proxy, and external CDNs will run the second proxy. This implementation ensures 72 | that Google's proxy can only view a user’s IP address but not the destination 73 | domain, while the CDN proxy can only view the destination domain but not the 74 | user’s original IP address, and that neither proxy can associate this data to 75 | the user's account used to grant access to the feature. 76 | 77 | For proxied third-party traffic, the DNS will be resolved at the second proxy. 78 | 79 | Chrome is taking the following steps to prevent user identifiers, including IP 80 | address, from being linked to origin-bound traffic: 81 | 82 | * IP Protection will use CONNECT and CONNECT-UDP (MASQUE) to forward traffic. 83 | There is an end-to-end encrypted tunnel via TLS or QUIC from Chrome to the 84 | destination server. Separate connections will use different IP addresses from 85 | the proxies. 86 | 87 | * We are using two proxies for improved privacy. A second proxy (proxyB) will be 88 | run by an external CDN, while Google runs the first proxy (proxyA). We then 89 | leverage two additional layers of HTTPS encryption, one at each proxy, to 90 | ensure that neither proxy can see both the client IP address and the 91 | destination. The two additional layers of encryption are from the QUIC proxy 92 | tunnels that Chrome uses to connect through each proxy server. When the 93 | request supports HTTPS the flow is the following: There is an encrypted QUIC 94 | tunnel between the client and proxyA; through it, there is another QUIC tunnel 95 | between the client and proxy B; through that tunnel, there is an end-to-end 96 | HTTPS connection between the client and the website, protected by QUIC or TLS. 97 | This end-to-end encryption prevents both proxies from seeing any browsing 98 | contents including the destination URL. The client-proxyB encryption prevents 99 | the proxyA from seeing the hostname of the website. The proxyB cannot see the 100 | IP address of the client because, from its perspective, all client traffic is 101 | coming from the proxyA. These nested tunnels are established using CONNECT and 102 | CONNECT-UDP. Both sets of proxies are run close to users to minimize latency 103 | to the user. 104 | 105 | * Chrome will employ an [RSA blind signature 106 | scheme](https://datatracker.ietf.org/doc/draft-hendrickson-privacypass-public-metadata/) 107 | between client authentication and proxy usage to isolate client identity from 108 | all proxy servers. This will include open source bounds on what metadata is 109 | shared with proxies during this authentication process. This metadata is used 110 | to provide the information that is necessary for the basic operation of the 111 | proxy B, which includes: (i) approximate token expiration to detect expired 112 | tokens and, (ii) IP Geolocation to assign the appropriate egress IP. Chrome is 113 | committed to ensuring a user cannot be uniquely identified via their unblinded 114 | token or associated authentication metadata. 115 | 116 | ### IP geolocation 117 | 118 | IP-based geolocation is used by a swath of services within proxied third-party 119 | traffic, to comply with local laws and regulations and serve content that is 120 | relevant to users. Use cases include content localization, local cache 121 | assignment, and geo-targeting for ads. To support these needs but with privacy 122 | controls in place, the proxy will assign IP addresses that represent the user’s 123 | coarse location, including country. For more information, read the [IP 124 | Geolocation 125 | Explainer](https://github.com/GoogleChrome/ip-protection/blob/main/Explainer-IP-Geolocation.md). 126 | 127 | As described in the IP Geolocation explainer, this architecture sets a user's 128 | approximate IP Geolocation by assigning an appropriate block based on the user's 129 | non-proxied IP address. 130 | 131 | To accomplish this, Google will purchase IPv4 and IPv6 blocks, and defer BGP 132 | control of the blocks to external CDNs that Google has partnered with. 133 | 134 | ### Availability of the IP Protection feature 135 | 136 | IP Protection will be available for users in Chrome’s Incognito mode only, on 137 | Android and Desktop platforms. Users will have the ability to disable IP 138 | Protection. For enterprise-managed versions of Chrome, IP Protection can be 139 | enabled, but it will be off by default. 140 | 141 | The feature will be initially available in certain regions, and we plan to 142 | expand the availability over time. IP Protection will launch to Chrome Stable no 143 | sooner than July 2025. 144 | 145 | ### Identifying domains and the Masked Domain List (MDL) 146 | 147 | IP Protection will use a list-based approach to determine which network traffic 148 | should be proxied. Domains that are on the list will be proxied when they appear 149 | in a third-party context (for example if the domain is embedded within another 150 | website). If that domain is accessed in a first-party context it will receive 151 | the original unmasked IP address. Domains that are not on the list will be 152 | unaffected in either third- or first-party contexts. This applies equally to 153 | Google-owned and non-Google-owned domains. 154 | 155 | #### The Masked Domain List Criteria 156 | 157 | We’ve developed the following criteria to identify which domains should be on 158 | the Masked Domain List (MDL) and therefore receive masked IP addresses. 159 | 160 | **MDL Inclusion Criteria** 161 | 162 | The MDL will be comprised of domains that fulfill the following criteria: 163 | 164 | **The domain is embedded as a third-party domain** and therefore in a position 165 | to collect information about a user or their device across multiple sites that 166 | aren’t owned by the data collector ([see below for how we plan to identify 167 | ownership](#first-party-vs-third-party-determination)). 168 | 169 | In addition, the domain also meets at least one of the following criteria: 170 | 171 | * The domain serves one of the following business purposes: 172 | 173 | * Serving of ads 174 | * Targeting of ads 175 | * Measuring ad effectiveness 176 | * Collection of user data for ads, commerce or marketing related activities 177 | 178 | These business purposes have been selected because they indicate a 179 | heightened risk that an embedded domain could have a business incentive to 180 | collect users’ activity across sites for commercial purposes. 181 | 182 | OR 183 | * The domain collects user or device information in a way that appears likely 184 | to support re-identification of users or devices across contexts. 185 | 186 | While the criteria should be seen as largely stable and durable, the MDL itself 187 | is subject to ongoing evolution and change. This is driven by the refinement of 188 | detection mechanisms and the dynamic emergence and disappearance of domains that 189 | meet these criteria. 190 | 191 | #### Composition of the Masked Domain List 192 | 193 | Google has partnered with [Disconnect.me](https://Disconnect.me), a prominent 194 | internet privacy leader who also collaborates with other web browsers. Chrome 195 | will leverage Disconnect.me to identify domains that align with Chrome’s 196 | established criteria. Additionally, Chrome has developed a methodology to 197 | identify widely used JavaScript functions that provide consistent outputs from 198 | stable and high-entropy web APIs and can therefore be used to construct high 199 | entropy probabilistic identifiers. These functions are then detected when they 200 | are loaded on websites in a third-party context, resulting in a list of domains 201 | that serve scripts with these characteristics that become part of the MDL and 202 | are therefore proxied. The detection pipeline that looks for these patterns of 203 | API misuse considers all domains, including Google’s own domains. 204 | 205 | #### Publication of the Masked Domain List 206 | 207 | The MDL ([initial 208 | version](https://github.com/GoogleChrome/ip-protection/blob/main/Masked-Domain-List.md)) 209 | will be hosted on GitHub. Periodically, domains may be added or removed based on 210 | the fingerprinting detection system and updates to Disconnect's published list. 211 | Chrome will also remove domains that have successfully obtained an appeal. The 212 | published MDL will be the latest version used by Chrome. 213 | 214 | For general inquiries about the MDL, such as those regarding domain inclusions, 215 | exclusions or updates, please contact mdl_inquiries@disconnect.me. Please note 216 | that response times for general inquiries may not adhere to the [timelines 217 | listed for appeals](#policies-and-timelines). 218 | 219 | #### Appeals 220 | 221 | We recognize the importance of implementing an appeals process for our 222 | list-based approach. Appeals permit companies to make a claim that their domain 223 | on the MDL does not meet the inclusion criteria and ought to be removed, thereby 224 | allowing that domain to continue to receive users' original IP addresses in a 225 | third-party context in Incognito. 226 | 227 | The appeals process is available now (as of **April 15th, 2025**) to provide 228 | domain owners sufficient time to seek an appeal and receive a decision prior to 229 | the launch of IP Protection in Incognito in Chrome Stable. 230 | 231 | [Disconnect.me](https://Disconnect.me) will independently manage and operate the 232 | appeals process for the MDL. All [Disconnect.me](https://Disconnect.me) 233 | decisions regarding a domain's appeal are based solely on the MDL criteria 234 | outlined in this document. 235 | 236 | Domain owners who wish to submit an appeal should send an email to 237 | mdl_evaluations@disconnect.me. The email should include the following 238 | information: 239 | 240 | * The domain name subject to the appeal. 241 | * Company name and contact information for the domain owner. 242 | * An explanation of why the domain does not meet the [MDL inclusion 243 | criteria](#the-masked-domain-list-criteria). 244 | 245 | Domain owners can expect the following 246 | policies and timelines to apply to the appeals process: 247 | 248 | * Appeals must be submitted by the domain owner. 249 | * Disconnect.me will aim to provide a decision on each appeal within **10 250 | business days** from the initial appeal request. 251 | * If Disconnect.me requires additional information from the domain owner and 252 | does not receive a response within **10 business days**, the appeal may be 253 | closed. 254 | * If an appeal is closed due to insufficient information, the domain owner may 255 | resubmit an appeal request. 256 | * If an appeal is closed with rationale, the domain will not be eligible for 257 | re-evaluation for a period of **60 days** from the date of the denial. 258 | 259 | The appeals process has been designed to align with governance principles for 260 | Privacy Sandbox under discussion with the UK’s Competition and Markets Authority 261 | ([see CMA's 2024 Q3 262 | report](https://www.gov.uk/cma-cases/investigation-into-googles-privacy-sandbox-browser-changes#q2q3-2024)). 263 | 264 | #### First-party vs Third-party determination 265 | 266 | IP Protection will apply to the domains on the MDL only when accessed in a 267 | third-party context in Incognito, thus we must have a mechanism to determine 268 | what is first-party and what is third-party on a contextual basis. If the 269 | domain for a resource on a page matches the top level domain, that will be 270 | considered first-party context, even if the domain itself is on the MDL. 271 | However, simply using domain structures is insufficient as a mismatch does not 272 | inherently mean the context is third-party. Websites are often constructed using 273 | a modular approach, where various resources are provided by different domains, 274 | even if they are operated by the same company. While masking IP addresses across 275 | multiple domains enhances user privacy, it offers limited privacy gain when 276 | those domains are service domains under common ownership or, to a certain 277 | extent, if they have an affiliation that is clearly presented to users. 278 | Additionally, it imposes an unnecessary burden for web developers operating such 279 | websites. 280 | 281 | 282 | 283 | 290 | 299 | 308 | 309 |
284 |
285 | A figure showing Site A embedding Site B 287 |
Site B is on the MDL and receives a masked IP
288 |
289 | 		291 |
292 | A figure showing Site B as the top-level site 294 |
295 | Site B loads in a 1P context, gets the user's original IP 296 |
297 |
298 | 		300 |
301 | A figure showing Site C embedding Site B 303 |
304 | Site C & B are owned by the same entity, Site B gets the original IP 305 |
306 |
307 |
310 | 311 | Similar to how browsers handle third-party cookie blocking, IP Protection 312 | considers all subdomains of a [registrable 313 | domain](https://web.dev/articles/url-parts#registrable-domain) on the MDL as 314 | part of the same domain and will therefore also receive the same treatment. 315 | Additionally, any subdomains under domains in the [private section of the Public 316 | Suffix 317 | List](https://publicsuffix.org/list/public_suffix_list.dat#:~:text=//%20%3D%3D%3DBEGIN%20PRIVATE%20DOMAINS%3D%3D%3D) 318 | would be considered third-party to each other. 319 | 320 | Chrome will temporarily employ a best effort approach to 321 | deduce domain ownership leveraging an entity mapping created by 322 | [Disconnect.me](https://Disconnect.me). Chrome is partnering with Disconnect to 323 | determine first vs. third-party context. If you believe that your domain is only 324 | loading in a first-party context, please contact mdl_inquiries@disconnect.me. 325 | 326 | ### Anti-Fraud and Anti-Spam Strategy and Implementation 327 | 328 | Chrome recognizes that fighting fraud and spam is critical to keeping a healthy 329 | and safe online ecosystem for users, publishers and advertisers, and that, 330 | today, IP addresses play a critical role in accomplishing this, whether it is 331 | preventing fraudulent commercial transactions or spam at scale. 332 | 333 | Internet proxies provide users with increased anonymity online. For this same 334 | reason, proxies are useful to potential attackers that want to conceal their 335 | activities, such as executing a Denial-Of-Service (DOS) attack. Proxy 336 | defensibility measures are the set of tactics that IP Protection will employ to 337 | decrease the risk of our proxies being leveraged by potential attackers and they 338 | include: 339 | 340 | 1. Rate-limiting access to the proxies 341 | 2. Limiting issuance of authentication tokens 342 | 3. Reporting of fraudulent behavior 343 | 4. Probabilistic Reveal Tokens 344 | 345 | **1. Rate-limiting access to the proxies** 346 | 347 | IP Protection will use client authentication to limit the ability of bad actors 348 | to leverage the proxies to amplify attacks on services on the Masked Domain 349 | List. Therefore, IP Protection will only be available to users that have been 350 | authenticated using the Google account they're signed in with in the Chrome 351 | browser prior to opening a new Incognito window. 352 | 353 | It's important to note that, unlike a majority of services that use 354 | authentication, IP Protection does it in a way that prevents any collection of 355 | data about that user's activity tied to their account as a result of their use 356 | of the feature. To achieve this, Chrome will employ an [RSA blind signature 357 | scheme](https://datatracker.ietf.org/doc/html/draft-amjad-cfrg-partially-blind-rsa-01). 358 | This design ensures that the proxies cannot link the traffic that they're 359 | handling to a user's account, neither the one operated by Google nor the one 360 | operated by the CDN. 361 | 362 | **2. Limiting issuance of authentication tokens** 363 | 364 | Since tokens are blinded to prevent linkability back to a client, it is 365 | theoretically possible to transfer tokens to different clients or use tokens to 366 | appear as multiple indistinguishable clients. To limit token transfer or 367 | harvesting, there will be a maximum quota of tokens issued per user per day and 368 | tokens will be relatively short-lived. Additionally, proxies will limit how much 369 | network traffic can be generated per token. 370 | 371 | IP Protection will aim to provide most users with a sufficient number of tokens 372 | to proxy all their traffic to domains in the MDL. In practice, this means that 373 | users with average traffic patterns will get enough tokens to have their IP be 374 | masked every time, but users with unusually high activity or that show other 375 | indicators of fraud risk may experience limited access. 376 | 377 | In the event a user has no tokens, the requests to domains in the MDL will be 378 | routed directly, without proxying. Token quotas may change over time in response 379 | to reported or observed patterns of fraudulent activity. 380 | 381 | **3. Reporting of fraudulent behavior** 382 | 383 | In addition to preventative measures, we will provide a way for websites to 384 | report DoS or other fraudulent behavior. 385 | 386 | Defensibility is a constant need and an ever-changing landscape as threats 387 | evolve. We expect to remain vigilant and evolve our tactics as necessary to 388 | limit fraud and spam through the IP proxies. 389 | 390 | **4. Probabilistic Reveal Tokens** 391 | 392 | As an additional measure to ensure businesses can monitor the amount of fraud on 393 | their systems, respond to emerging fraudulent behavior, and provide feedback on 394 | future design iterations, we will add a delayed mechanism to access a random 395 | sample of IP addresses called **Probabilistic Reveal Tokens (PRT)**. PRTs will 396 | be included on proxied requests in a new HTTP header added by Chrome for domains 397 | that enable PRTs. This PRT can, after a delay, be decrypted using a key issued 398 | by Google. The PRT will contain the non-proxy IP in a small percent of tokens 399 | issued. This PRT will be rotated for each new first-party load within a given 400 | incognito session. More information on PRTs can be found 401 | [here](https://github.com/GoogleChrome/ip-protection/blob/main/prt_explainer.md). 402 | 403 | ### Ecosystem Engagement 404 | 405 | Over the years of developing this proposal in the Privacy Sandbox, we've 406 | actively sought and encouraged [ecosystem participation and 407 | feedback](https://github.com/GoogleChrome/ip-protection/issues). We want to 408 | ensure that the ecosystem has sufficient time to provide input and feedback 409 | before implementing IP Protection in Incognito. Questions on Github have and 410 | continue to act as a platform for collecting this feedback during the 411 | development phase. This feedback will be considered for refining our proposal 412 | and shaping the roadmap for IP Protection. 413 | 414 | To report issues related to the deployment of IP Protection, including site 415 | compatibility or bugs, please file an issue in the public 416 | [Chromium tracker](https://issues.chromium.org/issues/new?component=1456782&template=1943293). 417 | 418 | ### IP Protection and VPNs 419 | 420 | IP Protection and VPN services have distinct purposes and features. While a VPN 421 | encrypts all user traffic, IP Protection selectively routes third-party traffic 422 | through proxies to prevent online tracking. Unlike VPNs, which often allow users 423 | to choose a virtual location, IP Protection reflects the user's actual country 424 | and nearest metropolitan area. IP Protection is designed to complement active 425 | VPN services, ensuring that both can function simultaneously on the same device 426 | without interference. 427 | --------------------------------------------------------------------------------