[w3ctag/design-reviews] Review request: Partitioning Network State (#596)

HIQaH! QaH! TAG!

I'm requesting a TAG review of partitioning network state.

We propose to use the network partition key to partition connections and certain other network information, and only use state with a matching key for requests, in addition to whatever the object was previously keyed on. This will increase the eviction rate of various object types, since resource limitations require there be limits on the amount stored network objects. These limits do potentially leak information across network partition keys when evicting data, but addressing that is beyond the scope of this proposal.

  - [Explainer](https://github.com/MattMenke2/Explainer---Partition-Network-State/blob/main/README.md)
  - Specification URL
    -  [Connection pooling portion of the fetch spec](https://fetch.spec.whatwg.org/#connections)
  - [GitHub repo](https://github.com/MattMenke2/Explainer---Partition-Network-State/)
  - Tests: [fetch/connection-pool/](https://github.com/web-platform-tests/wpt/tree/master/fetch/connection-pool) (Only cover H1 sockets)
  - Security and Privacy self-review: https://github.com/MattMenke2/Explainer---Partition-Network-State/blob/main/security-privacy-questionnaire.md

  - Primary contact:
    - Matt Menke (@MattMenke2), Google
  - Organization driving the specification: Google
  - Key pieces of existing multi-stakeholder review or discussion of this specification: 
    - This is an extension of partitioning the disk cache, which was reviewed at https://github.com/w3ctag/design-reviews/issues/424

    - Main update to the fetch spec:  https://github.com/whatwg/fetch/pull/1063

    - Privacy CG list of bits of storage that leak data across-sites https://github.com/privacycg/storage-partitioning

  - External status/issue trackers for this specification (publicly visible, e.g. Chrome Status):
    - FireFox intent to ship:  https://groups.google.com/g/mozilla.dev.platform/c/uDYrtq1Ne3A

    - WebKit supports this:  https://webkit.org/status/#?search=client-side%20storage%20partitioning

    - Chrome status entry:  https://www.chromestatus.com/guide/edit/6713488334389248


Further details:
  - [X] I have reviewed the TAG's [API Design Principles](https://w3ctag.github.io/design-principles/)
  - The group where the work on this specification is currently being done:
    - Fetch spec / WHATWG.
  - Major unresolved issues with or opposition to this specification:
    - Should addition information be added to the partition key, beyond top-frame site?
      - Chromium adds innermost iframe site, and for the HTTP cache, an additional bool that's true for frames.
    - Should origin be used instead of site?  Main concern about using origin instead is performance.
    - The explainer lists a number of areas not yet covered.
    - Some areas mentioned in the explainer currently aren't specified all, or are only covered by low level protocol specs (e.g., TLS session resumption cache, ALPN cache)
  - This work is being funded by: Google

You should also know that...

While the explainer doesn't cover these, as it sticks to cross-browser behaviors, in Chromium we intend to shard NEL and Reporting data by network partition key as well, for the moment. Both of these specs are in draft form, currently, and the reporting spec is moving towards making reporting information document-scoped, which will remove the need for reporting information to be keyed on network partition, since it will no longer have its own global cache. The NEL spec will also need to be updated to take this into account. Chromium will, of course, ultimately implement these standards as specified.

Also, the bits of this that are implemented in different browsers may not perfectly match - FireFox's intent covers HTTP auth, for instance, which is something the explainer doesn't yet cover, and which may require further spec work.

We'd prefer the TAG provide feedback as:
  🐛 open issues in our [GitHub repo](https://github.com/MattMenke2/Explainer---Partition-Network-State/issues) for **each point of feedback**


-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/596