SafeBrowsingLookupMechanism
is the base class and we have three implementations for it, hash_realtime == V5 (send partial hash of the URL to the server through a proxy), url_realtime == Protego (send URL to the server), hash_database == V4 (check against the local blocklist), worth mentioning that SafeBrowsingLookupMechanismRunner
controls LookUpMechanism and sets a timeout for the mechanism to run within. The timeout is defined at the top of the class.
When the check is required in the remote DB, it delegates the call to ApiHandlerBridge
, which uses JNI to call StartURLCheck on SafeBrowsingApiBridge. ApiBridge uses the SafetyNetApiHandler
(Soon to be SafeBrowsingApiHandler) to make the startUriLookup
call, the next section talks about WebView specifics.
See the relevant Chromium classes in //components/safe_browsing/.
One of the main classes in WebView implementation is AwUrlCheckerDelegateImpl which defines the 4 threat types WebView support in the constructor, it calls WebViewClient#onSafeBrowsingHit to allow the app to respond, also it handles the app’s response to the callback, the default behavior is to show interstitial by calling ui_manager->DisplayBlockingPage
. When the callback returns backToSafety() or the user clicks “back to safety” button in the interstitial the class triggers onReceivedError()
callback.
WebView has its own allowlisting mechanism which lives in AwSafeBrowsingAllowlistManager, it was implemented to serve a specific API, setSafeBrowsingAllowlist, and that doesn’t have anything to do with the allowlisting in //components (WebView uses both of them but they are unaffiliated).
Any WebView Safe Browsing UI specific logic is being managed by AwSafeBrowsingUIManager, that includes creating the interstitial based on the error.
Depending on which Safe Browsing features you need to test, you may need to build WebView from an upstream (public) or a downstream (internal) build target.
Upstream (public) WebView targets support a limited form of Safe Browsing. WebView only supports blocking hard-coded URLs, but this is sufficient if all you need is to create an interstitial for testing. You can build and install system_webview_apk
(see quick start).
The WebView we ship to users is based on downstream (private) build targets. If you need to test the GMS-based implementation which we use to block real malware, you need to build one of the downstream targets. See Google-internal instructions.
If Google Play Services (AKA GMSCore) is uninstalled, disabled, or out-of-date, WebView cannot perform Safe Browsing checks (with the exception of hard-coded URLs). Before trying Safe Browsing locally, make sure this is up-to-date:
$ adb shell am start -a "android.intent.action.VIEW" -d "market://details?id=com.google.android.gms" # Then, manually update GMS in the UI.
If Google Play Services is installed, the user must opt into Google Play Protect's “Verify Apps” setting: Settings > Google > Security > Google Play Protect > Scan device for security threats
.
Safe Browsing is enabled by default, but applications can explicitly disable it with a manifest tag:
<manifest> <application> <meta-data android:name="android.webkit.WebView.EnableSafeBrowsing" android:value="false" /> ... </application> </manifest>
WebView supports Safe Browsing checks (for testing purposes) on hard-coded WebUI URLs defined in //components/safe_browsing/core/common/web_ui_constants.cc
(ex. chrome://safe-browsing/match?type=malware
).
These URLs don't show meaningful content, but will trigger an interstitial when trying to navigate to them. WebView relies on these URLs in our CTS tests, so they must never change (but more URLs may be added).
See this page.
Automated tests live here.
You can manually test Safe Browsing with the WebView Shell. Navigate to one of the hard-coded URLs mentioned above.
To test more complex scenarios and WebView's Safe Browsing APIs, please try out the open source WebView demo app.
As Chrome supports more threat types, so can WebView. The steps are:
WebViewClient.java
, please consult a WebView team member before this step). The new threat type constant should only be used when the application targets the new Android SDK: use SAFE_BROWSING_THREAT_UNKNOWN for apps with older targetSdkVersions (see http://crbug.com/887186#c15 and http://b/117470538).