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/CAKXHy%3DfeSmd67AC9QuP-Vrf-x07RYcX6tvsGkHbdf3h3JXf3nA%40mail.gmail.com.
