Please let me know if there is some alternative solution that I am missing here. Even with option B it seems like the solution to the below problem is less secure than the affliction. Which further begs the question: Can we even adequately address this bug without [this](https://bugzilla.mozilla.org/show_bug.cgi?id=1788109)? The Problem: From what I can tell we [aren't sending secure cookies](https://searchfox.org/mozilla-central/source/netwerk/cookie/CookieService.cpp#1048-1051) to non-secure origin processes. So in the case where Tab 1 has https://example.com secure cookie and we attempt an overwrite on the same cookie name with an insecure cookie on Tab2 for http://example.com, we have a limitation with the current plumbing in that we can't know which secure cookies are in the jar. Two options readily come to mind: A. Send all cookies for the relevant base domain + OA (including the secure ones) from the cookie jar in the parent process to the matching child. But this seems like a step backwards in terms of security and cookie isolation, especially if we continue to move towards more schemeful separations. B. Some kind of additional signalling from parent to relevant content processes that we are holding cookies of these name-host-path, without telling the content process what the values are. Additionally: Assuming we get this working. I'm concerned about the edge case behavior if we: 1. Tab 1: set insecure cookie "test=yes" on http://example.com 2. Tab 2: set secure cookie "test=overwrite; Secure" on https://example.com. Step 2 overwrite shouldn't be able to make it to Tab 1's process. I'm guessing we should clear the cookie in Tab 1 process so that we don't create another de-synchronization.
Bug 1783536 Comment 14 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
Please let me know if there is some alternative solution that I am missing here. Even with option B it seems like the solution to the below problem is less secure than the affliction. ~Which further begs the question: Can we even adequately address this bug without [this](https://bugzilla.mozilla.org/show_bug.cgi?id=1788109)?~ The Problem: From what I can tell we [aren't sending secure cookies](https://searchfox.org/mozilla-central/source/netwerk/cookie/CookieService.cpp#1048-1051) to non-secure origin processes. So in the case where Tab 1 has https://example.com secure cookie and we attempt an overwrite on the same cookie name with an insecure cookie on Tab2 for http://example.com, we have a limitation with the current plumbing in that we can't know which secure cookies are in the jar. Two options readily come to mind: A. Send all cookies for the relevant base domain + OA (including the secure ones) from the cookie jar in the parent process to the matching child. But this seems like a step backwards in terms of security and cookie isolation, especially if we continue to move towards more schemeful separations. B. Some kind of additional signalling from parent to relevant content processes that we are holding cookies of these name-host-path, without telling the content process what the values are. Additionally: Assuming we get this working. I'm concerned about the edge case behavior if we: 1. Tab 1: set insecure cookie "test=yes" on http://example.com 2. Tab 2: set secure cookie "test=overwrite; Secure" on https://example.com. Step 2 overwrite shouldn't be able to make it to Tab 1's process. I'm guessing we should clear the cookie in Tab 1 process so that we don't create another de-synchronization.