Network Partition Key for reports is not specified #220
Comments
|
To do this, it appears that we need to set the fetch request's client, which is used in https://fetch.spec.whatwg.org/#request-determine-the-network-partition-key. |
|
Right now we set a null client, which appears at first glance to work (i.e. it does not cache the response), but it looks like it reuses a "null"-keyed connection cache (https://fetch.spec.whatwg.org/#concept-connection-obtain) which doesn't seem right. |
|
@MattMenke2 Could you help us understand what's left to do for this in the "create a report request" algorithm? |
|
I'm not sure the fetch standard has a concept of a unique, unshared network partition. I'm not really sure what the next step is here, unfortunately. I know the network partitioning code, I don't know how specs wire it up to the web platform. |
Conversion measurement reports have information collected in two different first party network contexts (publisher page, report destination (?), and are potentially reported to yet a third site. To avoid leaking information between different first party network contexts, the reports should therefore be specified to each use a single-use Network Partition Key.
In Chrome-land, these are known as "Transient NetworkIsolationKey" (NIK predates adding Network Partition Key to the fetch spec, so NIKs and NPKs are basically the same thing), but I don't believe the fetch defines them. They're just NPKs for opaque origins, which the fetch spec allows.
The text was updated successfully, but these errors were encountered: