New issue
Advanced search Search tips

Issue 725206 link

Starred by 2 users

Issue metadata

Status: WontFix
Owner: ----
Closed: Jan 9
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 3
Type: Bug



Sign in to add a comment

Authenticating mandatory proxy could cause all alternative navigations to be considered valid

Project Member Reported by asanka@chromium.org, May 22 2017

Issue description

chrome_omnibox_navigation_observer.cc treats HTTP 407 responses as an indication that the alternate navigation was valid.

E.g.: Typing 'foo' causes the http://foo to be tried as an alternate navigation. chrome_omnibox_navigation_observer.cc attempts to validate the navigation target by issuing a URLFetcher request to that URL. An authenticating proxy can respond with a 407 for any such URL regardless of whether that host exists.

By itself this isn't likely to be harmful, just annoying. I'd suggest not considering 407 to be an indicator of the target hosts' existence.

 
Components: Enterprise
Labels: Enterprise-Triaged OS-All
Likely mainly affects intranet users, right?  Tagging as enterprise.

Any reason you marked this as Untriaged rather than Available?

Comment 2 by asanka@chromium.org, May 22 2017

Status: Available (was: Untriaged)
Marking as available.

Comment 3 by asanka@chromium.org, May 22 2017

It'd affect anyone who's behind an authenticating proxy. And yes, typically this would be intranet users.
pkasting@, you wrote the code that explicitly says 407 indicates a target address exists.  Can you justify why you decided so at the time?
// HTTP 2xx, 401, and 407 all indicate that the target address exists.
bool ResponseCodeIndicatesSuccess(int response_code) {
  return ((response_code / 100) == 2) || (response_code == 401) ||
         (response_code == 407);
}
https://cs.chromium.org/chromium/src/chrome/browser/ui/omnibox/chrome_omnibox_navigation_observer.cc?l=33-37
Cc: jdonnelly@chromium.org
The goal of including 407 was to avoid false negatives -- since this background request can't actually let the user authenticate, we likely can't proceed past it.  So we have to either assume everything behind 407 is real or nothing is.  The former seemed less bad than the latter (which would result in users struggling to navigate to any intranet URL on such intranets).

At least, that was my reasoning.  Maybe I'm wrong.
Project Member

Comment 7 by sheriffbot@chromium.org, Dec 31

Labels: Hotlist-Recharge-Cold
Status: Untriaged (was: Available)
This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
Status: WontFix (was: Untriaged)
pkasting's reasoning in C#6 seems good.

I agree that false negatives are worse than false positives when it comes to the alternative navigation system.

Sign in to add a comment