Updating this thread to track that this was ramped up to 10% stable this week. Estimated milestones remain:
Estimated milestones Ship at 1% on December 13th - M108 Ship at 10% on January 9th - M109 Ship at 100% on January 23rd - M109 On Mon, Dec 12, 2022 at 2:37 PM Mike West <mk...@chromium.org> wrote: > LGTM3. > > Thanks for your close collaboration with the security team here; I think > the compromise you landed on is both reasonable and good. > > -mike > > > On Mon, Dec 12, 2022 at 8:13 PM Chris Harrelson <chris...@chromium.org> > wrote: > >> LGTM2 >> >> On Fri, Dec 2, 2022 at 1:33 AM Yoav Weiss <yoavwe...@chromium.org> wrote: >> >>> LGTM1 >>> >>> Thanks for working on this compromise between our security/privacy needs >>> and our performance goals!! >>> >>> On Thu, Dec 1, 2022 at 9:38 PM 'Brianna Goldstein' via blink-dev < >>> blink-dev@chromium.org> wrote: >>> >>>> Contact emails >>>> >>>> brgoldst...@chromium.org, mme...@chromium.org, a...@google.com, >>>> miketa...@chromium.org >>>> >>>> Explainer >>>> >>>> >>>> https://github.com/MattMenke2/Explainer---Partition-Network-State/blob/main/README.md >>>> >>>> Specification >>>> >>>> https://fetch.spec.whatwg.org/#connections >>>> >>>> Summary >>>> >>>> Partition network state by the network partition key to protect against >>>> cross-site tracking through the use of side channels. The network partition >>>> key consists of the schemeful site of the top level frame and a boolean >>>> indicating if the request is coming from a cross-site iframe. "Network >>>> State" here includes connections (H1, H2, H3, websocket), the DNS cache, >>>> ALPN/H2 support data, TLS/H3 resumption information, Reporting/NEL >>>> configuration and uploads. >>>> >>>> Unpartitioned network state allows for side-channel timing attacks, >>>> where one site can figure out if another has been visited recently. For >>>> example, if the connection is made quickly, it may be assumed that a >>>> connected socket exists. It also allows for third parties to track users >>>> across first party contexts they are loaded in using a variety of >>>> techniques (tracking socket reuse, using per-user alternative service >>>> advertisements, etc). >>>> >>>> Our initial attempt to partition the network state re-used the triple >>>> key partition scheme that was shipped for the HTTP cache >>>> <https://chromestatus.com/feature/5730772021411840>. This included the >>>> schemeful sites of the top-level frame and the iframe. However, in an >>>> attempt to land a favorable balance between (1) the performance benefits of >>>> shared resources, and (2) the privacy promises of ensuring sites are safely >>>> prevented from gaining information about a user’s browsing habits, this new >>>> partition key consists of the top level site and a boolean indicating if >>>> the request is coming from a cross-site iframe. >>>> >>>> Partitioning may reduce Chromium’s ability to reuse network resources. >>>> We’ve enabled network state partitioning in a 1% experiment on Stable. From >>>> our experiments, Android navigation times to first contentful paint are >>>> increased by around 0.35% at the 50th percentile and 0.17% at the 99th >>>> percentile. Cross-site iframe navigation time to first contentful paints is >>>> increased by 2.85% at the 50th percentile and 1.35% at the 99th percentile. >>>> This represents about a 40 ms increase at the 50th percentile. On desktop, >>>> navigation times to first contentful paint are increased by around 1.00% at >>>> the 50th percentile (approximately a 10 ms increase) and have no impact on >>>> the 99th percentile. For cross-site iframes, the navigation times to first >>>> contentful paint are increased by 1.84% at the 50th percentile and 2.05% at >>>> the 99th percentile. >>>> >>> >>> The numbers still don't make me leap of joy, but they are >>> significantly more reasonable than the previous iteration. >>> I'm curious about the p75 numbers, but assuming they are somewhere in >>> between, that probably won't change the outcome. >>> >>> I wonder if speculative preconnection using the right key could have >>> bought back some of this. I similarly wonder if it could've been safe to >>> somehow publish speculative congestion windows to get rid of slow start in >>> those cases. >>> But obviously, none of this is a blocker to shipping this. Just ideas >>> for winning back some of the losses (that may enable stricter partitioning >>> if they actually work) >>> >>> +Kenji Baheux <kenjibah...@google.com> - FYI >>> >>> >>>> >>>> Explainer: >>>> https://github.com/MattMenke2/Explainer---Partition-Network-State/blob/main/README.md >>>> >>>> Review of partitioning design options: >>>> https://docs.google.com/document/d/1UPjO44CMekDDXIKlih570Z6SOvKQnWzKoDe7APN_GHg/edit >>>> >>>> Blink component >>>> >>>> Internals>Network >>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Internals%3ENetwork> >>>> >>>> TAG review >>>> >>>> https://github.com/w3ctag/design-reviews/issues/596 >>>> >>>> TAG review status >>>> >>>> Issues addressed >>>> >>>> Risks >>>> Interoperability and compatibility >>>> >>>> This proposal partitions the DNS cache and connections, which could >>>> result in longer load times when previously reusable resources can no >>>> longer be reused. The performance impact will likely be most visible in >>>> cross-site iframes. >>>> >>>> Chromium's implementation partitions state by top-level site and a >>>> boolean flag indicating if the frame site is cross-site to the top-level >>>> site. This is unlike the implementation shipped by other browser vendors, >>>> which just uses the top-level site. >>>> >>>> This will also increase the number of connections made per page load, >>>> both because connections can't be reused as often, and because Chromium is >>>> less likely to know in advance if H2 or H3 can be used for a site. >>>> >>>> NEL and Reporting `Report-To` headers tell Chromium how and when to >>>> inform a site of certain errors. Partitioning this information means that >>>> Chromium potentially won't know where to report errors, particularly the >>>> first time it issues a request to a site in a particular context. The >>>> latest version of the Reporting API (Reporting V1, to replace Reporting V0) >>>> is scoped to frames, anyways, so is already subject to a more restrictive >>>> limitation. >>>> >>>> None of these changes is expected to visibly break sites. >>>> >>>> >>>> Gecko: Shipped/Shipping ( >>>> https://bugzilla.mozilla.org/show_bug.cgi?id=1590107) >>>> >>>> WebKit: Shipped/Shipping >>>> >>>> Web developers: No signals >>>> >>>> Other signals: >>>> >>>> Ergonomics >>>> >>>> The only risk here is slightly decreased performance, particularly in >>>> cross-site iframes. >>>> >>>> >>>> Debuggability >>>> >>>> DevTools won't display the network partition key, but will continue to >>>> display the results of network requests accurately. >>>> >>>> Is this feature fully tested by web-platform-tests >>>> <https://chromium.googlesource.com/chromium/src/+/master/docs/testing/web_platform_tests.md> >>>> ? >>>> >>>> No >>>> >>>> Flag name >>>> >>>> EnableCrossSiteFlagNetworkAnonymizationKey, >>>> SplitHostCacheByNetworkIsolationKey, >>>> PartitionConnectionsByNetworkIsolationKey, >>>> PartitionHttpServerPropertiesByNetworkIsolationKey, >>>> PartitionSSLSessionsByNetworkIsolationKey, >>>> PartitionExpectCTStateByNetworkIsolationKey, >>>> PartitionNelAndReportingByNetworkIsolationKey >>>> >>>> Requires code in //chrome? >>>> >>>> False >>>> >>>> Tracking bug >>>> >>>> https://crbug.com/1343856 >>>> >>>> Launch bug >>>> >>>> https://crbug.com/1166303 >>>> >>>> Estimated milestones >>>> >>>> Ship at 1% on December 13th - M108 >>>> >>>> Ship at 10% on January 9th - M109 >>>> >>>> Ship at 100% on January 23rd - M109 >>>> >>>> Link to entry on the Chrome Platform Status >>>> >>>> https://chromestatus.com/feature/6713488334389248 >>>> >>>> Links to previous Intent discussions >>>> >>>> Intent to ship (triple key): >>>> https://groups.google.com/a/chromium.org/g/blink-dev/c/tJa6uzXu_IA/m/IN6UhwKtAwAJ >>>> >>>> Intent to experiment: >>>> https://groups.google.com/a/chromium.org/g/blink-dev/c/-5lo8I9QT0c/ >>>> >>>> >>>> -- >>>> 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/CALO2AEcVQz68P41h%3D%2Bb-zp%3DEdFFQ1nSn9OTPqaTQBjgAeXQiXw%40mail.gmail.com >>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CALO2AEcVQz68P41h%3D%2Bb-zp%3DEdFFQ1nSn9OTPqaTQBjgAeXQiXw%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/CAL5BFfVUdb5XGr6N0gPGf_kzBzAMmG2jCfeGNfv43gPeCCudeA%40mail.gmail.com >>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfVUdb5XGr6N0gPGf_kzBzAMmG2jCfeGNfv43gPeCCudeA%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/CAOMQ%2Bw_6cJmkB7By84PDYxTyxcR1c8ZnPMpJswP6Ztsyhk2O8Q%40mail.gmail.com >> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw_6cJmkB7By84PDYxTyxcR1c8ZnPMpJswP6Ztsyhk2O8Q%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/CALO2AEe85u%3DD0Pp08tXLCXAX30LAYrFJhRA9fUaftDnkTrMRtA%40mail.gmail.com.
