On a side note, we've run into a bunch of issues in general with sharing just subcomponents of URLRequestContexts, and we'd really like to get rid of the ability for consumers to do this (Except perhaps the NetLog, HostResolver, and some proxy configuration stuff).

Since the safe-browsing data is per-install, not per-profile, the SB cookies can't mix with the profile cookies.

I would be somewhat surprised to see anything interesting in the safe-browsing cookie store, because there's no way to login at that level.  So just the "cookies necessary for .google.com to work at all", probably.  I only have a cookie for host=.google.com and name=NID.

At least at the safe-browsing level, I think it would be reasonable to whitelist cookies.  I'm not suggesting that because I love complexity, just that for something not visible like this, I'd hate to find out it was starting to persist tons of irrelevant stuff.

Hmm ... also, safe-browsing has been around long enough that it's also possible that cookies needed to be stored originally, but now they're only stored because we've always stored them.  Maybe it would work fine without cookies, or with a transient store.

Note that the system URLRequestContext, which is what I was suggesting, is global, not per-profile, and is not persisted to disk, so it shouldn't have per-profile cookies in it (In theory, at least...).

I hadn't realized SafeBrowsing was persisting cookies to disk, but you're right, it currently is.

+awoz for the backend need for Cookies.  I think they are used for diagnostics, experiments, and looking for broken clients.

Nathan pretty much summed it up. Used to ensure quality of service.

We're working on componentizing the network stack, so it can potentially be moved out of process, and I don't think we want to make it to be possible to do what SafeBrowsing is currently doing - mixing and matching parts of URLRequestContexts has constantly gotten us into trouble.  (We don't want a method like NetworkService::CreateInstanceThatSharesSomeRandomSubcomponentsWithAnotherNetworkSurfaceButUsesASeparateCookieStore(cooke_store_path, other_network_service))

Seems like it should either switch to an entirely independent instance of the network stack (modulo proxy configuration, logging, and not much else, much like they SystemURLRequestContext vs the profile URLRequestContext), or we need to move it onto one of those two URLRequestContexts.  Just from a simplicity / memory consumption standpoint, I'd rather the latter option, if we can reasonably do it.  If we can't, I can live with the former option.

+battre for privacy concerns of mixing SB cookie store w/ SystemUrlRequestContext.

If we can guarantee we won't send non-SB cookies to SB services, I think the latter could work.

One question while we're here: What happens when login credentials are required from some corp firewall, to access the Internet? Would the System context get access to that? I heard (from sleevi?) SB would fail to talk to Google in these cases, in the current setup.

Yea, SB would fail in that case, since we can't use a user's credentials in that case.  If there are multiple profiles, which user does safebrowsing get its URLRequestContext from?  What if that user logs out?

If the system one doesn't work, could we instead either use domains for safebrowsing only, or use some mechanism to handle this diagnostic data other than cookies?  (like attaching headers directly)

Also, I don't think we're getting those credentials now, are we?  SafeBrowsing creates its own NetworkSession, and I think that's where the HTTP auth cache lives?

Yup, I remember now that the challenge is we don't know which profile has sufficient credentials to get to the Internet. We'd need to keep track of which profile had them, and attach to that. Does other code need such a thing (e.g. UMA)?

For cookies:  Can we, on a per-request basis, control which cookies are sent?  Like, can I say, "For this connection to safebrowsing.google.com, don't send any cookie scoped to *.google.com" 

No, you can't.  Can only send all matching cookies or not.

Could you host SB on a different domain, not under google.com?

That would take quite a bit of work, but may be a reasonable long-term solution. FWIW, API v4 is hosted on googleapis.com, so at least one backend is separated out as of today.

WebView now also requires the use of this custom URLRequestContextGetter since it also needs to have a special cookie jar. If there's not a viable solution to maintain that, we may need to leave this code for now.

WebView is using the SafeBrowsingURLRequestContextGetter just to use its own cookie jar?

RE#16, Yes. 

+timvolodine@ to cc for awareness

I happened upon the original bug to add this request context:  https://crbug.com/103243 

If we really need this, I'd rather we create a completely independent URLRequestContext (We could also attach cookie headers manually, and tell net/ not to attach them but I suspect that doesn't offer sufficient privacy protections), rather than introducing an API that allows NetworkContexts (With different lifetimes...) to depend on each other.

mmenke -- What do you think is the next step?  This is assigned to me, but I don't think I know how to solve this. Would you like to take it?

Not particularly.  :)  I have a ton of other stuff to do, more core to the network service effort.

It may be worth putting off until we're farther along with the network service effort, but worth noting the current code won't work when the network service is running out of process (i.e., there's no option to leave it alone, since there will be no other URLRequestContext in process to steal from).

We will need to do something for AppContexts (apps are deprecated everywhere but ChromeOS), which may need to do something similar, so it's possible we can piggy back off of whatever we end up doing for that.