The thrivethemes.com download of TPM 10.9.1 is blocked by Chrome with "Suspicious download blocked." Originally suspected the bundled ZeroClipboard.swf as the cause. Round 1 invalidated that. This page now runs round 2 to test the revised hypothesis.
Chrome's "Suspicious download blocked" string corresponds to Safe Browsing's reputation-based classifier (distinct from its malware classifier, which surfaces as "This file is dangerous"). The classifier keys on file hash + serving domain + observed-download frequency. Files freshly published from new URLs - including legitimate ones - get flagged until they accumulate positive reputation.
If true, then changing even a single byte (different SHA-256) should make the block disappear, despite the contents being effectively identical.
| # | File | What changed | SHA-256 (first 12) | Expected |
|---|---|---|---|---|
| A | original.zip | Control. Untouched bytes from thrivethemes.com. | 1a08756a82e5 |
blocked |
| E | original-rezipped.zip | Extracted original and re-zipped it. Identical file tree, identical file contents on extraction. Only the archive-level metadata differs - so a different SHA-256. | cce220ac1950 |
should pass |
| F | original-tweaked.zip | Byte-for-byte copy of original.zip with a single \n appended at the end. Smallest possible content delta. Different SHA-256. |
fcf33c45d5c4 |
should pass |
| # | File | Result |
|---|---|---|
| B | no-swf.zip - original minus the SWF | passed |
| C | swf-only.zip - just the SWF, nothing else | passed |
| D | swf-renamed.zip - SWF renamed to .bin | passed |
If E and F both pass:
If E passes but F doesn't (or vice versa): the rule is more subtle - probably URL-pattern + hash combined.
If both E and F are blocked: the trigger genuinely is content-based, and there's something about the archive structure (file count? path patterns? something embedded?) that Safe Browsing flags. We'd need to bisect further.