WordPress: How to Disable BrowseHappy

When you go to the Dashboard of your WordPress site, WordPress checks whether your browser is up-to-date, and displays a notice if it is not (i.e., “You are using an insecure browser!” or “Your browser is out of date!”).

This is probably not a bad thing, but:

• It could be annoying for Linux users (they may have a browser with all security patches backported, yet its version will not be the latest) — I was affected by this issue;
• wp_check_browser_version() function, which implements the check, does that with a call to http://api.wordpress.org/core/browse-happy/1.1/ (or https:// if the SSL support is enabled):

  // include an unmodified $wp_version
  include( ABSPATH . WPINC . '/version.php' );
  
  $url = 'http://api.wordpress.org/core/browse-happy/1.1/';
  $options = array(
      'body'       => array( 'useragent' => $_SERVER['HTTP_USER_AGENT'] ),
      'user-agent' => 'WordPress/' . $wp_version . '; ' . home_url( '/' )
  );
  
  if ( wp_http_supports( array( 'ssl' ) ) ) {
      $url = set_url_scheme( $url, 'https' );
  }
  
  $response = wp_remote_post( $url, $options );
  

  You can see that this code sends your user agent string, WordPress version, and the URL and IP address (implicitly) of the blog.

Strictly speaking, to determine whether the browser is up-to-date, BrowseHappy needs only User-Agent header; it does not need WordPress version and the URL of the site.

Whether this is good or bad, it is, of course, up to you; what personally I dislike here is that WordPress sends much more data than required to check the browser version, and violates the guidelines it enforces for plugin authors: “In the interest of protecting user privacy, plugins may not contact external servers without the explicit consent of the user”. In my personal opinion, these guidelines should apply to WordPress itself as well.

OK, we see that WordPress “leaks the data” by default, and there is no way to opt out of that in the UI. What to do if you do not want this functionality?

Luckily, WordPress allows plugin developers to implement a kind of a firewall — provided that plugin developers use WordPress Request API to communicate with external sites. WordPress Core obviously does.

WP_Http::request() function use a filter called pre_http_request, which allows for preempting an HTTP request’s return value. If the filter returns a non-false value, this will short-circuit the HTTP request and return early with that value.

We can use something like this to filter unwanted requests:

add_filter('pre_http_request', function($ret, array $request, string $url) {
    if (\preg_match('!^https?://api\.wordpress\.org/core/browse-happy/!i', $url)) {
        return new \WP_Error('http_request_failed', \sprintf('Request to %s is not allowed.', $url));
    }

    return $ret;
}, 10, 3);

Alternatively, you can use a plugin which implements this functionality.

Note: even after configuring this filter, it is possible that you still see the warning in the Dashboard. This happens because WordPress caches the check result for some time. You can either wait until it goes away, or, if you have WP-CLI, you can run this:

wp transient delete --all