nparker: Is 3 second the max limit for SB checks?

It sounds like in this case that limit is being hit for every resource?

only html and script resource consumed 3 seconds to download as mark in red circle

Deleted: jietu.PNG 162 KB

	jietu.PNG 162 KB View Download

you can also check it in the trace file

Deleted: trace.rar 1.3 MB

trace.rar 1.3 MB Download

keavenmike@gmail.com: 
 * Do you have Google Play Store loaded?  Did you get Chrome from there?
 * What is the version of both Google Play Store and Google Play Services (android settings -> apps -> **)?
 * Does this problem go away when you disable safe browsing (chrome's settings -> privacy -> Safe Browsing)?

The 3 second timeout is when Chrome is waiting on GMSCore to classify a URL as safe/unsafe.  If GMSCore is broken in a way we haven't seen before, this could happen. We do check the Google Play Services version at first-url-check, and Chrome will disable SB if it's not supported.  If it's disabled, it won't wait 3 seconds -- it'll mark it safe right away.  Some of this logic did change with M49 (+dgn).  


UMA metrics show about 2% of these checks timing out in China, and 20% (!) are marked as unsupported. The latter is likely side-loaded chrome w/o play store, and if so it's WAI.  The 2% may be representing some new class of breakage matching this bug.  According to UMA, only a few hundred users are affected, but I'm sure UMA doesn't get much data from China. graphs: https://goto.google.com/bfukvb

nparker@chromium.org:

We do not install Google Play Store on our devices
Google Play Services version:  8.3.01(2385995-440)
The problem do go away without safe browsing, and it can also be resolved by installing Google Play Store(6.4.12.C-all[0]2744941) with proxy.

As we all know, most request to google service including SB check will be blocked by GFW in China mainland. That's why every SB check hit the 3 seconds limit. 
So why not disable SB check by default in China just like Data Compression Proxy, which can end the problem.

There is a question:
If the 3 second timeout is when Chrome is waiting on GMSCore to classify a URL as safe/unsafe, why the problem still there after i delete GmsCore.apk

nparker@:

The logic to check the availability of a compatible GMSCore version has not changed. The right version is there, but if the GFW is blocking everything, it makes sense that we hit the timeout every time. The 2% would be people side-loading GMSCore?

keavenmike@:

Do you still have logs where the issue reproduces? I'd be curious to see the logs at the cr_SafeBrowsingApi tag. We should mention that SafeBrowsing is disabled when GMSCore is not available.

About the repro after uninstalling GmsCore: did you try killing and restarting Chrome? we check the availability on startup, and might not have noticed that it's gone.

I have reboot the device after deleting GmsCore.apk, but the problem still there.

Deleted: android_logs.rar 1005 KB

android_logs.rar 1005 KB Download

I don't think the 3 second delay is due to the GFW blocking requests to Google, since, a) in normal conditions only abut 1/1000 of URLs require a call to Google to classify, and b) in this case GMSCore should have gotten 0 updates to it's DB, and thus have nothing to pass through to Google. 

dgn@: I agree the 2% could be those sideloading GmsCore, though now if the problem persists with GmsCore.apk missing, then something else it going wrong with our version detection since we're not failing-fast. 

+williamluh@: Do you know why installing Google Play Store would help here?  How does that interact with GmsCore? (#6)

There should be no interaction with Google Play Store as far as the Safe Browsing API is concerned. Google Play Services (GmsCore) and Google Play Store are two completely separate entities so I am confused by how installing Play Store in Comment #6 can fix anything.

dgn@ & nparker@:
Try it again, i uninstall GmsCore from android->settings->apps instead of just deleting the apk from /system/app/GmsCore the problem do go away. 

By the net log(marked with red line) in trace file i offered before, it is confirm that both the url http://sina.cn and it's script resources will trigger SB Check.

We can also see the fake ip from GFW which blocked the real requests to Google, marked with red circle in the tcudump log.

williamluh@:
About the help of Google Play Store, we try several tests as follow:

case1: Install Google Play Services only                        => 3 seconds delay
case2: Install both Google Play Services and Google Play Store  => no delay
case3: Install Google Play Store only                           => no delay
case4: Install neither                                          => no delay

versions
Google Play Services：8.7.03 (2645110-236)
Google Play Store：6.4.12.C-all [0] 2744941

Deleted: netlog.PNG 79.7 KB

	netlog.PNG 79.7 KB View Download

Deleted: tcpdump.PNG 107 KB

	tcpdump.PNG 107 KB View Download

Deleted: next_4miao_jiazai_chongce.cap 548 KB

next_4miao_jiazai_chongce.cap 548 KB Download

This 3-second timeout behaviour is similar to what's reported in  http://crbug.com/603968 .

I can't repro this on my dev phone.  If I uninstall Google Play Services (via settings->apps), Chrome correctly short-circuits the SB checks, and increments the "unsupported" bucket (7) in chrome://histograms/SB2.RemoteCall.Result.

 nparker@:
Can you tell me the code location where SB check the Google Play Services version at first-url-check(#4)

I tried the issue between chromium49 and chrome49, the result is as follow:
chromium(49.0.2623.91)     => no delay
chrome(49.0.2623.105)      => 3 seconds delay
Please see user video shared on YouTube :https://www.youtube.com/watch?v=PVXF6TFsG_Q

It seems like the problem is related to the modify between 49.0.2623.91 and 49.0.2623.105. How can i find those changes?

The changes between 49.0.2623.91 and 49.0.2623.105 are listed at https://chromium.googlesource.com/chromium/src/+log/49.0.2623.91..49.0.2623.105?pretty=fuller&n=10000

Chromium builds do not support safe browsing, since the feature requires first-party (internal) GMSCore API calls.  So that's why there's no delay on that chromium build.

The opensource code that checks URLs ends here:
https://code.google.com/p/chromium/codesearch#chromium/src/components/safe_browsing_db/remote_database_manager.cc&l=256
The internal code (for those w/ access) is in safe_browsing_api_handler_impl.cc

The related bug  http://crbug.com/602560  was resolved when the user "updated their phone."

 nparker@:

  I do not think uninstalling GmsCore is a wright resolution, since it will invalidates Google apps which depend on Google Play Service.
  
  Why not add the check of location, we should cancel SB check if the location is China even though the Google Play Services version is ok. 
  In the other words, we only continue the SB check with the right Google Play Services version out of China. Can we add this logic? Mr nparker!

It sounds more like there is a strange interaction with the Play store there. You said installing it solves the issue? I tried disabling Play Store on my device and couldn't reproduce the issue.

williamluh@: Any idea of what might be happening? I feel like the Play services should be detecting and reporting the error. After all, many apps should be facing the same sort of issues, right?

 dgn@:
   Yes, this issue do have a relationship with Google Play Store that we can not explain now.

   As the 3 seconds delay is caused by GFW, the problem can only be reproduce in China. Do we have committers of Safebrowsing in China who can reproduce it.

I don't think we have evidence the 3-second delay is caused by the GFW (see my #10).

keavenmike@:
  * Does the tcpdump show request attempt Google for every resource, or just at the beginning of the session? 
  * Can you gather the results of chrome://histograms/SB2 after restarting chrome and then browsing to a site (w/ the 3-second delay happening)?

It only attempt Google ant the beginning of the session.
the histograms results is as follow.

Can you tell me why every SAFE_BROWSING_DEFERRED consumed 3 seconds in the netlog i offered #12, if it is not caused by GFW.

Deleted: Screenshot_2016-04-21-01-02-09.png 61.0 KB

	Screenshot_2016-04-21-01-02-09.png 61.0 KB View Download

Is that the only histogram in chrome://histograms/SB2?  There are normally a few more.  That "#1" bucket indicates all queries to GMScore are timing out (fits with your description).

The SAFE_BROWSING_DEFERRED state is when Chrome is waiting on a check request to GMSCore.  GMScore can normally respond "safe" to the vast majority of those requests w/o any network activity on its part.

I looked at the logs from #9 adn didn't see anything relevant, but I'm not sure what to look for.

Do you mean the 3 seconds is consumed by GMSCore when it check if a request is safe, and this is a problem of GMSCore? If the SB api in GMSCore is open for other browsers such as firefox?

The histograms of chrome://histograms/SB2 is as follow

Can you explain the meaning of each item in that histogram and the circuit of Safe Browsing.

Deleted: Screenshot_2016-04-21-09-33-15.png 188 KB

	Screenshot_2016-04-21-09-33-15.png 188 KB View Download

The 3 second delay is in Chrome while it's waiting for GMSCore to respond.  The API is not currently used by any other app, and is not public.

The histograms show that all resources are hitting that 3-second delay, except  few that were skipped due to having unsupported scheme.  There's not much else useful there.  The desc of each can be found in histograms.xml in chromium.

How prevalent is this issue?  Is it appearing on other/all devices in China?  Does chrome work otherwise in china?

All M version devices including Samsung Galaxy S6 SM-G9208(6.0.1) and HUAWEI MATE 8 TL00(6.0.0) , which have a GMSCore preseted within factory data will have this problem.  It is certain that the prevalent is more than 2%.

I will email you a link to download 48.0.2564.97 so you can test if that version has the same issue as M49.  What specific version(s) of M49 has the issue?

I have tested it, the M48 you provided have the same issue.
The specific version(s) of M49 is 49.0.2623.105

The new release chrome(50.0.2661.89)  have fixed this problem，it do not trigger SB check in China. Can we find out which change in the new release change list fixed it?

If it's fixed, I'm not too concerned about determined which CL did it.

BTW the general recommendation is that Android users in China should not sideload GMSCore since it depends so heavily on contacting Google.  It will spend a lot of battery repeatedly trying to do so.