Added Partitioned HTTP Cache Bypass

[NDevTK]

No description provided.

[terjanq]

Thanks for the pull request! Added three comments.

[NDevTK]

@terjanq I made the changes.

[NDevTK]

@terjanq is there a reason this never got added?

[terjanq]

Hey, as mentioned in the other PR I am busy recently so that was the main reason it wasn't added yet. It's not clear to me why it's working from the bypass description. I'd need to dive deeper into how partitioned cache currently works and whether it's an intended bypass or something the browser should fix (I'd guess the latter). Also, I didn't quite understand the example.

My bet is that it is what happens:

• A key for the partitioned cache is in the form of the triple (top_frame, parent_frame, resource)
• If //example.org loads a resource //example.org/img.png then the key would be (example.org, example.org, example.org/img.png), but when we directly visit the resource then the key is also (example.org, example.org, example.org/img.png) because top_frame === parent_frame.

If you have time to confirm that, it would be great, otherwise, when I get more time I will reach out to folks that implemented this to ask a few questions. It's a nice finding and I think that's something browsers would want to fix!

[NDevTK]

@terjanq (I dont think I need to put this here as your a "participant" for this issue but I did it anyway)

I think your right but you might want to check.

This is an example of how the network_isolation_key changes using chrome://net-export

Normal request by page to image.
{"params":{"initiator":"https://http.cat","load_flags":<Removed>,"method":"GET","network_isolation_key":"https://http.cat https://http.cat","privacy_mode":"disabled","request_type":"other","site_for_cookies":"SiteForCookies: {site=https://http.cat; schemefully_same=true}","url":"https://http.cat/images/200.jpg"},"phase":1,"source":{"id":<Removed>,"start_time":"<Removed>","type":1},"time":"<Removed>","type":100}

Direct .location change to image from different initiator, has same network_isolation_key as above.
{"params":{"initiator":"https://example.com","load_flags":<Removed>,"method":"GET","network_isolation_key":"https://http.cat https://http.cat","privacy_mode":"disabled","request_type":"main frame","site_for_cookies":"SiteForCookies: {site=https://http.cat; schemefully_same=true}","url":"https://http.cat/images/200.jpg"},"phase":1,"source":{"id":<Removed>,"start_time":"<Removed>","type":1},"time":"<Removed>","type":100}

www.example.org is the same key as example.org (eTLD+1)
{"params":{"initiator":"https://www.example.com","load_flags":<Removed>,"method":"GET","network_isolation_key":"https://example.org https://example.org","privacy_mode":"disabled","request_type":"main frame","site_for_cookies":"SiteForCookies: {site=https://example.org; schemefully_same=true}","url":"https://www.example.org/"},"phase":1,"source":{"id":<Removed>,"start_time":"<Removed>","type":1},"time":"<Removed>","type":100}

[NDevTK]

Hopefully its better explained now.

[terjanq]

Thanks for diving into the issue. It seems that this is not an intentional bypass and we'd want to fix that, awesome work once again :)

I will merge since fixing this will probably take some time.