├── README.md └── security-privacy-questionnaire.md /README.md: -------------------------------------------------------------------------------- 1 | # Explainer - Partition Network State 2 | Author: mmenke@google.com 3 | Last update: Jan 11, 2021 4 | 5 | ## Introduction 6 | 7 | A browser's network resources, such as connections, DNS cache, and alternative service data are generally shared globally. That is, requests to the same destination across pages can reuse the same socket, and DNS lookups across pages will use the same cache. This 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). See Chrome [Privacy Sandbox](https://github.com/michaelkleber/privacy-model) privacy model for more information. 8 | 9 | We propose to [partition](https://github.com/michaelkleber/privacy-model#identity-is-partitioned-by-first-party-site) much of this state to prevent these resources from being shared across first party contexts to protect against these sorts of attacks. To do this, each request will have an additional "network partition key" that must match in order for resources to be reused. 10 | 11 | This extra key will necessarily make third party resources less reusable, as sites will not be able to access shared resources and metadata learned from loading other sites. 12 | 13 | ## Network Partition Key 14 | 15 | This is covered by the earlier [HTTP cache partitioning explainer](https://github.com/shivanigithub/http-cache-partitioning/) as well as the [fetch spec](https://fetch.spec.whatwg.org/#network-partition-key). We propose to use the two value (top-level site, iframe site) key described in the HTTP cache partitioning explainer as "triple keying". 16 | 17 | A "transient network partition key" is a network partition key for an [opaque origin](https://html.spec.whatwg.org/multipage/origin.html#concept-origin-opaque), and stores no data on disk. In several cases mentioned below, such keys are created for use by internal network requests. 18 | 19 | ## Proposed solution 20 | 21 | 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. 22 | 23 | ### What resources will and will not be keyed on network partition key: 24 | 25 | We propose to key the following connection-associated resources using the network partition key: 26 | 27 | * Live DNS requests and the DNS cache 28 | * HTTP/1.x sockets 29 | * HTTP/2 and HTTP/3 sessions 30 | * WebSockets over shared HTTP/2 and HTTP/3 sessions 31 | * Connections to proxies (though the result of DNS lookups for the hostnames of proxy servers will be shared globally) 32 | * The TLS and HTTP/3 session resumption caches 33 | * Alternative service information, including information about which servers have broken alternative services 34 | * Cache of which servers support HTTP/2 (used to avoid creating extra sockets when establishing a connection to HTTP/2 compatible servers) 35 | * DNS lookups from PAC scripts will use the network partition key of the request causing the PAC script to issue the lookup 36 | * Cached information from Expect-CT headers. 37 | 38 | This particular proposal does not cover some other types of network information. For clarity, here are some types of network information and resources not covered by this proposal, though this is likely not a complete list. 39 | 40 | These objects will likely need to respect the network partition key in the future, but will need to be covered by other explainers and spec work: 41 | 42 | * HTTP cache [already has an explainer of its own](https://github.com/shivanigithub/http-cache-partitioning/blob/master/README.md). 43 | * HTTP auth cache 44 | * Client certs 45 | * Clear-Site-Data header 46 | 47 | Other solutions will likely need to be used for these: 48 | 49 | * [Cookies](https://blog.chromium.org/2020/01/building-more-private-web-path-towards.html) 50 | * HSTS cache 51 | * Cert validation (Both the verification cache itself, and OCSP/CRL/ACA network fetches, which will use a single transient network partition key for now, at least) 52 | * Reporting API. The latest (draft of the spec)[https://w3c.github.io/reporting/] addresses tracking concerns, by making it document-scoped. 53 | * Network error logging 54 | 55 | Some potential cross-site information leaks involve upstream resources that are not under the control of a browser, and others involve trusted third parties and would have a significant performance impact to mitigate. Here are some other potential leaks not currently covered by this explainer, with no work currently planned to address them: 56 | * The browser can't do much about upstream or OS-layer DNS caches, though using DoH without fallback or the built-in DNS resolver will bypass OS caches, at least. 57 | * While DNS resolutions will respect the key, and live lookups will not be merged across network partition keys, partitioning DoH HTTPS requests themselves may not be worth the performance cost. 58 | * Loading a single instance of the configured PAC script would likely require too much memory, and put too much load on servers hosting PAC files. 59 | * PAC script fetches delegated to the OS cannot be keyed on the network partition key. 60 | * On platforms where certificate validation is deferred to the OS, the OS itself will likely cache any data it needs to fetch from the network (e.g. for revocation checks or AIA fetches). 61 | 62 | ## Performance 63 | 64 | We expect partitioning network state to cause a modest reduction in performance, since connections can no longer be shared with cross-site iframes, or across different top-level sites. It’s also less likely that we’ll have HTTPS/QUIC session resumption information for a network partition, and we’ll be less likely to use QUIC for the initial connection to a site. 65 | 66 | Our current experiment is small, and shows a performance change that’s generally within the margin of error. We’ll release numbers once the experiment is larger, and we have more confidence in the accuracy of our numbers. 67 | 68 | ## Acknowledgements 69 | This explainer takes heavy inspiration from Shivani Sharma’s [HTTP cache partitioning explainer](https://github.com/shivanigithub/http-cache-partitioning/). It also reflects extensive feedback from Josh Karlin and Paul Jensen. 70 | -------------------------------------------------------------------------------- /security-privacy-questionnaire.md: -------------------------------------------------------------------------------- 1 | ### 2.1. What information might this feature expose to Web sites or other parties, and for what purposes is that exposure necessary? 2 | 3 | While the entire purpose of this feature is to expose less cross-site information to web sites, it does, however, potentially make some types of information easier to probe. Global limits, for instance, potentially become easier to reach. This is a pre-existing issue, however, and sharding data doesn't make it that much easier to abuse. 4 | 5 | ### 2.2. Is this specification exposing the minimum amount of information necessary to power the feature? 6 | Regardless of what data is being exposed, is the specification exposing the bare minimum necessary to achieve the desired use cases? If not, why not and why expose the additional information? 7 | 8 | This feature doesn't directly expose any new information to sites - it hides information. 9 | 10 | ### 2.3. How does this specification deal with personal information or personally-identifiable information or information derived thereof? 11 | ### 2.4. How does this specification deal with sensitive information? 12 | 13 | The specification doesn't directly deal with any PII. It does shard network connections by top-level site. Since reused network objects could be used to indirectly learn about what other sites a user visits (e.g., through timing attacks), this specification should improve user privacy. 14 | 15 | ### 2.5. Does this specification introduce new state for an origin that persists across browsing sessions? 16 | No, though it does make state that was originally per origin now be per-top-level-site-per-origin. 17 | 18 | ### 2.6. What information from the underlying platform, e.g. configuration data, is exposed by this specification to an origin? 19 | No new configuration information is exposed. 20 | 21 | ### 2.7. Does this specification allow an origin access to sensors on a user’s device 22 | No. 23 | 24 | ### 2.8. What data does this specification expose to an origin? Please also document what data is identical to data exposed by other features, in the same or different contexts. 25 | This exposes no new data to an origin, though it does shard existing data by top-level site to prevent users being tracked based on per-origin data. 26 | 27 | ### 2.9. Does this specification enable new script execution/loading mechanisms? 28 | No. 29 | 30 | ### 2.10. Does this specification allow an origin to access other devices? 31 | No. 32 | 33 | ### 2.11. Does this specification allow an origin some measure of control over a user agent’s native UI? 34 | No. 35 | 36 | ### 2.12. What temporary identifiers might this this specification create or expose to the web? 37 | This specification attempts to further shard network state, much of which can implicitly be used as user identifiers (reused connection, alternative service information, DNS cache entries, etc). 38 | 39 | ### 2.13. How does this specification distinguish between behavior in first-party and third-party contexts? 40 | It keys network state on first-party site. It currently leaves open whether network state used in third-party context network state will additionally be keyed on third party site or not. Otherwise, it doesn't distinguish between the two. 41 | 42 | ### 2.14. How does this specification work in the context of a user agent’s Private Browsing or "incognito" mode? 43 | It works much the same as it does in standard browsing mode. 44 | 45 | ### 2.15. Does this specification have a "Security Considerations" and "Privacy Considerations" section? 46 | No. The spec was added directly to the Fetch spec. The fetch spec, for better or worse, is specified as a set of prescriptive rules without any comments, reasoning, or motivations, so such a section would seem out of place there, given the current style. That aside, partitioning network state should be a net privacy and security positive, better isolating top-level browsing contexts from each other, which providing no new avenues for attacks. 47 | 48 | ### 2.16. Does this specification allow downgrading default security characteristics? 49 | No. 50 | 51 | ### 2.17. What should this questionnaire have asked? 52 | N/A 53 | --------------------------------------------------------------------------------