SBClientDownload.DownloadExtensions metric says there were only 12 .SCF files downloaded in the last 7 days. That is extremely small. It'd be fairly safe for us to mark this file as "dangerous" so it can't be downloaded without a warning.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/25ac3c481a621cec69d1dec92abb7efee9a33d27

commit 25ac3c481a621cec69d1dec92abb7efee9a33d27
Author: nparker <nparker@chromium.org>
Date: Mon May 15 23:05:35 2017

Treat .scf files as dangerous.

hey'll show a warning on every download. These files are very rarely
downloaded, so it won't increase warning fatigue.

BUG= 722524 
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:closure_compilation

Review-Url: https://codereview.chromium.org/2881093003
Cr-Commit-Position: refs/heads/master@{#471941}

[modify] https://crrev.com/25ac3c481a621cec69d1dec92abb7efee9a33d27/chrome/browser/resources/safe_browsing/download_file_types.asciipb

I pushed this as v11 of file_type_policies component update.  It should get to most active clients by tomorrow, if not sooner.

Just for reference per Nathan:

To check if you have the fix: If chrome://components/ has "File Type Policies" at v11, then you have the fix.

Are there plans to communicate this externally so folks know this is no longer a concern and how they can check to verify if they are 'patched'?

Aaron -- What are the plans for external communication about this fix?  I see more news stories appearing, which describe it still as an issue.

+jschuh who can add more color on the severity (or lack there of) of the issue in the first place.

This requires a lot of unusual preconditions to be a practical attack. First, this is blocked by the default configuration of any firewall or NAT--even the local firewall on Windows--so the overwhelming majority of Windows systems just don't have any realistic attacker exposure. Then it's further mitigated by the mix of non-standard, legacy configuration options required to make this a practical concern for Win7+, which is the earliest version we support.

I'll mark it low-severity out of an abundance of caution, but pragmatically speaking the population of real-world users impacted by this is de minimis. It's also public already, so is there any reason to keep it view restricted?

Removing view restrictions.

 Issue 724638  has been merged into this issue.