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 (e.g., “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, the WordPress version, and the blog’s URL and IP address (implicitly).

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

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 firewall — provided that plugin developers use the WordPress Request API to communicate with external sites. WordPress Core obviously does.

The WP_Http::request() function uses a filter called pre_http_request, which allows for preempting an HTTP request’s return value. If the filter returns a non-false value, the HTTP request will be short-circuited and the function will 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 that 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