**
*Contact emails*
*
miketa...@chromium.org, jhbrad...@google.com
Explainer
https://github.com/GoogleChrome/ip-protection/blob/main/README.md
<https://github.com/GoogleChrome/ip-protection/blob/main/README.md>
Specification
None
Summary
IP Protection is a feature that limits availability of a user’s original
IP address in third-party contexts in Incognito mode, enhancing
Incognito's protections against cross-site tracking when users choose to
browse in this mode.
IP addresses facilitate a range of use cases, including routing traffic
and preventing fraud and spam. However, they can also be used for
tracking. For Chrome users who choose to browse in Incognito mode, we
want to provide additional control over their IP address, without
breaking essential web functionality.
To strike this balance between protection and usability, this proposal
focuses on limiting the use of IP addresses in a third-party context in
Incognito mode. To that end, this proposal uses a list-based approach,
where only domains on the Masked Domain List
<https://github.com/GoogleChrome/ip-protection/blob/main/Masked-Domain-List.md>(MDL)
in a third-party context will be impacted.
Blink component
Internals>Network>Proxy
<https://issues.chromium.org/issues?q=customfield1222907:%22Internals%3ENetwork%3EProxy%22>
TAG review
https://github.com/w3ctag/design-reviews/issues/1083
<https://github.com/w3ctag/design-reviews/issues/1083>
TAG review status
Pending
Risks
Interoperability and Compatibility
There shouldn’t be any interop concerns, as we’re routing certain
traffic through a series of proxies.
In terms of compatibility, there are a few possible risks, namely
assigning the incorrect geo
<https://github.com/GoogleChrome/ip-protection/blob/main/Explainer-IP-Geolocation.md>on
egress. However, this would be considered a bug in our services (to be
fixed server side when discovered), not a consequence of the feature
itself. Another risk might be that these IP ranges aren’t recognized and
certain traffic is incorrectly blocked or a user loses access to a
resource. We have published our geofeed
<https://www.gstatic.com/ipprotection/geofeed>as one mitigation for this
risk.
Gecko: No signal
WebKit: Shipped/Shipping Safari has a similar feature called iCloud
Private Relay.
Web developers: Mixed signals There are some different views in the
various open and closed issues at
https://github.com/GoogleChrome/ip-protection/issues
<https://github.com/GoogleChrome/ip-protection/issues>. The issues from
developers appear to be largely neutral (in the form of questions to
better understand use case impact etc.). It’s worth noting that there
are some negative sentiments expressed in other issues, but it’s unclear
if these are from a developer point of view, or just a user point of view.
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?
No, we are not proposing to ship this on WebView.
Goals for experimentation
We will run a 1% stable experiment for users when in Incognito mode,
limited to clients in North America. Our motivation is functional in
nature: we would like to better understand the stability and scalability
of our infrastructure based on real world traffic, as well as understand
client metrics impact ahead of any future Intents to Ship. We will also
be able to test out our MDL update pipeline.
Debuggability
Today, proxied requests can be debugged via netlogs[1]. We plan to add
more robust support to DevTools in a future release such that it will be
apparent which requests are being proxied.
We also have chrome://flags/#ip-protection-proxy-opt-out which
developers or users can use for testing suspected breakage.
[1] See https://www.chromium.org/for-testers/providing-network-details/
<https://www.chromium.org/for-testers/providing-network-details/>for
instructions on capturing a netlog. If IP Protection is enabled will see
a socket corresponding to the IP Protection Proxy in the Sockets tab
that handles traffic to domains on the MDL.
Will this feature be supported on all six Blink platforms
(Windows, Mac, Linux, ChromeOS, Android, and Android WebView)?
No. We plan to launch this on all Blink platforms except WebView.
Is this feature fully tested by web-platform-tests
<https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>?
No, and there isn’t any API to be tested. So we don’t plan to add any.
Flag name on about://flags
None
Finch feature name
EnableIpPrivacyProxy
Non-finch justification
N/A
Requires code in //chrome?
False
Tracking bug
https://issues.chromium.org/issues/370696608
<https://issues.chromium.org/issues/370696608>
Launch bug
https://launch.corp.google.com/launch/4302200
<https://launch.corp.google.com/launch/4302200>
Estimated milestones
We would like to run the experiment from M137 to M142 inclusive.
Link to entry on the Chrome Platform Status
https://chromestatus.com/feature/6574194264899584?gate=6479226800439296
<https://chromestatus.com/feature/6574194264899584?gate=6479226800439296>
Links to previous Intent discussions
Intent to Experiment:
https://groups.google.com/a/chromium.org/g/blink-dev/c/9s8ojrooa_Q/m/I6Rj5UTZBgAJ
<https://groups.google.com/a/chromium.org/g/blink-dev/c/9s8ojrooa_Q/m/I6Rj5UTZBgAJ>
This intent message was generated by Chrome Platform Status
<https://chromestatus.com/>.
*
--
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 visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/3dc16174-d810-4da4-87b9-7cb3cd989f14%40chromium.org.
