Intent to Experiment: IP Protection Phase 0

[Brianna Goldstein]

Contact emails

Brianna Goldstein, James Bradley, David Schinazi

Explainer

IP Protection formerly known as Gnatcatcher

Specification

None

Summary

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 

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 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?

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

[Brianna Goldstein]

Correction: 

The link to the entry on the Chrome Platform Status was incorrect. Below is the corrected link

https://chromestatus.com/feature/5111460239245312

[Alex Russell]

Why has the TAG not been consulted?

--
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+...@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.

[Mike Taylor]

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.

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.

[Alex Russell]

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.

[Harald Alvestrand]

standard naming rant .... can we call this "IP Address Protection"?

My initial read of the title was "Intellectual Property Protection", and I opened it with a sense of dread expecting to find DRM-related stuff and a long argument.

There are IETF efforts related to automatic relays (MASQUE, OHAI), but I think they are intended for a lower level of the protocol stack.

Relays in HTTP are also well defined in IETF (for some value of "well"). I can't remember having seen this particular usage discussed there (but I don't follow HTTP that closely).

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.

[Yoav Weiss]

I think it makes sense to file a TAG review as FYI in the future (non-blocking for this experiment) just to let the TAG know that this is happening, as it changes things significantly when it comes to fingerprinting data (by making other avenues of fingerprinting data more valuable than they currently are).

I wouldn't expect them to provide feedback on the IETF drafts this relies on though.

Should we expect all 3Ps impacted to get the same client IP? Are we concerned with them "comparing notes"?

Also, since the first party gets the real IP, are we concerned with it starting to reflect that info in the DOM for 3Ps to pick it up?

That's probably fine for the initial experiment, but at a later point, you may want some way in devtools to get the same info with a fewer number of hoops jumped. 

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOqqYVFicT9hYsjxPE6GnBboM2bw-md%2B5oe95T3dksVZfBHD9Q%40mail.gmail.com.

[Martin Thomson]

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.

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.

[Thomas Steiner]

In the attached document, there are (at first sight) three domains of long-dead Google services:

inbox.google.com

wave.google.com

orkut.com

Is this on purpose? 

--
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+...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CALO2AEfjo4UU0j%2BxK-PCfgoXCs2Nw2zVuNtfAoi2OpJ8M5M28A%40mail.gmail.com.

--

Thomas Steiner, PhD—Developer Relations Engineer (https://blog.tomayac.com, https://twitter.com/tomayac)

Google Germany GmbH, ABC-Str. 19, 20354 Hamburg, Germany
Geschäftsführer: Paul Manicle, Liana Sebastian
Registergericht und -nummer: Hamburg, HRB 86891

----- BEGIN PGP SIGNATURE -----

Version: GnuPG v2.3.4 (GNU/Linux)

iFy0uwAntT0bE3xtRa5AfeCheCkthAtTh3reSabiGbl0ck0fjumBl3DCharaCTersAttH3b0ttom.hTtPs://xKcd.cOm/1181/

----- END PGP SIGNATURE -----

[Mike Taylor]

Sure, the plan is to file one before any future I2S. But this isn't a blocking concern for this first experiment, imho.

[Mike Taylor]

On 10/20/23 3:41 AM, 'Thomas Steiner' via blink-dev wrote:

In the attached document, there are (at first sight) three domains of long-dead Google services:

inbox.google.com

wave.google.com

orkut.com

Is this on purpose?

Yep, for the ~* retro vibes *~. 

(But also, this is a test list in the first of a few experiments.)

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CALgRrLm%3DMXhD4DDM5xib9B9pXrxrhjMhHh5o2yMdVWrxr%2Bv0Qg%40mail.gmail.com.

[Pete Stergion]

Will we be able to turn this feature off once it rolled out or will it be REQUIRED? The issue for us here at the Cornell University Library IT department is that we have resources that we access by whitelisting domain ip address/vlans to our ERM (Electronic Resource Mangement.) We do not want to use a SAML solution because these are public computers that have a requirement to not have user identifiable information associated with them. 

[Eric Browning]

Please publish the domains this feature will use so that school and district admins may block it because of required governmental child safety filtering concerns.

[Mike Taylor]

Hi Pete,

Yes, users will be able to turn the feature off. See:

https://github.com/GoogleChrome/ip-protection/issues/16
https://support.google.com/chrome/a/answer/7679408?sjid=15843372962730454051-NA#upChromeBrsrX118

thanks,
Mike

--
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+...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/78991b54-9758-4843-a076-f98568743f12n%40chromium.org.

[Mike Taylor]

Hi Eric,

Sure - we will have more details about which domains will be proxied as we get past the experimentation phases and sent an Intent to Ship.

thanks,
Mike

--
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+...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/5202fb6a-5dd6-4a1b-8692-bf4e0aa8b662n%40chromium.org.

[ayumi hamasaki]

What's the advantages / disadvantages of the IP Protection (formerly known as Gnatcatcher) compared to something like the Tor browser?

[Daniel Santiago Rincón Silva]

Can you describe in more detail what are the steps that this proposal would go through in order to be approved? Is there voting from the community that needs to happen or internal Google decisions? Are the 'experimentation phases' mentioned by Mike above the phase 0 and 1 mentioned in the other doc? 

[Mike Taylor]

Hi Daniel,

You can read more about the Blink process for shipping features here:

https://www.chromium.org/blink/launching-features/

And yes, we do have plans for phase 0 and phase 1 experiments (and possibly others, depending on what we learn in the process).

best,
Mike

[Rick Byers]

LGTM, no concerns from me with experimenting. It seems like user and enterprise controls are in place, and since this is just about proxying 3P resources that reduces the risk of it impacting either site functionality or network filtering policy. 

Note that Chrome already has another (fully shipped) feature which proxies some requests to enable IP-protected pre-fetching - by default to Google services.

Rick

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/0924a485-03b2-4883-96ca-4c9e1b86b0ba%40chromium.org.

[Chris]

Putting all other concerns aside, wouldn't this "ip protection" proxy allow the owner/controllers of the proxies to decide what websites and content the end user will and won't be allowed to access?  Why is this problem not listed with other concerns in any of the proposal write ups I have read? This is a serious 1st Amendment concern,a nd should be addressed in the conversation and made known to the public using chrome.

On Thursday, October 19, 2023 at 2:52:53 PM UTC-6 Brianna Goldstein wrote:

[Daniel Santiago Rincón Silva]

Hi Brianna and team.

I see that the readme has been updated to specify that the feature will be initially launched as an "opt-in setting in specific regions". Is there a tentative timeline for this roll-out as well as the candidate regions? Also will this roll-out still be limited to Google services only or all web traffic?

Thanks!

[Mike Taylor]

Hi Daniel,

We don't have any further details to announce right now, but when we do we can update this thread.

thanks,
Mike

--
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+...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/5c0f63c7-5dc0-4619-8801-44010dfece52n%40chromium.org.