This is now enabled on 100% of clients.
On Wed, Jan 25, 2023 at 1:57 PM Brianna Goldstein <brgoldst...@google.com> wrote: > This is now enabled on 100% of clients. > > On Thu, Jan 12, 2023 at 3:39 PM Brianna Goldstein <brgoldst...@google.com> > wrote: > >> 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/CALO2AEfUUQqp9jDNOugkk-WfV%2BWtDrempZ4benQf3HXKMOpsjw%40mail.gmail.com.
