netpog

Just got this alert today, for the first time. Malware 58081 called on both the uninstaller and its registry key.

I want to look at the list of scan reports, and easily find those that detected anything. Instead, EVERY single scan report has the title "Scan Report". My assumption: somebody made the user-hostile decision to keep the titles of the scan reports short and sweet, to avoid spoiling that lovely white space (between "Scan Report" and the date) with anything useful. This would be another example of UI designers beguiled by the cult of faux simplicitude. Whereas we users want nothing more than obviousness. EXPECTED: Titles like "Scan Report: no detections" versus "Scan Report: 3 PUPs detected" EXPECTED: An easy way to filter the reports, to see only those reports with detections. (Better: delete all those reports with no results.) Instead, I'm apparently expected to click and read every one of these reports. Because I live to stroke my security tools? WORKAROUND EXISTS: I've written a script that uses grep, sed, awk, and uniq to find the actual detections among all those reports, and print them in reverse chron order, one line each, showing date, source json file, and threat name. That really shouldn't be necessary. But it's clearly an easy fix. (My rule of thumb: if *I* can write a script to do something, it's thereby provably easy to do.) - Dan in Boston

The main problem with the new UI, for me at least, is the usual problem with MBAM: lack of obviousness(*). When I open the app, there is no menu! I must click each of the three giant icons to find the options. It's NOT OBVIOUS that scan reports are under "Scanner", whereas items excluded from scans is under "Detection History". The settings icon has most, but not all, scan-related settings. Scheduling is under "Scanner". And you're not likely to look there, because that icon is dominated by the big "Scan" button, suggesting that this icon is to run a scan (or maybe see scanning progress). In fact it's also essential for scan-schedule settings. I'd expect scan reports to be part of "History", but nope. Finally, I want to TRUST my malware protection provider. I expect sober adult tone. I don't want a teenager who goofily burbles, "Awesome! Your computer is protected." cool? And why should roughly 40% of the application's window be given to that text? You could instead provide menus, or other uncool, old-school, actually-useful tools. There's an overall sacrifice of utility to the stark faux-simplicity design fad of the day. (See my thread about the unhelpful titling of the Scan Reports.) (*) One example design bug, showing non-obvious and ill-tested UI: you have to 'just know' that if you click to ignore a threat, you'll be offered the otherwise-invisible "ignore always affordance. - Dan in Boston

Check out the page of "AMTSO Security Features Check Tools." These two are failed by Malwarebytes (Premium 4.0.4). 1. "Detects phishing pages": Malwarebytes does not block the industry-standard test page. 2. "Detects potentially Unwanted Applications (PUAs)": The AMTSO test file is successfully downloaded, without being blocked. However, when scanned, that file IS successfully caught by Malwarebytes, and reported as "PUP.Optional.AMTSO.TestFile". - Dan

In case I'm not the only one who didn't know this, @exile360's advice in comment #18 above is correct and excellent, and helps you exclude those specific Registry Values, not the overall threat. I, too, wanted to exclude those two items from scans, for privacy protection, but I saw no way to do so. Although you can use the Settings to exclude files, folders, websites, applications, and exploit processes (?), the only way to exclude a registry value is after detection, if you de-select those items, then click Next. This is not at all obvious. I submitted a bug report just now, in this comment, which I surely posted to the wrong thread, in the wrong forum, but I'm new here. Dan

Thank you, Mieke, I see that you are of course correct (re how to exclude a registry key). And I appreciate that there may be malware that you cannot otherwise flag, unless you also flag what is, in my case at least, a false positive. Of course better to be more cautious, not less. In light of this, I'll suggest only that the process for excluding registry values is entirely too subtle. I suggest these two enhancements: 1) Bug: The "Add Exclusion Wizard" does not include an option for registry keys/values. This is what led me to believe that it wasn't possible Expected: For all possible exclusions to be available from "Settings : Exclusions : Add Exclusions", rather than having certain "Exclusion Types" accessible only after the item is detected. 2) Bug: Although "Ignore Once" is redundant with the prior screen's "Cancel" button (which is fine), the "Ignore Always" option is very valuable. (Essential, in light of #1, above.) But that option is insufficiently-obvious. Worse, the user is discouraged from finding it: the "Threat Scan Results" screen speaks *only* of quarantine, with no hint that "do not quarantine" is synonymous with "show me the otherwise-invisible and -undisclosed exclusion options". To the contrary, that the screen says explicitly "If you don't want to quarantine ..., click Cancel"! I would be surprised if they were discovered by a first-time user in a proper usability test. (I.e. with undirected prompts, such as: "Yes, that screen includes possible threats, both of which you want to exclude from future MBAM detections. Why don't you exclude them both, now?") Expected: Those buttons to be visible in the "Threat Scan Results" screen. I expect to select items, and then select the action. Almost as good: Have another line of text in that screen: "To exclude any of these options from future scans, unselect them, then click Next." This would be an easier fix to implement, although it remains clunky and non-intuitive. For your consideration... - Dan S, another usability curmudgeon in Boston

I'm pretty sure this refers to two registry keys, both in "hklm\software\[wow6432node\]policies\microsoft\mrt", named dontreportinfectioninformation". (The log file is no-longer available.) In fact, this is a perfectly-safe and -cromulent privacy setting, that does not inhibit the client-side activities of Microsoft's MRT. As the community becomes increasingly aware of the depth of the phone-home behavior of MRT, you'll be hearing more about this one. Problem is, we cannot do so! Short of a blanket exclusion of the threat, there's no affordance -- no means within MBAM -- to exclude a registry key. I'd like to hear from my MBAM scans about other instances of this threat, while excluding these two keys. At least: there's none that I can find. I'd love to be wrong about this detail. There's more discussion of this false positive in this recent forum thread. Thanks for your consideration, and for any help you can give with this one. Dan S

This is confusing, and discourages upgrades entirely. (One user waited until I could tell her which answer to give.) The *strong* implication is that there's a licensing implication. And please note, MB staff, that *everyone* wonders what functional difference there might be. ("Really? It only changes the ads you show me? And why ARE you showing me ads after I've paid for the product, anyway?!?") So this feature subtracts value, with its pure failure to explain either why you're asking or the implications of either answer. That's aside from the arguably trivial value to the user. SUGGESTION: Gather your user data through surveys. Avoid going all Facebook on us, trying to extract data from all the users, while squandering the trust we have in you. Don't be Yahoo: value the trust we have in you, and protect it.