Friendly ping?

Friendly pong!

@plinss and I discussed this during our F2F. We agree about the problem (timing attacks), and as a mitigation to the problem at stake, it seems like an acceptable immediate solution.

As for a longer-term solution for this problem, it feels like adding one more key every time we have this kind of problem is trading off security at the expense of the user. Bandwidth, energy, and storage don't come for free - and n-key feels like a short-sighted solution that simplifies the implementation, but eventually, the user is the one who suffers. We briefly discussed ideas like minimum constant load times, like what crypto does as a different way to approach this - have different options ever been considered? (Asking because we did not see any "alternatives" in the explainer. It's worth noting that while this can prevent timing attacks, it probably won't help with attacks like Spectre.)

Thanks for taking the time to think about this!

I assume the question is about using the subframe site as an additional key, as using the main frame site as a key is primarily aimed at addressing cases where sites are collaborating to track the user across sites, which is not a concern that delaying requests could address, and all browsers seem to be in agreement about keying on main frame site (or potentially origin).

We were thinking that while we were adding the main frame site as a key to address privacy concerns, we could add iframe site as well to provide some degree of mitigation against security concerns while we were at it, with minimal additional investment or complexity. As a result, we have not investigated other mitigations for frames in the same tab spying on each other, hence the empty alternatives considered section.

We are in agreement that endlessly adding keys isn't great, as it increases site load and reduces resource reuse, though we've also considered using the ordered set of sites up to the main frame as a key (and are not convinced that's not something worth considering, long term, though I suspect there'd be a difference of opinion there among some interested members of the Chrome team).

That having been said, my team in particular is solely focused on tracking users across top-frame navigations, so the choice we were looking at was between using the subframe as a key and not doing anything for the moment to address cross-frame spying.

We've run into other cases where adding delays seems the only way to solve cross-site spying, short of not reusing sockets. I think that looking general logic to delay requests in a way that preserves privacy may well be worth looking into, though that, of course, does have performance implications to consider, particularly when an existing socket may be available for reuse. Unfortunately, I can't share a bug about the particular case I'm thinking of, since it's not yet public.

Thanks for the quick feedback!

Roughly, this is the kind of mindset we would like to discourage moving forward. :)

We agree that the proposed approach is the most straightforward way to address the immediate concerns, but we'd love to hear about and potentially review a more long-term, wider-scoped solution moving forward. If you folks have any proposals that are worth an early review, we would love to take a look.

(That said, we can't simply consider this review done without a second opinion from @ylafon and @hober)

I'm not sure fixed delays can ever be sufficient when sharing sockets on a per-tab basis, since there are limits on how many outstanding requests can be live at once, even with H2 and H3. Reaching that limit will necessarily delay other requests to an arbitrary degree.

The nice thing about using the entire stack is then SameSite=Lax cookies could be described in terms of Network Partition Key, and I'd argue that a consistent mapping between the two gives more consistent and predictable protections than having their behavior diverge, as it currently does.

@MattMenke2 well, only as long as you don't care about service workers, right (https://github.com/httpwg/http-extensions/issues/1288)?

I said SameSite=Lax, not SameSite=Strict. I think it's just Strict that doesn't match? Admittedly, SameSite=Lax has some weirdness (if a iframes b, and then b navigates to a, we send SameSite=Lax, I believe...But that actually is consistent with using the full path as key).

Is that assuming you would be able to partition service workers in the same way you do network state?

Sorry, should have made that clear. Yes, I think whatever we do, SW (and all storage) should ideally be partitioned by network partition key. If you have B->C->B and use the full path as the key, the inner B would have its own SW, which would certainly a bit funky.

Chrome's current scheme would result in partitioning them effectively the same way as just using top frame site as keys, while using the fully path would result in rather different behavior.

The nice thing about a single key everywhere is that if new features affect the key (e.g., if first party sets are ever standardized - something which, admittedly, I'm personally a bit wary of due to potential user confusion over which sites share user ID), then we just update the key, and everything magically starts using the updated partitioning scheme.

Hi @MattMenke2!

@ylafon and I took a look at this during a breakout this week. Overall we're really happy that you're tackling this work; it's really important to the future of the Web.

I think whatever we do, SW (and all storage) should ideally be partitioned by network partition key. If you have B->C->B and use the full path as the key, the inner B would have its own SW, which would certainly a bit funky.

We have a separate design review request that came in recently, Partitioning Storage, Service Workers, and Communication APIs, and that for them, cookies and network stack related state is out of scope. We hope that you're working with them to make sure that the SW/storage partitioning key is the same as the one you're proposing.

We note that the multi-vendor effort to coordinate on all these types of partitioning questions is happening in the Privacy CG's storage-partitioning repo, which you're hopefully already aware of and pitching in on, which will help ensure that all implementations converge on the same partitioning keys for each kind of partitioned data or state.

Mostly our concern is that there are so many related-but-distinct efforts going on here, we want to make sure that we don't end up with subtly-different and incompatible solutions in each case of partitioning.

Thanks for bringing this to us, and please don't hesitate to come back to us if there are substantive changes that you'd like us to take a look at.

We have a separate design review request that came in recently, Partitioning Storage, Service Workers, and Communication APIs, and that for them, cookies and network stack related state is out of scope. We hope that you're working with them to make sure that the SW/storage partitioning key is the same as the one you're proposing.

FWIW, both efforts use the same partitioning key.

I'm no longer working on partitioning, apart from launching the work this explainer covers to Chrome stable - other folks are working on the storage and cookies partitioning. I may have time in the future to loop back and work on some of the unresolved items (e.g., HSTS, cert caches), but for the moment, I'm only minimally involved in Chrome's ongoing partitioning efforts.