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