Revive SplitHostCacheByNetworkAnonymizationKey [chromium/src : main]
Kenichi Ishibashi (Gerrit)
Kenichi Ishibashi added 1 comment![]( "Open in Gerrit")
mmenke@: PTAL, we want to run a holdback experiment to disable host cache network isolation, just for perf investigation. We don't plan to disable DNS network isolation at this point.
Related details
- mmenke
Code-Coverage
Code-Owners
Code-Review
Review-Enforcement
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Kouhei Ueno (Gerrit)
Kouhei Ueno voted Code-Review+1![]( "Open in Gerrit")
- Kenichi Ishibashi
- mmenke
Code-Coverage
Code-Owners
Code-Review
Review-Enforcement
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
mmenke (Gerrit)
mmenke added 1 comment![]( "Open in Gerrit")
Looks like you already have the +1 you need, so I'm going to defer to Kouhei.
Also, rare is it for me to refuse to have anything to due with a feature due to disagreement with the direction a CL is taking us (in fact, I'm not sure I've ever done that before), but in this case, I'm going to do that. I feel that no thought has gone into the privacy or security issues here, given the fact that no doc has covered them. It's not so much that I'm completely confident that this is a bad idea, but rather that I don't feel anyone on the critical path here has given any thought to whether it is.
I feel that the sole focus here has been trying to eek out a bit of performance, while throwing everything else aside. Maybe there's been more thought invested here than I'm aware of, but I'm skeptical of that, given the multiple docs on this without any security and privacy sections discussing the risks.
This feeling is doubtless aggravated a bit by the lack of activity from anyone else on all the Google-generated AI bug reports we're seeing.
Anyhow, I'm not going to try and block this effort, but at this point, I don't want to have anything to do with proceeding here.
Looks like you have the signoff you need, anyways.
Related details
- Kenichi Ishibashi
Code-Coverage
Code-Owners
Code-Review
Review-Enforcement
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Kenichi Ishibashi (Gerrit)
Kenichi Ishibashi added 2 comments![]( "Open in Gerrit")
Looks like you already have the +1 you need, so I'm going to defer to Kouhei.
Also, rare is it for me to refuse to have anything to due with a feature due to disagreement with the direction a CL is taking us (in fact, I'm not sure I've ever done that before), but in this case, I'm going to do that. I feel that no thought has gone into the privacy or security issues here, given the fact that no doc has covered them. It's not so much that I'm completely confident that this is a bad idea, but rather that I don't feel anyone on the critical path here has given any thought to whether it is.
I feel that the sole focus here has been trying to eek out a bit of performance, while throwing everything else aside. Maybe there's been more thought invested here than I'm aware of, but I'm skeptical of that, given the multiple docs on this without any security and privacy sections discussing the risks.
This feeling is doubtless aggravated a bit by the lack of activity from anyone else on all the Google-generated AI bug reports we're seeing.
Anyhow, I'm not going to try and block this effort, but at this point, I don't want to have anything to do with proceeding here.
Looks like you have the signoff you need, anyways.
I'm sorry I wasn't considerate enough in may ways. Let me loop in haraken@ and kouhei@ for these aspects.
I would also like to discuss the lack of response to AI bug reports within the team. Cc-ing visiedo@.
Regarding this CL, I plan to submit this CL so that we can have a way to start an experiment. We'll carefully consider whether we run it.
mmenke@: Thank you for your feedback.
+haraken@ and +visiedo@ for discussion.
Related details
- Kentaro Hara
- Kouhei Ueno
Code-Coverage
Code-Owners
Code-Review
Review-Enforcement
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Kentaro Hara (Gerrit)
Kentaro Hara added 1 comment![]( "Open in Gerrit")
Kenichi IshibashiLooks like you already have the +1 you need, so I'm going to defer to Kouhei.
Also, rare is it for me to refuse to have anything to due with a feature due to disagreement with the direction a CL is taking us (in fact, I'm not sure I've ever done that before), but in this case, I'm going to do that. I feel that no thought has gone into the privacy or security issues here, given the fact that no doc has covered them. It's not so much that I'm completely confident that this is a bad idea, but rather that I don't feel anyone on the critical path here has given any thought to whether it is.
I feel that the sole focus here has been trying to eek out a bit of performance, while throwing everything else aside. Maybe there's been more thought invested here than I'm aware of, but I'm skeptical of that, given the multiple docs on this without any security and privacy sections discussing the risks.
This feeling is doubtless aggravated a bit by the lack of activity from anyone else on all the Google-generated AI bug reports we're seeing.
Anyhow, I'm not going to try and block this effort, but at this point, I don't want to have anything to do with proceeding here.
Looks like you have the signoff you need, anyways.
I'm sorry I wasn't considerate enough in may ways. Let me loop in haraken@ and kouhei@ for these aspects.
I would also like to discuss the lack of response to AI bug reports within the team. Cc-ing visiedo@.
Regarding this CL, I plan to submit this CL so that we can have a way to start an experiment. We'll carefully consider whether we run it.
Regarding privacy / security impact, I think we've fully analyzed it when we launched the partitioning a few years ago and decided to go with 2.5 key partitioning (Example doc: https://docs.google.com/document/d/1T1SFOlRmLyMq8nYvDG7t2r9-SzpkE0Lz3bK3l-XtI0U/edit?resourcekey=0-yihfJ_Z20DTlmXTn9jVmaA&tab=t.0).
The reason I want to run this experiment is to collect new information about performance because the assumptions about performance have changed in the past years (e.g., SearchLatency and Android memory were not evaluated when we launched the partitioning). My plan is to collect the performance numbers on the new metrics, and if the impact is substantial, kick off a discussion of the performance vs. security tradeoff.
Google-generated AI bug reports
I'm working on it with the top priority. Improving the precision of the bug reports, creating a guideline for individual feature teams etc.
Related details
- Kenichi Ishibashi
- Kouhei Ueno
- mmenke
Code-Coverage
Code-Owners
Code-Review
Review-Enforcement
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
mmenke (Gerrit)
mmenke added 1 comment![]( "Open in Gerrit")
Kenichi IshibashiLooks like you already have the +1 you need, so I'm going to defer to Kouhei.
Also, rare is it for me to refuse to have anything to due with a feature due to disagreement with the direction a CL is taking us (in fact, I'm not sure I've ever done that before), but in this case, I'm going to do that. I feel that no thought has gone into the privacy or security issues here, given the fact that no doc has covered them. It's not so much that I'm completely confident that this is a bad idea, but rather that I don't feel anyone on the critical path here has given any thought to whether it is.
I feel that the sole focus here has been trying to eek out a bit of performance, while throwing everything else aside. Maybe there's been more thought invested here than I'm aware of, but I'm skeptical of that, given the multiple docs on this without any security and privacy sections discussing the risks.
This feeling is doubtless aggravated a bit by the lack of activity from anyone else on all the Google-generated AI bug reports we're seeing.
Anyhow, I'm not going to try and block this effort, but at this point, I don't want to have anything to do with proceeding here.
Looks like you have the signoff you need, anyways.
Kentaro HaraI'm sorry I wasn't considerate enough in may ways. Let me loop in haraken@ and kouhei@ for these aspects.
I would also like to discuss the lack of response to AI bug reports within the team. Cc-ing visiedo@.
Regarding this CL, I plan to submit this CL so that we can have a way to start an experiment. We'll carefully consider whether we run it.
Regarding privacy / security impact, I think we've fully analyzed it when we launched the partitioning a few years ago and decided to go with 2.5 key partitioning (Example doc: https://docs.google.com/document/d/1T1SFOlRmLyMq8nYvDG7t2r9-SzpkE0Lz3bK3l-XtI0U/edit?resourcekey=0-yihfJ_Z20DTlmXTn9jVmaA&tab=t.0).
The reason I want to run this experiment is to collect new information about performance because the assumptions about performance have changed in the past years (e.g., SearchLatency and Android memory were not evaluated when we launched the partitioning). My plan is to collect the performance numbers on the new metrics, and if the impact is substantial, kick off a discussion of the performance vs. security tradeoff.
Google-generated AI bug reports
I'm working on it with the top priority. Improving the precision of the bug reports, creating a guideline for individual feature teams etc.
Well, we also have perf numbers from before we deployed partitioning. They're both outdated, and don't reflect the difference of just removing partitioning at this layer. Same issues apply to that doc.
Related details
- Kenichi Ishibashi
- Kentaro Hara
- Kouhei Ueno
Code-Coverage
Code-Owners
Code-Review
Review-Enforcement
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Kenichi Ishibashi (Gerrit)
Kenichi Ishibashi voted and added 1 comment![]( "Open in Gerrit")
Votes added by Kenichi Ishibashi
| Commit-Queue | +2 |
1 comment
- Kentaro Hara
- Kouhei Ueno
Code-Coverage
Code-Owners
Code-Review
Review-Enforcement
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Chromium LUCI CQ (Gerrit)
Chromium LUCI CQ submitted the change![]( "Open in Gerrit")
Change information
Revive SplitHostCacheByNetworkAnonymizationKey
This CL revives the SplitHostCacheByNetworkIsolationKey feature flag as
SplitHostCacheByNetworkAnonymizationKey, which was previously removed in
https://crrev.com/c/5527451.
Currently, DNS partitioning is tightly coupled with the broader
PartitionConnectionsByNetworkIsolationKey feature. Re-introducing this
flag allows us to run an experiment to selectively disable DNS-related
Network State Partitioning (e.g., HostCache partitioning and DoH
connection isolation) while keeping the rest of the network state
properly partitioned.
The feature is ENABLED_BY_DEFAULT by design. Since DNS isolation
requires `IsPartitioningEnabled()` to be true, keeping this flag enabled
by default ensures that we preserve the current state where DNS caching
is split by default when `kPartitionConnections...` is active without
breaking hundreds of existing tests and Finch configs. It only needs to
be explicitly disabled in targeted experiments.
The flag is evaluated alongside the overarching partitioning feature
inside HostResolverManager, and test coverage is updated to verify its
behavior across different configurations.
- M net/base/features.cc
- M net/base/features.h
- M net/dns/host_resolver_manager_request_impl.cc
- M net/dns/host_resolver_manager_service_endpoint_request_impl.cc
- M net/dns/host_resolver_manager_unittest.cc
Code-Review: +1 by Kouhei Ueno
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |