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.
On Fri, Oct 20, 2023 at 7:34 AM 'Harald Alvestrand' via blink-dev
<[email protected]> wrote:
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).
On Fri, Oct 20, 2023 at 6:29 AM Alex Russell
<[email protected]> 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
<[email protected]> 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 <[email protected]> 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
<[email protected]> wrote:
Contact emails
Brianna Goldstein
<mailto:[email protected]>, James Bradley
<mailto:[email protected]>, David Schinazi
<mailto:[email protected]>
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.
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?
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.
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.
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
[email protected].
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 [email protected].
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 [email protected].
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 [email protected].
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
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOqqYVFicT9hYsjxPE6GnBboM2bw-md%2B5oe95T3dksVZfBHD9Q%40mail.gmail.com?utm_medium=email&utm_source=footer>.
