Can you indicate where/how the avatar is fetched (by pointing to the code)?

Any use of URLFetcher with the profile's URLRequestContext should be treated as an important bug to resolve.

URL requests that go through the Profile's URLRequestContext should have all of the behaviours of web-initiated loads. If the request is initiated by and processed by the renderer, you will have this behaviour. However, if it's done by the browser process, you will not.

The consequence of using a URLFetcher or any from of non-renderer initiated URLRequest is that you will end up bypassing significant portions of logic responsible for interrogating the user as to what they want to do and how they want to handle things. For example, if fetching the avatar requires authentication with a proxy, a renderer-initiated request will show a tab-associated proxy authentication dialog, while a URLFetcher-mediated request will simply tell the proxy not to authenticate. As a consequence, if the renderer later tries to access a resource for that host, it will fail, because the browser will think that the *user* (the human operator) chose to provide no credentials - and as a result, the user will not be interrogated.

Using any URLRequest handler other than the renderer-initiated URL requesting mechanism will result in that URLRequest (including URLFetcher) making decisions 'on behalf of' the user, without actually asking the user. This can poison socket pools that rely on caching the user's decision, and result in unexpected interactions in which the user did not authorize (or choose to not authorize) a particular action.

<triage>Assigning to vasilii for response</triage>

This is the code https://cs.chromium.org/chromium/src/chrome/browser/ui/passwords/account_avatar_fetcher.cc?sq=package:chromium&dr=CSs&rcl=1482150271&l=20

I confirm that fetching the avatar should not result in asking the user anything. It should just fail silently.

One more point. If the user has used an account on the site then the avatar is likely to be in the cache. We want to retrieve it from there instead of fetching it every time.

Right, so comment #3 is bad behaviour (because we shouldn't use the user's URLRequestContext if we won't go through the same UI and interceptor flow)

Regarding Comment #4, the SystemURLRequestContext (or related) could have a separate cache (I don't recall if it does already). Still, the problems caused by #3 outweigh the benefits for #4.

mmenke@, csharrison@, rdsmith@: contacting you as the owners of content/browser/loader

We currently use the profile's URLRequestContext for
- fetching an avatar tied to the saved credential.
- fetching the association between Android apps and site.

Usage of SystemURLRequestContext doesn't seems right:
- If it doesn't have cache then the performance will be degraded. An avatar is like any other resource may already be in the profile's cache.
- If it has cache then it's probably not cleaned with "Clear browsing data" and it's a privacy leak.

It seems that we would continue to use the profile's URLRequestContext but make it renderer initiated. We always have a Chrome tab for which we request an avatar. Additionally the request should bypass the service workers.
Do you have a suggestion how we should proceed?

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/db776d1a2133ce046f21cec827ef4dea34fb4c6a

commit db776d1a2133ce046f21cec827ef4dea34fb4c6a
Author: vasilii <vasilii@chromium.org>
Date: Fri Dec 23 15:49:25 2016

Add LOAD_DO_NOT_SEND_AUTH_DATA flag to the avatar fetcher.

As discussed with rsleevi@ this is a quick fix that improves the situation. A longer term solution is to be discussed.

BUG=675944

Review-Url: https://codereview.chromium.org/2604603002
Cr-Commit-Position: refs/heads/master@{#440634}

[modify] https://crrev.com/db776d1a2133ce046f21cec827ef4dea34fb4c6a/chrome/browser/ui/passwords/account_avatar_fetcher.cc

I tried to repro so that I could see what the avatar was and judge how related to the tab it was, but I couldn't figure out how to "Save a testing credentials".  Could you give more detail for that repro step?

Speaking just to the information in the bug: If the avatar is associated with the page I think it's reasonable for the request to be initiated in the renderer context.  Having said that, I'm not sure if we have a good way to do that from the browser (Ryan, do you know of one?).  I'm also wary of bypassing service worker--that seems like a dangerous exception to renderer initiated requests to be making.  Can you say more about why you want to bypass service worker?

I agree with Ryan that taking advantage of the cache usage is a secondary goal to making sure the functionality works correctly (in this case not poisoning the authentication cache with non-user specified decisions).  I do agree that not having the privacy leak of leaving things in the system context through a "clear browser context" action is important functionality.

There's currently no general way for the browser to initiate a request that uses a ServiceWorker (Or appcache).  We have magic to do it in the downloads case, I believe, but nothing more general.

The attached screenshot shows the context.

A website can offer the user to save credentials of the form (username, password, URL to avatar). In several cases, e.g., when the user signs in and has >1 credential saved, the user sees a native account selector with the avatar picture as shown in the screenshot.

Deleted: snapshot.png 62.9 KB

	snapshot.png 62.9 KB View Download

So the avatar will generally be fetched from a credential management website (Google, Facebook, etc.)?  (I doubt this actually makes a difference to how we should solve this problem, but it's good to nail down all the contexts.)

Nope, any (secure) domain can host the avatar.

See https://w3c.github.io/webappsec-credential-management/#dom-siteboundcredential-iconurl for the exact requirements on the URL and https://w3c.github.io/webappsec-credential-management/#privacy-chooser-leakage for privacy comments w.r.t. service workers.

The testing site to play around is https://w3c.github.io/webappsec/demos/credential-management/