return buckets.size() == 1U ? buckets[0].min : 0;Liam BradyWhy did this helper function change? Was it just meaningless before (by not consulting the histogram samples), unrelated to the changes in this CL? If so, maybe we can land it first with an explanation, to be clear it's not a behavior change related to the other changes.
At this point, I don't remember why I changed this. The latest iteration has some failing tests that seems to be resolved by changing this back. The original method is doing some weird histogram checking to make sure they're being logged properly, but I think the logic is still sound there, so I'm going to change this back.
As embarrassed as I am to admit it, I think this might be some LLM change from when I was trying to get some tests fixed that I completely missed. go/stake-your-reputation
// Ad frames should not be site-keyed by default.Liam Bradyshould be, I think?
Done
ad_waiter.Wait();Liam BradyAny risk that the ad tagging doesn't get to start before we suspend the navigation with WaitForRequestStart(), and then doesn't get kicked off at all? Would it be safer to call ResumeNavigation() first?
Resolving as I think we can get away without the ad tagging waiter altogether.
// non-ad frame that has been origin-keyed.Charlie ReisI'm not sure about the premise of this test. I think for cases like ad.bar.com(ad_not_on_easylist.bar.com), we wanted ad_not_on_easylist.bar.com to be site-keyed if there was a same-site ancestor ad frame that was site-keyed (and we'll eventually want a test for this - but it doesn't look like this logic is part of this CL). But I'm not sure why we'd want this case to force ad.bar.com to be origin-keyed because it has an origin-keyed same-site sibling frame. Why couldn't we keep the ad as site-keyed in this case? With OAC state being per-origin, it doesn't seem like other.bar.com being origin-keyed should force ad.bar.com to be origin-keyed as well. We also wouldn't want a case like microsoft.com(ad.microsoft.com) to be affected, right? That latter one is probably worth covering in a separate test here.
Liam BradyI agree-- I think I would expect ad.bar.com to be site-keyed in this test, unless I'm missing the reason why it shouldn't be.
I was thinking that a decision for a site should affect all origins within that site, which is why I had originally added this test. Now that I'm thinking about it, a sibling shouldn't be able to affect other siblings, especially if they're cross-origin, so I'll update this.
virtual void OnCalculatedLoadPolicyFinished();Liam BradyI found it a bit unexpected that this is in the middle of some pure virtual functions but it defines an implementation in this class, only to have that overridden in SafeBrowsingChildNavigationThrottle. Is that intentional to provide a default implementation for other derived classes?
I see the overridden version calls this one, but if we always expect the overrides to call that, maybe we should make this pure virtual and put the base implementation into a different function of ChildFrameNavigationFilteringThrottle.
Done. All the logic is now in `SafeBrowsingChildNavigationThrottle::OnCalculatedLoadPolicyFinished`.
void TestSubresourceFilterObserver::OnSubframeEvaluationComplete(Liam BradyIs there a difference between this new method and OnChildFrameNavigationEvaluated, such that we couldn't just reuse OnChildFrameNavigationEvaluated?
I think we might be able to get away without having any observers at all, and just wait for the navigation to finish and check to see what kind of process keying we ended up getting.
I think my original understanding of how the ad tagger works was not fully accurate. It seems that if we have navigation throttles in place, there is blocking happening on the navigation until we have a verdict on whether something is an ad or not, so I think we can just do a normal navigation and not pause it to give the ad tagger time to come up with a decision. I'm going to remove this entirely and see how the bots do, and if they aren't flaking then I think we can greatly simplify how the testing is done.
SiteIsolationPolicy::AreOriginAgentClustersEnabledByDefault(Charlie ReisOne more question, credit to Gemini: does this also need to check that origin-keyed processes are enabled by default, e.g. with `AreOriginKeyedProcessesEnabledByDefault()`? If they aren't, it doesn't seem like we need to change any behavior for ads, do we?
Suppose logical OAC is enabled but origin-keyed processes are disabled (e.g., Android), and suppose an ad frame navigates. We'll enter this block and set oac_isolation_state to logical OAC (i.e., OAC without process isolation). Then we'll call AddOriginAgentClusterStateForBrowsingInstance(), and hit your new `DCHECK(oac_isolation_state != isolation_context.default_isolation_state());`, which seems like it will fail because both states are equivalent to `CreateForOriginAgentCluster(false, false)`. (Let's try to cover this case in a test as well.)
Liam BradyLooks like this was fixed between PS6 and PS9, possibly apart from adding a test for it.
I've added a test for this case. I also put these tests under an `OriginAgentClusterAdBrowserTest` test class just to make inheritance a bit simpler since we're now juggling both the `OriginAgentClusterOacOnlyBrowserTest` class and `OriginKeyedProcessByDefaultBrowserTest` class, which both need ad methods. Feel free to bikeshed the names if you think they can be better.
!url_info.oac_header_request.has_value()) {Liam BradySuppose there was no OAC header and the `oac_isolation_state` was assigned to `isolation_context.default_isolation_state()` two lines above. Also suppose that OAC is globally disabled (e.g., via enterprise policy). Wouldn't we want to skip this override in that case, since otherwise we'd be turning logical OAC on for ads and making them origin-keyed in the renderer (while keeping in the same process), and breaking document.domain for them while keeping it working for everything else? Should there be an additional check similar to `oac_isolation_state.is_origin_agent_cluster()` here?
I'll add an `is_origin_agent_cluster()` check to this statement.
bool is_ad_tagged = false;Liam BradyAre you planning to rename these along the lines of `matches_ad_filter_with_host_` in a future CL, or should we do that here to be consistent with chrome_track_event.proto?
Done
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Code-Review | +1 |
Thanks! content/ LGTM with the questions and changes below.
: enable_origin_agent_cluster_(enable_oac) {Should we require `enable_oac` to be true (with a CHECK) if `enable_origin_keyed_processes` is true?
// BrowsingInstances.Maybe mention the new subresource_filter features as well, which I'm guessing are a pre-req for the ad exclusion logic? Or, do we only need them enabled in the case that we're enabling kExcludeAdsFromOriginIsolation below, and we can move them down there?
if (enable_oac || enable_origin_keyed_processes) {Just curious: do we need this clause? I wouldn't expect kExcludeAdsFromOriginIsolation to affect `enable_oac` behavior if `enable_origin_keyed_processes` isn't enabled, since it should only affect process selection and not agent cluster behavior.
Or is it needed for the new test at the end? If so, that might be worth a comment.
EXPECT_FALSE(content::HasOriginKeyedProcess(child));Let's include an expectation that the main frame has an origin keyed process, in contrast.
EXPECT_FALSE(content::HasOriginKeyedProcess(child));Thanks, this is great now. Can we add a version of this test where `other.bar.com` is a subframe of `ad.bar.com`? I think we were on the fence about whether to make the nested frame site-keyed or not, and we might have decided to do that (in the hopes of reducing process count in a common case without adding too much attack surface)? If the full implementation of that policy isn't done yet, we can have a TODO in the test for what we want the outcome to be.
#include "base/functional/callback.h"nit: Do we still need any changes in this file?
// advertising purposes.It might be worth elaborating on the conditions here (based on the new name), or maybe starting with a TODO that this will be limited to cases where the ad filter detected it based on the host and not just an arbitrary URL pattern or other dynamic state about the frame.
SiteIsolationPolicy::AreOriginAgentClustersEnabledByDefault(Charlie ReisOne more question, credit to Gemini: does this also need to check that origin-keyed processes are enabled by default, e.g. with `AreOriginKeyedProcessesEnabledByDefault()`? If they aren't, it doesn't seem like we need to change any behavior for ads, do we?
Suppose logical OAC is enabled but origin-keyed processes are disabled (e.g., Android), and suppose an ad frame navigates. We'll enter this block and set oac_isolation_state to logical OAC (i.e., OAC without process isolation). Then we'll call AddOriginAgentClusterStateForBrowsingInstance(), and hit your new `DCHECK(oac_isolation_state != isolation_context.default_isolation_state());`, which seems like it will fail because both states are equivalent to `CreateForOriginAgentCluster(false, false)`. (Let's try to cover this case in a test as well.)
Liam BradyLooks like this was fixed between PS6 and PS9, possibly apart from adding a test for it.
I've added a test for this case. I also put these tests under an `OriginAgentClusterAdBrowserTest` test class just to make inheritance a bit simpler since we're now juggling both the `OriginAgentClusterOacOnlyBrowserTest` class and `OriginKeyedProcessByDefaultBrowserTest` class, which both need ad methods. Feel free to bikeshed the names if you think they can be better.
Thanks for the test!
// matching a known ad URL. This only includes filters who match a domain, and
// does not include partial matches.Should this be a TODO until that behavior is added?
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Should we require `enable_oac` to be true (with a CHECK) if `enable_origin_keyed_processes` is true?
Done
Maybe mention the new subresource_filter features as well, which I'm guessing are a pre-req for the ad exclusion logic? Or, do we only need them enabled in the case that we're enabling kExcludeAdsFromOriginIsolation below, and we can move them down there?
Good point. I moved them so they're only enabled if `kExcludeAdsFromOriginIsolation` is also enabled.
Just curious: do we need this clause? I wouldn't expect kExcludeAdsFromOriginIsolation to affect `enable_oac` behavior if `enable_origin_keyed_processes` isn't enabled, since it should only affect process selection and not agent cluster behavior.
Or is it needed for the new test at the end? If so, that might be worth a comment.
This is needed for the crash test at the end. I've added a comment explaining that.
Let's include an expectation that the main frame has an origin keyed process, in contrast.
Done
Thanks, this is great now. Can we add a version of this test where `other.bar.com` is a subframe of `ad.bar.com`? I think we were on the fence about whether to make the nested frame site-keyed or not, and we might have decided to do that (in the hopes of reducing process count in a common case without adding too much attack surface)? If the full implementation of that policy isn't done yet, we can have a TODO in the test for what we want the outcome to be.
Added a test for this case.
nit: Do we still need any changes in this file?
Not anymore. I'll revert this.
It might be worth elaborating on the conditions here (based on the new name), or maybe starting with a TODO that this will be limited to cases where the ad filter detected it based on the host and not just an arbitrary URL pattern or other dynamic state about the frame.
Now that I'm looking at this again, I think we should keep this untouched as `is_ad_tagged_` and then add the `matches_ad_filter_with_host_` boolean in the follow up CL. Since renaming this now doesn't really make any sense.
The TODO added to `content/browser/url_info.h` should be a sufficient documentation of that future effort.
// matching a known ad URL. This only includes filters who match a domain, and
// does not include partial matches.Should this be a TODO until that behavior is added?
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Code-Review | +1 |
Thanks! Still LGTM, though you'll need another reviewer for the components/subresource_filter files.
// advertising purposes.Liam BradyIt might be worth elaborating on the conditions here (based on the new name), or maybe starting with a TODO that this will be limited to cases where the ad filter detected it based on the host and not just an arbitrary URL pattern or other dynamic state about the frame.
Now that I'm looking at this again, I think we should keep this untouched as `is_ad_tagged_` and then add the `matches_ad_filter_with_host_` boolean in the follow up CL. Since renaming this now doesn't really make any sense.
The TODO added to `content/browser/url_info.h` should be a sufficient documentation of that future effort.
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Code-Review | +1 |
Just caught up on this CL and it looks great. LGTM as well!
if (enable_oac || enable_origin_keyed_processes) {The CHECK on line 169 guarantees that this is equivalent to just `enable_oac`, so we could simplify this to that.
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
dcheng@: PTAL at `chrome_track_event.proto`.
alexmt@: PTAL at the following files:
Thanks!
The CHECK on line 169 guarantees that this is equivalent to just `enable_oac`, so we could simplify this to that.
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Code-Review | +1 |
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
void SafeBrowsingChildNavigationThrottle::OnCalculatedLoadPolicyFinished() {Could you explain the switch being made here? I'm a little confused, but it's also been a while since I touched this code.
void SafeBrowsingChildNavigationThrottle::Does this still need to be defined?
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
void SafeBrowsingChildNavigationThrottle::OnCalculatedLoadPolicyFinished() {Could you explain the switch being made here? I'm a little confused, but it's also been a while since I touched this code.
(It's also been a while since I originally wrote this) There were two reasons I needed to make this change.
We want to get this information to the `NavigationRequest` object as soon as possible to give it the best chance at having that information when it needs to select a process. Doing this moves this notification call earlier in the navigation request. We explicitly decided to not affect navigation timing for this, and instead opt for a "best effort" approach. The OKPD ads exclusion feature is a performance optimization, and having a false negative because it didn't show up on time doesn't constitute a security risk, so we deemed this okay to do.
We also needed to handle evaluations that were synchronous and non-deferred, which we needed in place for the browser tests I wrote to work.
Does this still need to be defined?
It looks like this is unused, so this should be safe to remove.
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
void SafeBrowsingChildNavigationThrottle::OnCalculatedLoadPolicyFinished() {Liam BradyCould you explain the switch being made here? I'm a little confused, but it's also been a while since I touched this code.
(It's also been a while since I originally wrote this) There were two reasons I needed to make this change.
We want to get this information to the `NavigationRequest` object as soon as possible to give it the best chance at having that information when it needs to select a process. Doing this moves this notification call earlier in the navigation request. We explicitly decided to not affect navigation timing for this, and instead opt for a "best effort" approach. The OKPD ads exclusion feature is a performance optimization, and having a false negative because it didn't show up on time doesn't constitute a security risk, so we deemed this okay to do.
We also needed to handle evaluations that were synchronous and non-deferred, which we needed in place for the browser tests I wrote to work.
So there are two changes here:
To be honest, I'm a bit confused about the previous state. Navigations only seem to be being deferred if they activated (which I think means we're ad blocking them?). Do you know why we had that before?
cc @cshar...@chromium.org for any thoughts
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Code-Review | +1 |
void SafeBrowsingChildNavigationThrottle::OnCalculatedLoadPolicyFinished() {Liam BradyCould you explain the switch being made here? I'm a little confused, but it's also been a while since I touched this code.
Alex Turner(It's also been a while since I originally wrote this) There were two reasons I needed to make this change.
We want to get this information to the `NavigationRequest` object as soon as possible to give it the best chance at having that information when it needs to select a process. Doing this moves this notification call earlier in the navigation request. We explicitly decided to not affect navigation timing for this, and instead opt for a "best effort" approach. The OKPD ads exclusion feature is a performance optimization, and having a false negative because it didn't show up on time doesn't constitute a security risk, so we deemed this okay to do.
We also needed to handle evaluations that were synchronous and non-deferred, which we needed in place for the browser tests I wrote to work.
So there are two changes here:
- one is to trigger on navigations that aren't being deferred
- one is to trigger on navigations that will be cancelled
To be honest, I'm a bit confused about the previous state. Navigations only seem to be being deferred if they activated (which I think means we're ad blocking them?). Do you know why we had that before?
cc @cshar...@chromium.org for any thoughts
The navigation is deferred if the parent frame is activated (i.e. we are doing ad blocking in them). This throttle is responsible for figuring out if we should block the navigation (or tag it as in ad in the ad tagging case).
That being said, I also don't fully understand this change. I'm not sure how we could possibly support synchronous navigations?
Which exact test breaks here?
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
void SafeBrowsingChildNavigationThrottle::OnCalculatedLoadPolicyFinished() {Liam BradyCould you explain the switch being made here? I'm a little confused, but it's also been a while since I touched this code.
Alex Turner(It's also been a while since I originally wrote this) There were two reasons I needed to make this change.
We want to get this information to the `NavigationRequest` object as soon as possible to give it the best chance at having that information when it needs to select a process. Doing this moves this notification call earlier in the navigation request. We explicitly decided to not affect navigation timing for this, and instead opt for a "best effort" approach. The OKPD ads exclusion feature is a performance optimization, and having a false negative because it didn't show up on time doesn't constitute a security risk, so we deemed this okay to do.
We also needed to handle evaluations that were synchronous and non-deferred, which we needed in place for the browser tests I wrote to work.
Charles HarrisonSo there are two changes here:
- one is to trigger on navigations that aren't being deferred
- one is to trigger on navigations that will be cancelled
To be honest, I'm a bit confused about the previous state. Navigations only seem to be being deferred if they activated (which I think means we're ad blocking them?). Do you know why we had that before?
cc @cshar...@chromium.org for any thoughts
The navigation is deferred if the parent frame is activated (i.e. we are doing ad blocking in them). This throttle is responsible for figuring out if we should block the navigation (or tag it as in ad in the ad tagging case).
That being said, I also don't fully understand this change. I'm not sure how we could possibly support synchronous navigations?
Which exact test breaks here?
Which exact test breaks here?
3 of the tests I added are failing without this change. More specifically from the `OriginKeyedProcessByDefaultBrowserTest` suite:
The only time that the associated `NavigationRequest` is notified that the request is for an ad is the [`navigation_handle()->SetIsAdTagged();` call in `OnReadyToResumeNavigationWithLoadPolicy()`](https://source.chromium.org/chromium/chromium/src/+/main:components/subresource_filter/content/browser/safe_browsing_child_navigation_throttle.cc;l=107;drc=b251030f22d6810f6755262d2182316f60552d60). If we don't need to defer the navigation to determine the ad status ([`DeferStage::kNotDeferring`](https://source.chromium.org/chromium/chromium/src/+/main:components/subresource_filter/content/browser/child_frame_navigation_filtering_throttle.h;l=66;drc=b251030f22d6810f6755262d2182316f60552d60)) (which I believe happens for ad **tagging**; the deferral only happens if we're **blocking** the ad), the browser-side navigation request is never notified about this. Up until this point, this was fine since [the RenderFrameHost is told about this at navigation commit time](https://source.chromium.org/chromium/chromium/src/+/main:components/subresource_filter/content/browser/content_subresource_filter_throttle_manager.cc;l=784;drc=4df3b811351ed1ae108ba833da2322391ca3e558).
The issue is that the browser now needs this information when it's selecting what process to put the resulting frame in, regardless of whether we're deferring the navigation. Which would point to this notification needing to happen in `OnCalculatedLoadPolicyFinished` instead of `OnReadyToResumeNavigationWithLoadPolicy`.
For ad tagging itself (not ad blocking), since that runs in dry run mode, we don't defer, and instead just give the result to the RFH after the navigation finishes. This means that the navigations in the failing browser tests don't defer, so the `NavigationRequest` is never given the ad status, so it assumes this navigation isn't for an ad frame, and the resulting process is origin-keyed, which is incorrect.
That being said, I also don't fully understand this change. I'm not sure how we could possibly support synchronous navigations?
Ah, "synchronous" is referring to the load policy evaluation itself, i.e. we didn't need to defer the navigation in order to figure out whether the navigation is for an ad. I might've not used the best terminology here.
| Code-Review | +1 |
void SafeBrowsingChildNavigationThrottle::OnCalculatedLoadPolicyFinished() {So, this ad tagging logic was only needed when we were blocking, but now we need that signal earlier. I think there's some complexity here if ad tagging is ever undo-able, but for now that's not possible. I think this seems ok to me, thanks for the detail.
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Code-Review | +1 |
| Code-Review | +1 |
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |