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 >>>> >>>> On Thu, Oct 19, 2023 at 4:52 PM Brianna Goldstein < >>>> [email protected]> wrote: >>>> >>>>> Contact emails >>>>> >>>>> Brianna Goldstein <[email protected]>, James Bradley >>>>> <[email protected]>, David Schinazi <[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 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. >>>>> >>>>> 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 >>>>> >>>>> -- >>>> 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> > . > -- 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/CAL5BFfWPc7-HMbOMZc1YT5NHK0aS854FaHF2tJ9jsRPU29CW_A%40mail.gmail.com.
