ChromeNetworkDelegate blocks setting/getting cookies and forces pivacy mode for some requests (See OnCanSetCookie, OnCanGetCookie, and OnCanEnablePrivacyMode). We should make all these work with the network service. I believe these are mostly configured through extension APIs, though could be wrong about that.
They may be configured through extension APIs, but the current implementation:
1) Checks Content Settings (based on the target URL and the requesting URL)
2) Notifies the tab (for updating UI about cookies that were blocked/allowed)
What's the separate bug #, for reference?
I agree that splitting it out is useful, which is why I was proposing changing those events in the URLRequest style to be notification-events only, with only a single unified policy consultation.
In any event, the policy (for channel ID and cookies) right now filters through Content Settings, which can be controlled by extensions, but set explicitly rather than as a callback/async event. If we have sufficient context in the request (to know first and third party URL), then I think the caller may be able to set these at time of request, as we already consult policy before starting the request (for Channel ID). That's why I was proposing unifying them into a single state.
The question that I don't have resolved yet, but hope to within the next day or two, is whether:
- It's sufficient to explicitly unify such blocking under a single control
- What the expected redirect behaviours are supposed to be (in the case of 3PCB, whether 3P with cookies blocked -> 1P thus with cookies -> 3P with query string should be 'valid'). If I can get a clear 'no' to that, then we can fully make it a flag at the request initialization that propogates through requests and would only require the policy consultation before the request is initialized.
Hopefully that made sense with the context of the design doc we've been discussing.
The cookie logging bug is issue 789636 . Hrm...Wonder if we should be logging channel ID through a similar mechanism, to reveal to the user all data we're sending to a site.
I agree that it would be great if we can unify them all.
So, Jesse's giving it a go getting up to speed on unifying the privacy mode flags, which is related to this. From the cross-team sync up we held prior to IETF101, it's also clear that we need to treat 3rd-party cookie blocking separate from any notion of a credentials flag (important for both privacy goals and performance), so we can't unify those as a single request flag.
That is, we're going to need two modes:
- Credentials flag (comparable to the CORS notion, but also self-imposed)
- 3PCB flag (unifying the two methods we have into a single method, since content settings only expresses it as a single bit)
The redirect problem is still unsolved, though, and significantly affects the shape of any API here. That is, our two options are to set a flag at the start of the request and have it propagate through redirects, or to set a callback and set it per-hop. The former is cleaner, but is a observable behaviour change in cookie-blocking behaviour, while the latter is consistent with the current behaviour, but not necessarily desirable (and with holes).
Has the network service solved how it will be handling things like CORS policies on redirects yet? Or even where the CORS policies will live? Are those being propagated back to the browser process (now that CORS is out of the renderer)? If so, going the route of maintaining the current behaviour (by dispatching callbacks during each leg of the Request) may be viable for now. Previously, I'd been given to understand it was seen as non-viable because of abstract, underspecified concerns about performance.
I can take a look at this if no one has started (if anyone has, please let me know!).
@sleevi: some of the discussion above seems to be about behavior changes (e.g. independent of getting existing functionality working with network service). If so, let's discuss this in a separate bug, as this should just cover getting network service flag to parity with existing behavior. Regarding CORS, that's still in the renderer.
Hi John,
It sounds like there's some miscommunication, so we should set up a Hangout as appropriate. I think the question from Comment #8 still stands, and the direction being moved towards in Comment #15 (to move it in) seems like it either answers or doesn't answer the question in #8. The description in Comment #8 also applies - namely, that there's opportunity to make sure that the S13N portion of this is done in a principled way, rather than simply converting a known problematic API 1:1, and it seems like doing that could save work both short and long term. That's not about (observable) behaviour changes, but about making sure that there's a sensible API contract, rather than just porting it over directly.
Issue 799935 has the design doc that's worked with the various owners for this functionality.
As mentioned in Comment #3, the API doesn't need to be a 1:1 mapping of the existing APIs, and a more targeted API such as handles those two methods would suffice.
Further, depending on the CORS side (that is, whether or not redirects are processed Service side or Browser side), it's possible to reduce that API into explicitly declarative approaches - namely, whether or not 3PCB is enabled for that domain (when making the request) and what cookies were blocked if that was set (when returning the response).
The CORS implications matter in that if redirects are handled in the Network Service, then it would need to reconsult the browser process on each redirect for the Content Settings for each destination in the redirect to check the 3PCB status, and update the flag as appropriate.
In either event, it either ends up as flag + result set in the response or callback + result set on the response, but doesn't need the parity with the current API, and would benefit from not maintaining the (buggy) API.
[cduvall]: Do we need to keep the legacy path in ChromeNetworkDelegate, or could we move the new implementations into NetworkContext::ContextNetworkDelegate (Which wraps the real network delegate). That way, we can have the new code working in production and remove the old code.
Thought I asked this earlier today on an issue, but I can't find my earlier comment, so maybe got distracted before I posted.
Comment 1 by mmenke@chromium.org
, Nov 29 2017