As Harald mentioned, this is based on ongoing IETF work, but I think that Mike's assessment is the relevant one: this is a choice that Chrome can make without necessarily getting approval from anyone. Apple's iCloud Private Relay is a very similar system that is well-known and favourably viewed.
The hazards here are less obvious, but they are all things that Chromium people need to consider carefully. I believe some, like Mike, already have performed this analysis, even if Brianna's short note doesn't cover these details. Sites today rely heavily on IP reputation for denial of service and abuse mitigation purposes. Hiding IP at scale is going to force sites to alter how they think about and react to abuse and attacks. I understand that this is why Apple shipped Private Access Tokens and Google are working on Private State Tokens. That is, Privacy Pass. (Mozilla will have something to share about Privacy Pass in the next week or so.) A slow roll-out that initially limits proxying to embedded content should help here. Routing traffic through a limited number of entities creates a traffic bottleneck. That gives those entities considerable power over a vast amount of traffic. The privacy risk here is tiny, as I don't believe that traffic analysis is currently very good at this scale, but it is worth noting. More concerning is that these entities have the ability to block or slow traffic at scale. The two-proxy setup does help a lot with that as it makes targeting flows for analysis harder. On Fri, Oct 20, 2023 at 3:29 PM Alex Russell <slightly...@chromium.org> wrote: > This is going to change observable network behavior, right? The TAG liases > with IETF, and if there aren't already active conversations in IETF about > this change, I worry that it will be received poorly. > > On Thu, Oct 19, 2023, 7:15 PM Mike Taylor <miketa...@chromium.org> wrote: > >> I'm recused from voting on this feature so with my API OWNER hat off (or >> maybe just back and to the side to make me look cool...), it's possible >> that we submit an FYI review in the future ahead of an I2S. >> >> That said, this is a feature that arguably does not materially alter web >> platform APIs, but instead masks the client's IP using IETF defined >> CONNECT, CONNECT-UDP, and MASQUE, etc. But if TAG would like to provide >> input on our design choices, that could be useful. But it shouldn't block >> an experiment. >> On 10/19/23 3:22 PM, Alex Russell wrote: >> >> Why has the TAG not been consulted? >> >> On Thu, Oct 19, 2023, 3:09 PM 'Brianna Goldstein' via blink-dev < >> blink-dev@chromium.org> wrote: >> >>> *Correction*: >>> The link to the entry on the Chrome Platform Status was incorrect. Below >>> is the corrected link >>> >>> https://chromestatus.com/feature/5111460239245312 >>> >>> On Thu, Oct 19, 2023 at 4:52 PM Brianna Goldstein < >>> brgoldst...@google.com> wrote: >>> >>>> Contact emails >>>> >>>> Brianna Goldstein <brgoldst...@google.com>, James Bradley >>>> <jhbrad...@google.com>, David Schinazi <dschin...@google.com> >>>> >>>> Explainer >>>> >>>> IP Protection formerly known as Gnatcatcher >>>> <https://github.com/GoogleChrome/ip-protection> >>>> >>>> Specification >>>> >>>> None >>>> >>>> Summary >>>> >>>> IP Protection <https://github.com/GoogleChrome/ip-protection> is a >>>> feature that sends third-party traffic for a set of domains through proxies >>>> for the purpose of protecting the user by masking their IP address from >>>> those domains. >>>> >>>> After receiving much feedback from the ecosystem, the design of the >>>> broader proposal is as follows: >>>> >>>> - >>>> >>>> IP Protection will be opt-in initially. This will help ensure that >>>> there is user control over privacy decisions and that Google can monitor >>>> behaviors at lower volumes. >>>> - >>>> >>>> It will roll out in a phased manner. Like all of our privacy >>>> proposals, we want to ensure that we learn as we go and we recognize >>>> that >>>> there may also be regional considerations to evaluate. >>>> - >>>> >>>> We are using a list based approach and only domains on the list in >>>> a third-party context will be impacted. We are conscious that these >>>> proposals may cause undesired disruptions for legitimate use cases and >>>> so >>>> we are just focused on the scripts and domains that are considered to be >>>> tracking users. >>>> >>>> >>>> We plan to test and roll out the feature in multiple phases. To start, >>>> Phase 0 will use a single Google-owned proxy and will only proxy requests >>>> to domains owned by Google. This first phase will allow us to test our >>>> infrastructure while preventing impact to other companies and gives us more >>>> time to refine the list of domains that will be proxied. For simplicity, >>>> only clients with US-based IP addresses will be granted access to the >>>> proxies for phase 0. >>>> >>>> A small percentage of clients will be automatically enrolled in this >>>> initial test, though the architecture and design will evolve between this >>>> test and future launches. To access the proxy, a user must be logged in to >>>> Chrome. To prevent abuse, a Google-run authentication server will grant >>>> access tokens to the Google run proxy based on a per-user quota. >>>> >>>> In future phases we plan to use a 2-hop proxy, as had previously been >>>> indicated in the IP Protection explainer. >>>> >>>> Blink component >>>> >>>> Privacy>Fingerprinting>IPProtection >>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Privacy%3EFingerprinting%3EIPProtection> >>>> >>>> TAG review >>>> >>>> None >>>> >>>> TAG review status >>>> >>>> N/A >>>> >>>> Risks Interoperability and Compatibility >>>> >>>> IP Protection changes how stable a client's IP address is but does not >>>> otherwise cause a breaking change for existing sites. In this experiment >>>> the only sites impacted are Google owned domains which include the some >>>> domains >>>> <https://docs.google.com/document/d/1iCM3BxJ5cBVwepIL3L-ux-2eS-R0SgaCZEM_ja0ary4/edit?usp=sharing> >>>> when they are loaded in a third party context. >>>> >>>> For those requests, a stable IP address for a client can no longer be >>>> expected. There is no impact to other domains at this time. >>>> >>>> Gecko: No signal >>>> >>>> WebKit: Shipped a similar feature in Intelligent Tracking Protection. >>>> This experiment is only a single proxy, however we plan in a later phase to >>>> move to the double hop proxy model that Safari has also shipped. >>>> >>>> Web developers: No signals >>>> >>>> Other signals: >>>> >>>> WebView application risks >>>> >>>> Does this intent deprecate or change behavior of existing APIs, such >>>> that it has potentially high risk for Android WebView-based applications? >>>> >>>> This experiment does not include Webview. >>>> >>>> >>>> Goals for experimentation >>>> >>>> We will enable this experiment in the pre-stable Chrome channels at >>>> most to 33% of clients. For this initial experiment we want to test our >>>> infrastructure and the integrations between various components for bugs, >>>> stability and reliability. We want to measure the latency of requests using >>>> the full flow to get an early picture of where we can improve performance >>>> as we ramp up traffic. >>>> >>>> Ongoing technical constraints >>>> >>>> None >>>> >>>> Debuggability >>>> >>>> How to test IP Protection if the feature is enabled on your client >>>> >>>> 1. >>>> >>>> Navigate your configured browser to chrome://net-export. >>>> 2. >>>> >>>> Click “Start Logging To Disk” and save the log as something you can >>>> remember >>>> 3. >>>> >>>> Open another tab and navigate to a sites that loads 3p Google ads >>>> 4. >>>> >>>> Go back to your net-export tab and click “Stop Logging”. This will >>>> download a JSON log file. >>>> 5. >>>> >>>> Navigate to https://netlog-viewer.appspot.com/#import and import >>>> your file >>>> 6. >>>> >>>> Using the left navigation bar, navigate to the Sockets tab, if IP >>>> Protection is enabled for you will see a socket corresponding to the IP >>>> Protection Proxy that handles traffic to some Google owned domains. >>>> >>>> >>>> Will this feature be supported on all six Blink platforms (Windows, >>>> Mac, Linux, Chrome OS, Android, and Android WebView)? >>>> >>>> No, not WebView. >>>> >>>> Is this feature fully tested by web-platform-tests >>>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> >>>> ? >>>> >>>> No >>>> >>>> Flag name >>>> >>>> kEnableIpProtectionProxy >>>> >>>> Requires code in //chrome? >>>> >>>> chrome/browser/ip_protection/ handles authenticated requests to the >>>> token signing server. >>>> >>>> Estimated milestones >>>> >>>> M119 - M125 >>>> >>>> Link to entry on the Chrome Platform Status >>>> >>>> https://chromestatus.com/feature/6574194264899584 >>>> >>>> -- >>> You received this message because you are subscribed to the Google >>> Groups "blink-dev" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to blink-dev+unsubscr...@chromium.org. >>> To view this discussion on the web visit >>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CALO2AEczuZgtFBOSVq2x4G41%3D8h1KZu13y69AAGqwABy-edtRg%40mail.gmail.com >>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CALO2AEczuZgtFBOSVq2x4G41%3D8h1KZu13y69AAGqwABy-edtRg%40mail.gmail.com?utm_medium=email&utm_source=footer> >>> . >>> >> -- >> You received this message because you are subscribed to the Google Groups >> "blink-dev" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to blink-dev+unsubscr...@chromium.org. >> To view this discussion on the web visit >> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAA44PQi5unZHkS0W34Ns4AEO4Fbt-4yF7QE89Cuyp87iu-m0Dg%40mail.gmail.com >> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAA44PQi5unZHkS0W34Ns4AEO4Fbt-4yF7QE89Cuyp87iu-m0Dg%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> >> -- > You received this message because you are subscribed to the Google Groups > "blink-dev" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to blink-dev+unsubscr...@chromium.org. > To view this discussion on the web visit > https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAA44PQg0L45W7T0zpkJC_NbTNXr83jkHHiJHxReE6%3Ducf%2BeA0w%40mail.gmail.com > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAA44PQg0L45W7T0zpkJC_NbTNXr83jkHHiJHxReE6%3Ducf%2BeA0w%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > -- You received this message because you are subscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscr...@chromium.org. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAPLxc%3DWRoNX0RMcnbhaYa-C%3DQ0dtBBpGKn-TTtFnW-uf7cPfxQ%40mail.gmail.com.
