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
<https://chromestatus.com/feature/5111460239245312>
On Thu, Oct 19, 2023 at 4:52 PM Brianna Goldstein
<brgoldst...@google.com> wrote:
Contact emails
Brianna Goldstein <mailto:brgoldst...@google.com>, James
Bradley <mailto:jhbrad...@google.com>, David Schinazi
<mailto: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
<https://netlog-viewer.appspot.com/#import>and import your
file
6.
Using the left navigation bar, navigate to the Socketstab,
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
<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/9db81b52-1df3-4e95-a880-80be4a713c7a%40chromium.org.
