Thanks for the feedback! Responses inline.
On Wed, Feb 2, 2022 at 12:03 PM Alex Russell
<[email protected]> wrote:
A 0.5%-5% regression on FCP is massive, particularly if this is at
the median. Are y'all able to publish more data about the
histograms these numbers came from?
A 0.5% for main frames is similar to what we saw on HTTP cache
partitioning, not sure about cross-site iframes. Look at the latest
metrics, 0.7% for main frames is probably a more accurate summary.
The metrics in question specifically are
PageLoad.PaintTiming.NavigationToFirstContentfulPaint and
PageLoad.Clients.ThirdParty.Frames.NavigationToFirstContentfulPaint3.
We have details about percentiles and platforms, though I'm not quite
sure how useful those are. For general frame loads, the greatest
regressions are on slower page loads. For iframes, the largest
regression is at the 50th percentile and below of page loads, with the
regression dropping to around 1% at the 99th percentile of load times.
Regressions are similar across platforms, though Android seems to see
the greatest regression for general frame loads.
I'm unaware of any histograms that would let us better delve into what
sorts of cases the regressions affect most.
Thanks.
On Wednesday, February 2, 2022 at 1:25:41 AM UTC-8 Yoav Weiss wrote:
Thanks for working on this important partitioning!
On Tue, Feb 1, 2022 at 7:01 PM 'Matt Menke' via blink-dev
<[email protected]> wrote:
Contact emails
[email protected]
Explainer
https://github.com/MattMenke2/Explainer---Partition-Network-State/blob/main/README.md
<https://github.com/MattMenke2/Explainer---Partition-Network-State/blob/main/README.md>
Specification
https://fetch.spec.whatwg.org/#connections
<https://fetch.spec.whatwg.org/#connections>
Summary
Partition network state by the network partition key
(which consists of top frame site and frame site), to
protect against cross-site tracking through the use of
side channels. "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, and Expect-CT information.
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 the socket was warm. 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).
Partitioning storage may reduce Chromium’s ability to
reuse network resources. We’ve enabled network state
partitioning in a 5% experiment on Stable. It slows time
to first contentful paint by about 0.5%, and slows
cross-site iframe time to first contentful paint by about
5%. These are very rough averages that vary across
platforms and users.
Can't say that I'm excited about a 5% slowdown here..
Have y'all worked with the webperf community to try and find
mitigations to that? (e.g. adding preconnects for resources
that typically already had warm connections)
I'm unaware of any process for this. We can't allow arbitrary
preconnects for cross-site navs, since they potentially leak
information, though I believe another team is looking / has looked
into fancier cross-site prefetch (which may allow only the root
document to be prefetched, though doesn't allow connection reuse).
Also worth noting that Chrome throws away never used sockets after 10
seconds, since sites tend to close unused sockets quickly, which would
also make cross-site preconnects potentially less useful, unless they
happen exactly at the time navigation starts.
Preconnects for cross-site iframes seems potentially more viable,
since the concerns there are largely around cross-site attacks, so
leaking data due to preconnects are less a use privacy concern, and,
to the extent of my knowledge, are less useful for spying on
cross-site iframes as well.
Any research on the implications in other browsers that we
could use as developer advice? Have y'all looked at the
implications on overall LCP?
I'm unaware of any research here. We have not looked into the
implications of lower LCP here, though I imagine they're similar to
those of cache partitioning.
Any developer facing documentation on this change and what
they should do about it?
The fetch spec covers keying on main frame site (and also allows for
additional keys). We're also talking to devrel, though I'm unfamiliar
with any developer-targeted documentation that we maintain, apart from
web standards documentation.
Explainer:https://github.com/MattMenke2/Explainer---Partition-Network-State/blob/main/README.md
<https://github.com/MattMenke2/Explainer---Partition-Network-State/blob/main/README.md>
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
<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, innermost frame site), unlike the implementation
shipped by other browser vendors, which just uses
top-level site.
This will also potentially increase the number of
connections made to sites, 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 with a site. When
that isn't known, up to six connections are created to a
site, instead of one or two.
This has DDoS potential. Any reports on heavier server load
from the 5% experiment? How are you planning to roll this out?
We have received no reports of heavier server load, but it's not
entirely clear we'd learn of it if it were an issue. Note that this
does not increase number of HTTP requests, but rather number of
established connections (with SSL negotiated), though of course, those
aren't free from either the perspective of the server or the client
(it can also increase number of DNS requests, though those should
typically cached by upstream resolvers).
The plan is to slowly ramp this up to 100% over the course of a
month. Ramp it up to 10%, monitor for two weeks. If all goes well
ramp, it up to 50%, monitor for two more weeks, and then ramp it up to
100%.
Is there a way for us to "remember" the H2/H3 state without it
being a vector for re-leaking the information we're trying to
hide from content?
We do still remember H2/H3 information, but it's sharded by site
(e.g., in the contexts of https://*a.com <http://a.com>, we know that
HTTPS requests to https://*b.com <http://b.com> can be sent to
unique-user-id.tracker.com <http://unique-user-id.tracker.com> via
H3). Since H3 remembers much more than just a boolean, even
remembering a single H3 server across sites is basically equivalent to
a 3P cookie, unless we rework how H3 advertisements works, or have
some central repository where we can validate that H3 information is
not user identifying, which would be a rather major undertaking.
That having been said, DNS HTTPS records do, in fact, rework how H3
(and H2) advertisements works, with browsers learning that information
directly from DNS results, and that should hopefully help here, at
least. Other members of the Chromium team are actively working on
wiring this up. This does add a new DNS request type, which is a
pretty major change, so I'm not sure how long it will take from
implementation to deployment.
NEL, Reporting, and Expect-CT: 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
<https://bugzilla.mozilla.org/show_bug.cgi?id=1590107>)
WebKit: Shipped/Shipping
(https://webkit.org/status/#?search=client-side%20storage%20partitioning
<https://webkit.org/status/#?search=client-side%20storage%20partitioning>)
Web developers: No signals
Have we asked?
I hadn't realized there was a process here. I'll look into starting that.
Other signals:
Ergonomics
The only risk here is 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, though it does have partial coverage.
web-platform-tests can't test some features like, e.g.,
DNS cache partitioning.
Flag name
SplitHostCacheByNetworkIsolationKey,
PartitionConnectionsByNetworkIsolationKey,
PartitionHttpServerPropertiesByNetworkIsolationKey,
PartitionSSLSessionsByNetworkIsolationKey,
PartitionExpectCTStateByNetworkIsolationKey,
PartitionNelAndReportingByNetworkIsolationKey
Requires code in //chrome?
False
Tracking bug
https://crbug.com/993801 <https://crbug.com/993801>
Launch bug
https://crbug.com/1166303 <https://crbug.com/1166303>
Estimated milestones
Plan to roll out in M97/M98 over the course of February
Link to entry on the Chrome Platform Status
https://chromestatus.com/feature/6713488334389248
<https://chromestatus.com/feature/6713488334389248>
Links to previous Intent discussions
Intent to prototype:
https://groups.google.com/a/chromium.org/g/blink-dev/c/6KKXv1PqPZ0/m/nm2z5I_MBAAJ
<https://groups.google.com/a/chromium.org/g/blink-dev/c/6KKXv1PqPZ0/m/nm2z5I_MBAAJ>
Intent to Extend Experiment:
https://groups.google.com/a/chromium.org/g/blink-dev/c/sLC_W6B8big/m/5sk787RQBAAJ
--
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/CAEK7mvrYvoXcc%2B28rFrHbb1tEJN6HPf1y%3DHdE%2BcGe3tuJwsAnA%40mail.gmail.com
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAEK7mvrYvoXcc%2B28rFrHbb1tEJN6HPf1y%3DHdE%2BcGe3tuJwsAnA%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/CAEK7mvrCJFYRoP7FW5JcwK5DjeCy2iW7j4%2BfN6WUy_zfjuZJDw%40mail.gmail.com
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAEK7mvrCJFYRoP7FW5JcwK5DjeCy2iW7j4%2BfN6WUy_zfjuZJDw%40mail.gmail.com?utm_medium=email&utm_source=footer>.
