Closed Bug 1053890 Opened 10 years ago Closed 10 years ago

[UX] define user-experience when downloads are detected as malware

Categories

(Firefox :: Downloads Panel, defect)

Product:
Firefox
Component:
Downloads Panel
Platform:
x86
macOS
Type:
defect
Priority:
Not set
Severity:
normal
Points:
8

Tracking

()

Status:
RESOLVED FIXED
Iteration:
34.3

People

(Reporter: madhava, Assigned: sevaan)

References

(Depends on 1 open bug)

Details

(Whiteboard: [ux])

Attachments

(4 files, 3 obsolete files)

Strings for inclusion in Firefox 34
2.51 MB, application/pdf
Details
UX for alerting users to downloaded malware (Update #3)
5.62 MB, application/pdf
phlsa
: ui-review+
Details
Updated Download Panel
134.24 KB, image/png
Details
Updated panel with Blocked "tag"
60.78 KB, image/png
Details 
We recently started using a Google API to check downloaded files for being malware. Firefox doesn't currently allow for a way to override, and it's not obvious that there's a good other anti-virus/malware experience to adopt here. We should define with the user-experience should be.

Related: Bug 1009021 -- I won't say this bug is blocked by those download manager changes, but they should be compatible.
QA Whiteboard: [qa-]
Whiteboard: [ux]
There's actually multiple classes of warnings from this service. We are currently blocking downloads with remote verdicts DANGEROUS and DANGEROUS_HOST. Chrome recently expanded their coverage to also block POTENTIALLY_UNWANTED (http://thenextweb.com/google/2014/08/14/google-expand-safe-browsing-service-flag-malware-makes-unexpected-changes-computer/), and also supports warnings on UNCOMMON which clearly needs a recovery case if we decide to support it.
Flags: firefox-backlog+
Assignee: nobody → sfranks
Status: NEW → ASSIGNED
Iteration: --- → 34.3
Points: --- → 8
QA Whiteboard: [qa-]
Flags: qe-verify-
Incidentally, the Firefox security and privacy ux guidelines will likely be helpful here: 
http://people.mozilla.org/~lco/ProjectSPF/
I found a great and safe test file for testing dangerous downloads: http://www.eicar.org/85-0-Download.html

But I can't find any way to test the Potentially Unwanted or Uncommon files. Does any one have any idea of how I might be able to go about doing so?
Sevaan, those are not implemented in Firefox yet. Those are waiting for this UX! :)
Also I can't resist quoting this line from the page you linked: "We understand (from the many emails we receive) that it might be difficult for you to delete the test file from your PC. After all, your scanner believes it is a virus infected file and does not allow you to access it anymore."
(In reply to [:mmc] Monica Chew (please use needinfo) from comment #4)
> Sevaan, those are not implemented in Firefox yet. Those are waiting for this
> UX! :)

Hey Monica, I just mean to test a Potentially Unwanted/Uncommon file in Chrome, to see how they are handling things.
Hey Sevaan, unfortunately we don't have reliable test urls, short of compiling Chrome yourself. We have this screenshot:

http://cdn1.tnwcdn.com/wp-content/blogs.dir/1/files/2014/08/p.png

And this one:

https://dl.dropboxusercontent.com/u/32496746/chromeux.png
(In reply to [:mmc] Monica Chew (please use needinfo) from comment #7)
> Hey Sevaan, unfortunately we don't have reliable test urls, short of
> compiling Chrome yourself. We have this screenshot:
> 
> http://cdn1.tnwcdn.com/wp-content/blogs.dir/1/files/2014/08/p.png
> 
> And this one:
> 
> https://dl.dropboxusercontent.com/u/32496746/chromeux.png

Thanks Monica. I'll figure it out!
Cool, lemme know if you can sync up next week about this bug -- lmandel said it was reasonable to pre-check-in strings if we were reasonably sure what we want, so maybe we can make 34 instead of 35.
We should get the strings in 34. That means we need them prior to the end of this iteration, with enough time for an engineer to write and check-in a strings patch. Sevaan, is that doable?
Flags: needinfo?(sfranks)
:gavin Yes, I will expedite things and have something for early next week. Is that enough time?
Flags: needinfo?(sfranks)
The sooner the better. Depending on how complex the interaction/code changes are, validating that we have the right strings might be tricky.
Attached is the a draft of the UX for alerting users to downloaded malware.

Madhava: You provided some initial feedback for me regarding the document and I think I have incorporated all your suggestions.

Matej: There are some strings we need to get in to 34. I have taken a stab at writing them (as can be seen in the mockups) and I've put all the text onto slides 23 & 24 to make it easier to review. Do you mind taking a look?
Attachment #8478689 - Flags: ui-review?(madhava)
Attachment #8478689 - Flags: feedback?(Mnovak)
Sevaan, thanks for the quick turnaround on the strings. Since we are doing this work now, we might as well accommodate another class of blocked downloads, UNCOMMON.

The string for that in Chrome is "download.exe is not commonly downloaded and could be dangerous". I suggest that the flow be the same as the potentially unwanted flow, since they are comparable in danger level.

https://code.google.com/p/chromium/codesearch#chromium/src/chrome/common/extensions/api/downloads.idl&l=104

Sorry I don't have a screencap of this.
Brilliant, thanks Monica! I will add UNCOMMON handling to the doc.
Hi Sevaan,

I think this looks great. I love how clear and direct the language is. It really puts Firefox in the position of helping the user while keeping them informed about what's going on.

How would you feel about not using the word "malware," though? (I thought I also saw "spyware" in the doc, but I don't see it on pages 23 and 24.) It's fairly intuitive, but it also sounds like jargon. I love the strings that say what the file will or could do to the user's computer. Do they work without calling it out or naming it specifically?

My other question is "sorry." I'm going back and forth on this one, but I think it might be better without it. It does soften the message, but ultimately we're not sorry that we had to block the download (though we could reword it so we're sorry about the malware rather than the action we're taking).

I also took a stab at cleaning up this long string:

This file was downloaded from a website that may have been compromised. You can search for an alternate download source or try to download the file again later.

Let me know what you think.
I think malware is more accurate than either spyware or virus. Malware is more generic, just software that does bad things. Virus implies replicability and infecting other machines, which may or may not be true. Spyware implies that the malware is sending back information to a mothership or is storing information locally to be retrieved later, which is also not true. Some malware just does terrible stuff like delete your entire hard drive.

> This file was downloaded from a website that may have been compromised. You
> can search for an alternate download source or try to download the file
> again later.

This warning is too specific. The website may not have been compromised. For example, if someone uploads malware to Dropbox then I would say that dropbox has an abuse problem but isn't necessarily compromised. I guess the Chrome warning is similar.
I think malware is more accurate than spyware. And if someone doesn't know what it means, the rest of the sentence "which will harm your computer" should clarify that it is bad.

As for the compromised site sentence, how about we just remove it? The message still reads well:

http://cl.ly/image/3W2g081q2b0D

And :Matej, I'm just going to remove the Sorry. It was more of a "Sorry, to interrupt!" But I think that's just the Canadian in me.
Sorry, this link has :Matej's revised text: http://cl.ly/image/1l2z3L0D2w0R
:Matej, your thoughts on these strings for uncommon downloads?

Doorhanger:

> The file you just tried to save is not usually downloaded and 
> may be harmful. We’ve blocked it just in case!

Modal:

> Are you sure you want to unblock this file?
> 
> The file is not usually downloaded and may be harmful to your 
> computer and/or making unwanted changed to Firefox.
> 
> You can search for an alternate download source or try to 
> download the file again later.
Attachment #8478689 - Flags: ui-review?(madhava)
Attachment #8478689 - Flags: feedback?(Mnovak)
Updated document to include string revisions and Uncommon Downloads.
Attachment #8479143 - Flags: ui-review?(philipp)
(In reply to Sevaan Franks [:sevaan] from comment #20)
> :Matej, your thoughts on these strings for uncommon downloads?
> 
> Doorhanger:
> 
> > The file you just tried to save is not usually downloaded and 
> > may be harmful. We’ve blocked it just in case!

A couple of small tweaks here:

The file you tried to save is not often downloaded and may be harmful. We’ve blocked it just in case!

(I changed "usually" to "often," but I'm still not sure that's right. Is the string saying that the file is common but not commonly downloaded, or that the file type or name itself is uncommon?)

> Modal:
> 
> > Are you sure you want to unblock this file?

No changes.

> > The file is not usually downloaded and may be harmful to your 
> > computer and/or making unwanted changed to Firefox.

I think we can cut the first part here, since it follows a question about "this file":

It may be harmful to your computer and/or make unwanted changes to Firefox.

> > You can search for an alternate download source or try to 
> > download the file again later.

No changes.
Thanks Matej. I like the "not often".

The string is about the file type itself being uncommon to download.
Updated doc.
Attachment #8478689 - Attachment is obsolete: true
Attachment #8479143 - Attachment is obsolete: true
Attachment #8479143 - Flags: ui-review?(philipp)
Attachment #8479210 - Flags: ui-review?(philipp)
Sevaan, thanks again for the fast turnaround. Strings look good to me, thanks for accommodating the as-yet-to-be-decided uncommon case.

Just a few suggestions:
s/We had to block/We blocked -- similar changes to make copy briefer might be good, too

"It may be harmful to your computer and/or make unwanted changes to Firefox"

Users will see this if they use Firefox to download rebundled Chrome and iTunes and IE and so on (e.g., http://internet-explorer-8.en.softonic.com/). The language is accurate, but it may be confusing if they weren't downloading rebundled Firefox or a search hijacking toolbar.
Thanks Monica. Good idea regarding we had to block/we blocked. I won't update all the mockups, but will change the Strings slides.

Any ideas how to better clarify the "It may be harmful" message?
(In reply to Sevaan Franks [:sevaan] from comment #26)
> Thanks Monica. Good idea regarding we had to block/we blocked. I won't
> update all the mockups, but will change the Strings slides.
> 
> Any ideas how to better clarify the "It may be harmful" message?

"This file may be harmful or cause unwanted changes to existing settings or programs"? Either way, s'ok.
(In reply to :Gavin Sharp [email: gavin@gavinsharp.com] from comment #10)
> We should get the strings in 34. That means we need them prior to the end of
> this iteration, with enough time for an engineer to write and check-in a
> strings patch. Sevaan, is that doable?

There are two parts in this user interface, the new type of panel item and the doorhanger. The former is the only one required for the functionality, while the latter is very helpful to clarify what is happening to the user, but not essential to the functionality, as well as quite tricky to implement given the asynchronous panel overlaying code.

Do you think we should pre-land strings for both of them, or should we focus only on the new panel item type for 34 instead?

(In reply to Sevaan Franks [:sevaan] from comment #27)
> Strings for inclusion in Firefox 34

Since it seems we're pre-landing this string, I'll explicitly note that "This file will harm your computer (Learn more) - Unblock" would need to be split in three parts.

I think that not parenthesizing the "Learn more" link would make the implementation easier. Maybe "This file will harm your computer. Learn more - Unblock". This also helps when we'll change the arrangement of those strings in future redesigns. Sevaan, what do you think?
Flags: needinfo?(sfranks)
Flags: needinfo?(gavin.sharp)
(In reply to :Paolo Amadini from comment #29)

> I think that not parenthesizing the "Learn more" link would make the
> implementation easier. Maybe "This file will harm your computer. Learn more
> - Unblock". This also helps when we'll change the arrangement of those
> strings in future redesigns. Sevaan, what do you think?

Hey Paolo, yes, that works fine. Thanks!
Flags: needinfo?(sfranks)
Looks very good Sevaan!

One issue and one question before I r+ it:
1) When attached to the file icon, I initially thought that the white-on-red X icon meant that there was a problem downloading the file.

2) Does it make sense to only show the unblock option in the context menu? If a user is experienced enough to really understand the harm he could do, he probably also expects the option there. This could vary depending on the severeness of the case.
Thanks Philipp,

1) In a way, there /is/ a problem downloading the file... But yes, we can definitely switch those icons. I grabbed it, as well as the warning icon, off a Google Image Search...so we should create our own assets for those during implementation. Would you like me to change the icons in these mockups for now?

2) The unblock option is in the download panel itself next to the Learn More link. The context menu is just an additional placement spot for it. I was against having a big "UNBLOCK" button because I wanted users to read the warning first, rather than just blindly click it.

http://cl.ly/image/2i1V1B2b012L

We can make it blue like the Learn More link to increase visibility, if you think that would be better.
(In reply to Sevaan Franks [:sevaan] from comment #32)
> Thanks Philipp,
> 
> 1) In a way, there /is/ a problem downloading the file... But yes, we can
> definitely switch those icons. I grabbed it, as well as the warning icon,
> off a Google Image Search...so we should create our own assets for those
> during implementation. Would you like me to change the icons in these
> mockups for now?
Let's leave it the way it is if there's going to be a separate icon bug :)

> 2) The unblock option is in the download panel itself next to the Learn More
> link. The context menu is just an additional placement spot for it. I was
> against having a big "UNBLOCK" button because I wanted users to read the
> warning first, rather than just blindly click it.
> 
> http://cl.ly/image/2i1V1B2b012L
> 
> We can make it blue like the Learn More link to increase visibility, if you
> think that would be better.

Oh, I think I came across wrong: I was suggesting to remove that link (at least for known malware). Even if it is already subtle, it is still a click through path.
(In reply to Philipp Sackl [:phlsa] from comment #33)

> 
> Oh, I think I came across wrong: I was suggesting to remove that link (at
> least for known malware). Even if it is already subtle, it is still a click
> through path.

I'm not sure just the context menu is enough...

FWIW, Chrome includes links to unblock on the download page: http://cl.ly/image/0E0M1D3n0d1F

I tried to bury the link to unblock it by making it very tiny and grey like the rest of the text, so the casual user will just glance over it. And if they do happen to click it, they get the strong "ARE YOU SURE?????" as a final step.

What are your thoughts to including a clickable link on the panel itself and putting some telemetry probes to see if people click the link more or right-click to unblock?

However, if you feel strongly about it, I'm also okay with just going with context menus. We can monitor support issues to see if people have a hard time finding it.
(In reply to :Paolo Amadini from comment #29)
> There are two parts in this user interface, the new type of panel item and
> the doorhanger. The former is the only one required for the functionality,
> while the latter is very helpful to clarify what is happening to the user,
> but not essential to the functionality, as well as quite tricky to implement
> given the asynchronous panel overlaying code.

I'm not sure I understand why the doorhanger is complex, but it doesn't seem overly harmful to pre-land strings for both parts.

Can you prepare a strings patch, and get it reviewed/landed before the merge?
Flags: needinfo?(gavin.sharp) → needinfo?(paolo.mozmail)
Following a discussion with :phlsa, we have decided to remove the "Unblock" link on the download panel from Malicious files, but keep it for Potentially Unwanted and Uncommon downloads.

The Unblock in the context menu will still remain for all three warning types.
Attachment #8479210 - Attachment is obsolete: true
Attachment #8479210 - Flags: ui-review?(philipp)
Attachment #8481334 - Flags: ui-review?(philipp)
(In reply to :Gavin Sharp [email: gavin@gavinsharp.com] from comment #35)
> Can you prepare a strings patch, and get it reviewed/landed before the merge?

I'm working on a draft, but I don't think it will be ready and reviewed before the merge on Tuesday. However, we can easily uplift it right after the merge.
Flags: needinfo?(paolo.mozmail)
Iteration: 34.3 → 35.1
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Iteration: 35.1 → 34.3
Attached image Updated Download Panel — 
Slight modification after discussions with Paolo and Phlsa. Now there will no longer be a doorhanger notification, and the download panel will be modified slightly to include a button. The sub-menu in the button would have the option to "Unblock".

Additional new string: "Remove File"

- - - - - - - - - -

For those curious, we decided to remove the doorhanger because it turns out that a check on the file is not performed until the download is complete. So, if a user is downloading a large file, the doorhanger notification would only appear later when the file finishes downloading. It was meant to be an instant feedback to the fact that you clicked on a bad link, but since it is no longer instant, it is no longer useful to have it.

Instead, the download icon will turn red, and the new modified download panel will be displayed.
The strings patch is almost ready. Following up to comment 25 and comment 28, I've slightly edited some messages and I'd like the following to be reviewed first. Monica, do these messages make sense based on the threat represented by the malware check response?

SHORT MESSAGE IN PANEL ITEM

Malware:
 "This file will harm your computer."
Potentially unwanted, uncommon:
 "This file may harm your computer."

LONG MESSAGE SHOWN IN UNBLOCK DIALOG

Malware:
 "This file contains a virus or other malware that will harm your computer."
Potentially unwanted:
 "This file may be harmful or cause unwanted changes to your programs."
Uncommon:
 "This file is not often downloaded, and it may be harmful or cause unwanted changes to your programs."

I've added back "virus" because I believe it is still one of the most understood terms. I've simplified "programs or settings" to just "programs" because "settings" is implied in "unwanted changes". We may also replace "your programs" with "your computer" again, though both are probably clear. What do you think?
Flags: needinfo?(sfranks)
Flags: needinfo?(mmc)
(In reply to :Paolo Amadini from comment #39)

>  "This file contains a virus or other malware that will harm your computer."

I'm good with the inclusion of virus here.

> I've simplified "programs or settings" to just "programs"
> because "settings" is implied in "unwanted changes". We may also replace
> "your programs" with "your computer" again, though both are probably clear.
> What do you think?

I would prefer "programs and settings" rather than just "programs". But I am also good with simply "computer".

Matej can have the final say here.
Flags: needinfo?(sfranks) → needinfo?(Mnovak)
Blocks: 1062966
Ok with me.
Flags: needinfo?(mmc)
(In reply to Sevaan Franks [:sevaan] from comment #40)
> (In reply to :Paolo Amadini from comment #39)
> 
> >  "This file contains a virus or other malware that will harm your computer."
> 
> I'm good with the inclusion of virus here.

Looking at this again, is "will" the right word? Do we know that it will harm the user's computer for sure? I like the bold stance we're taking, but I wonder if "can" is a better word.

"Computer" is starting to stand out to me here as well. That makes me think of the hardware rather than the software. Maybe we should use "programs" here as well.


> > I've simplified "programs or settings" to just "programs"
> > because "settings" is implied in "unwanted changes". We may also replace
> > "your programs" with "your computer" again, though both are probably clear.
> > What do you think?
> 
> I would prefer "programs and settings" rather than just "programs". But I am
> also good with simply "computer".

I prefer "programs and settings" as well. "Settings" may also refer to OS settings, which a user may not associate with "programs."


I also have one change to the long uncommon string:

"This file is not often downloaded. It may be harmful or cause unwanted changes to your programs."
Flags: needinfo?(Mnovak)
> Looking at this again, is "will" the right word? Do we know that it will
> harm the user's computer for sure? I like the bold stance we're taking, but
> I wonder if "can" is a better word.

Matej is right that nothing is for certain: there can be false positives. Whatever word we choose needs to be stronger relatively to the short string we use for potentially unwanted, which currently uses "may." The wording needs to indicate the difference between downloading a file that's straight up malware and one that may change their search settings, for instance.

I dislike adverbs, but nevertheless will suggest one: "will probably" or "will likely"

Malware:
 "This file will probably harm your computer."
Potentially unwanted, uncommon:
 "This file may harm your computer."

After writing that down, I think "will" is better.
(In reply to [:mmc] Monica Chew (please use needinfo) from comment #43)
> > Looking at this again, is "will" the right word? Do we know that it will
> > harm the user's computer for sure? I like the bold stance we're taking, but
> > I wonder if "can" is a better word.
> 
> Matej is right that nothing is for certain: there can be false positives.
> Whatever word we choose needs to be stronger relatively to the short string
> we use for potentially unwanted, which currently uses "may." The wording
> needs to indicate the difference between downloading a file that's straight
> up malware and one that may change their search settings, for instance.
> 
> I dislike adverbs, but nevertheless will suggest one: "will probably" or
> "will likely"
> 
> Malware:
>  "This file will probably harm your computer."
> Potentially unwanted, uncommon:
>  "This file may harm your computer."
> 
> After writing that down, I think "will" is better.

Can we say "is designed to" (or similar)? Viruses and malware are actively malicious. That would make it:

Malware (short):
 "This file is designed to harm your computer."

Malware (long):
 "This file contains a virus or other malware that is designed to harm your computer."
(In reply to Matej Novak [:matej] from comment #42)
> > >  "This file contains a virus or other malware that will harm your computer."
> 
> Looking at this again, is "will" the right word? Do we know that it will
> harm the user's computer for sure? I like the bold stance we're taking, but
> I wonder if "can" is a better word.

The word "will" stood out to me too in the short message, because it is shown even if the user took no further action, but we blocked the file already and so technically there is no active threat. I like "will" in the long message shown when an unblock attempt is made, though.

I don't like "is designed to" because, in the case of a virus, the original file or website was designed to be useful, but the virus modified it to make it harmful.

To better differentiate the malware case from the others, here is my revised proposal.

SHORT MESSAGE IN PANEL ITEM

Malware:
 "This file contains a virus or malware."
Potentially unwanted, uncommon:
 "This file may harm your computer."

LONG MESSAGE SHOWN IN UNBLOCK DIALOG

Malware:
 "This file contains a virus or other malware that will harm your computer."
Potentially unwanted:
 "This file may be harmful or cause unwanted changes to your programs and settings."
Uncommon:
 "This file is not often downloaded. It may be harmful or cause unwanted changes to your programs and settings."

I think "contains a virus" is strong and popular enough to convey the severity of the threat in the short message. I also kept "will harm your computer" rather than "programs and settings" in the long message because, in this case, some malware may have no visible effect on programs and settings, but still unknowingly make your computer a relay for harmful communications or attacks. The word "computer" here does not necessarily make me think of the hardware, as it is often used by the operating system UI to provide access to your data.

Matej is probably the best final reviewer for this.

I think the discussion in this bug, while long and nitpicking, can probably be a starting point for the support article in the "Learn More" link :-)
Flags: needinfo?(Mnovak)
Sevaan: While reviewing the patch in bug 1063105, Marco pointed out that formatting a "BLOCKED: <strikethrough filename>" string may be tricky for some locales.

The solution could be to show "BLOCKED" with no semicolon as a tag near the strikethrough filename, with a border around it. Does it sound right? If we have a border, should we still use all uppercase, or just capitalized like "Blocked"?

An alternative, if we don't want a tag, could be a "BLOCKED: %1" string so that localizers can put the filename where they want, but then we'd have no control over styling or where a long string is truncated (exposing problems similar to the truncated time we sometimes see in the panel's status line).
Flags: needinfo?(sfranks)
Something which concerns me a bit is that "uncommon" files, while not exactly a (drumroll) common occurrence, are still going to be the most common verdict (10x as much as dangerous-host, which is the 2nd most common, from Nightly telemetry). I haven't seen much indication that most of the files are actually dangerous. Experience with Internet Explorer, which gives similarly warnings, suggests the opposite.

Our default warning is a bit guilty-until-proven-innocent like. While encouraging users to be cautions is commendable, the subtext of "it's better to stay away from unknown things and stick to the popular" makes me a bit uneasy.

How do you guys feel about a different attitude for the message, which reflects reality more closer:
"This file may not be safe to open."
"This file is not often downloaded. Firefox cannot tell whether it is safe to open."
(In reply to Gian-Carlo Pascutto [:gcp] from comment #47)
> Something which concerns me a bit is that "uncommon" files, while not
> exactly a (drumroll) common occurrence, are still going to be the most
> common verdict (10x as much as dangerous-host, which is the 2nd most common,
> from Nightly telemetry). I haven't seen much indication that most of the
> files are actually dangerous. Experience with Internet Explorer, which gives
> similarly warnings, suggests the opposite.
> 
> Our default warning is a bit guilty-until-proven-innocent like. While
> encouraging users to be cautions is commendable, the subtext of "it's better
> to stay away from unknown things and stick to the popular" makes me a bit
> uneasy.
> 
> How do you guys feel about a different attitude for the message, which
> reflects reality more closer:
> "This file may not be safe to open."
> "This file is not often downloaded. Firefox cannot tell whether it is safe
> to open."

I like the short string, but my concern with the longer one is that we're not really being all the helpful. Worse, we're admitting that we don't know, which doesn't seem ideal for this kind of warning.

Could we make the strings more similar?

"This file may not be safe to open."
"This file is not often downloaded and may not be safe to open."
Flags: needinfo?(Mnovak)
(In reply to :Paolo Amadini from comment #45)
> 
> SHORT MESSAGE IN PANEL ITEM
> 
> Malware:
>  "This file contains a virus or malware."
> Potentially unwanted, uncommon:
>  "This file may harm your computer."
> 
> LONG MESSAGE SHOWN IN UNBLOCK DIALOG
> 
> Malware:
>  "This file contains a virus or other malware that will harm your computer."
> Potentially unwanted:
>  "This file may be harmful or cause unwanted changes to your programs and
> settings."
> Uncommon:
>  "This file is not often downloaded. It may be harmful or cause unwanted
> changes to your programs and settings."
> 
> Matej is probably the best final reviewer for this.

Not sure if we want to adopt any of the changes from comment 47 and comment 48, but all these strings look good to me.

I like mentioning the virus and malware right in the short string. Great call.
(In reply to :Paolo Amadini from comment #46)

I think the tag idea works. I've mocked up a version of how it could look.
Flags: needinfo?(sfranks)
(In reply to Matej Novak [:matej] from comment #48)

> I like the short string, but my concern with the longer one is that we're
> not really being all the helpful. Worse, we're admitting that we don't know,
> which doesn't seem ideal for this kind of warning.

The truth is that we indeed do not know - and the implication is that we've 
been looking over the users' shoulder for all the other downloads that 
didn't give a warning, but they're on their own for this one, so they'd better 
be careful.

You can consider that if you feel that "may be harmful" is a more informative 
warning, it's being so because we're being more specific and telling the user 
what the worst case is, not because we actually have more information :-)

That said, I can see the point in giving the most "careful" warning to the 
user. Chrome uses "foo.exe is not commonly downloaded and could be dangerous",
IE uses almost the same "foo.exe is not commonly downloaded and may harm
your computer". Given the current browser marketshares, someone who is hosting 
such a file already has to deal with those giving a warning, and it's 
pretty late for us to turn the implied tide of "unpopular = potentially evil".

Another concern about the current warnings: the warnings for uncommon and 
potentially unwanted both use as severity "may be harmful or cause unwanted 
changes to your programs and settings", yet in the latter case the file *has 
actually been scanned and confirmed to do dubious things*, while in the former 
it's just not a popular download.

Compare the explanations here: https://support.google.com/chrome/answer/4412392?hl=en

Some very approximate numbers (they're from Nightly, and we know release will
differ a lot due to usage patterns) show that about 2% of the downloads will
trigger an "uncommon" warning, and 0.3% will hit malware. I'd expect those numbers
to get closer on release, though. We have no data on "potentially unwanted" yet.
Thanks gcp for the explanation, and the reference to the Chrome support page. If the information there reflects the reality of what the verdicts are used for, then it might be worth having that information in our long messages as well.

"This file contains a virus or other malware that will harm your computer."
"This file, disguised as a helpful download, will make unexpected changes to your programs and settings."
"This file is not often downloaded and may not be safe to open."

"This file contains a virus or malware."
"This file may harm your computer."
"This file may not be safe to open."

For the long message of uncommon downloads, we can be more specific, according to the support page:

"This file has been downloaded from an unfamiliar and potentially dangerous website and may not be safe to open."

But I'm not sure whether the claim about the website would always be true.

Comments?
(In reply to :Paolo Amadini from comment #52)

> "This file has been downloaded from an unfamiliar and potentially dangerous
> website and may not be safe to open."
> 
> But I'm not sure whether the claim about the website would always be true.

What claim?

You get the UNKNOWN exactly if the file/site hasn't been scanned by Google,
so that's where the "unfamiliar" comes from. The rest of that sentence isn't
a claim. It's a hypothesis about what could potentially happen, erring on the
careful side at the cost of potentially painting innocent binaries in a 
bad light :-)

To give an example, if I'd compile Firefox Nightly myself, and throw it up on my
personal webspace, you'll likely get that exact warning.
(In reply to Gian-Carlo Pascutto [:gcp] from comment #53)
> (In reply to :Paolo Amadini from comment #52)
> 
> > "This file has been downloaded from an unfamiliar and potentially dangerous
> > website and may not be safe to open."
> > 
> > But I'm not sure whether the claim about the website would always be true.
> 
> What claim?

To answer your question, my concern is about calling the website, rather than the file, "unfamiliar and potentially dangerous". I wonder whether a file downloaded from Dropbox could trigger this specific warning.

If you think this isn't a concern, I think the message may be better because it mostly resembles the description in the support article you linked to. I'll put that in the patch unless there are objections.
Posted strings to bug 1063105.
(In reply to :Paolo Amadini from comment #54)
> (In reply to Gian-Carlo Pascutto [:gcp] from comment #53)
> > (In reply to :Paolo Amadini from comment #52)
> > 
> > > "This file has been downloaded from an unfamiliar and potentially dangerous
> > > website and may not be safe to open."
...
> To answer your question, my concern is about calling the website, rather
> than the file, "unfamiliar and potentially dangerous". I wonder whether a
> file downloaded from Dropbox could trigger this specific warning.

A file from Dropbox could certainly trigger this warning. I don't think that's
a problem - the installers from Dropbox itself will be signed and won't trigger
it, and in the context of "downloading random .exe's" Dropbox is certainly a
potentially dangerous website.
Will this bug add links to *real* explanations of why a download is blocked and how to disable that?
What is a "real explanation"? Disable what?
Your comment #53 and comment #53, saying it is "the file/site hasn't been scanned by Google" or whatever the reasoning is.

How to disable the scanning.  I guess it would not be useful privacy-wise to disable only the "uncommon" warning, but currently Firefox says nothing of how it decided the file contains virus of malware, so the user does not know where to go with it (Antivirus?  Look at the crap you may get with some ways of checking: https://www.virustotal.com/en/file/93ae14051148ce3aedf531e9bab93d8c385f22de565732e6b509626710c44336/analysis/1409741660/  "WS.Reputation.1" looks like a malware name, but means an uncommon file.).



Does it scan and block all kinds of files, or only .exe?
That's an educated guess from myself based on what I know and observed about the system. If you put a new exe file on your webspace, you'll get the UNCOMMON verdict from their server. Their documentation for webmasters mentions adding your site to their webmaster tools (or signing the binary) as a way to get rid of it. Furthermore, the server always replies relatively in real-time, even though actually scanning the file would mean it has to potentially download hundreds of megabytes from a potentially very slow remote server. This means it must also return verdicts when it doesn't know about the file, yet there's no UNKNOWN verdict. The combination of all of that makes be believe that UNCOMMON probably really means UNKNOWN.

The explanation of the feature is here: https://wiki.mozilla.org/Security/Features/Application_Reputation_Design_Doc 
It may be a small bit out of date with the very latest changes in Firefox (notably, it was disabled to fix this and related bugs first in Firefox 32), but it should clarify some misconceptions you appear to have, notably about who is scanning what, who decides what is a virus and why "useful privacy-wise to disable only the "uncommon" warning" is a nonsensical statement.

The user doesn't need to "know where to go with it" or know "how to disable the scanning". Firefox will *block* the file download by default, so there is nothing more to do and the user is safe. If the user knows better and overrules all the warnings and blocks regardless, then he obviously knows better and figured out what to do with it! See the PDF in attachment to this bug which was made by the UX team, to get an idea of how it will look.
Also note: "6. “Learn more” takes user to Mozilla help page regarding malicious and potentially unwanted downloads."

That would take the user to a site like this: https://support.mozilla.org/en-US/kb/how-does-phishing-and-malware-protection-work

We can expand this when this feature is ready, with some advice wrt. to unknown files. (Deciding the strings was more urgent because they're part of Firefox's UI and can't be changed after a release, and we need a long lead-time because our translators are volunteers)
(In reply to Gian-Carlo Pascutto [:gcp] from comment #60)
> who is scanning what, who decides what is a virus and why "useful
> privacy-wise to disable only the "uncommon" warning" is a nonsensical
> statement.

I don't understand.  Does it get whitelist pieces based on metadata the same way it does for URLs?

Is the "uncommon" warning Windows-only?

> better and figured out what to do with it! See the PDF in attachment to this
> bug which was made by the UX team, to get an idea of how it will look.

It was hard to understand which comments in this bug were overridden talk and which went into FIXED — and why people are still discussing here after FIXED, and after there was a UI without an explanation or a way to override (it's bitten some people already: bug 1048508 [Firefox OS], bug 1064930 [adware]).

(In reply to Gian-Carlo Pascutto [:gcp] from comment #61)
> Also note: "6. “Learn more” takes user to Mozilla help page regarding
> malicious and potentially unwanted downloads."
> 
> That would take the user to a site like this:
> https://support.mozilla.org/en-US/kb/how-does-phishing-and-malware-
> protection-work

That's what I wanted to hear.  I hope it doesn't end up simplified for "ordinary users".
Blocks: 1068660
I really, really do not like the current strings. I see a huge issue of users discounting the warnings due to inaccuracies--which lead to a lack of trust.

First off, you are using the same string for potentially unwanted programs and actual malware. They are not the same thing. The whole reason for the P in PUP is that users do actually sometimes want said programs. If they caused only harm, they would not be /potentially/ unwanted. If a user does want the program, they will likely discard the warning, even if the file really is malware, not a PUP. Not only should the strings be different, but the graphic needs to be different (as people users rarely actually read warnings after they've seen them more than a few times.)

Second, false positives, especially with Google's method of using multiple antiviruses, are not uncommon. We should not be saying that the program "will harm" your computer, when we don't know that for certain. If the file is not actually malware, you are conditioning the user to discount the warning.

(In reply to Gian-Carlo Pascutto [:gcp] from comment #56)
> A file from Dropbox could certainly trigger this warning. I don't think
> that's a problem - the installers from Dropbox itself will be signed and won't
> trigger it, and in the context of "downloading random .exe's" Dropbox is certainly a
> potentially dangerous website.

Perhaps, but the warning also says it is "unfamiliar," and Dropbox is **NOT** an unfamiliar website. This may cause users to discount the warning. The one thing we are certain of is that the file is unfamiliar, so that's what we should say.

Other than that flaw, Chrome's strings are all much better than the ones proposed by Firefox.
(In reply to Terrell Kelley from comment #64)
> First off, you are using the same string for potentially unwanted programs
> and actual malware. 

That's not true, see comment 52 and bug 1063105.

> We should not be saying that the program "will harm" your computer, when we don't know that for certain.

See comment 42 and later for the prior discussion on this. The problem is keeping the severity difference between the warnings while not making them too awkward.

> (In reply to Gian-Carlo Pascutto [:gcp] from comment #56)
> Perhaps, but the warning also says it is "unfamiliar," and Dropbox is
> **NOT** an unfamiliar website. This may cause users to discount the warning.
> The one thing we are certain of is that the file is unfamiliar, so that's
> what we should say.

Okay, I thought the concern was over calling Dropbox "potentially dangerous". If the "unfamiliar" could confuse people, then we'll need a better message.
And in any case, documentation of the "uncommon" status will need to explain how an individual hobbyist developer of useful software can avoid being blocked when making this software available to the public.

We could just recommend that hobbyist developers pay for a code signing certificate from a commercial certificate authority, pay again for certificates on other platforms, and pay again every year when each certificate expires. But that would seem inconsistent with Mozilla's sponsorship of the "Let's Encrypt" effort to provide domain-validated TLS certificates without charge. And if we go that route, we'll need to explain why we apply different verification policies for connections to web sites and for downloaded software.
My understanding is that uncommon files won't be blocked, you'll just get a warning about it being uncommon, forcing the user to explicitly acknowledge the lack of testing data and thus slightly more dangerous situation.

I say slightly because I'm assuming the URL is sent off to Google so they will scan it if it hasn't been scanned already, and thus the software is slightly more dangerous in that there is a risk of a 0 day exploit. It's more for people who want to be absolutely sure, or a heads up if a file is supposed to be common but isn't--which implies the file has been hijacked.
Depends on: 1148010
Blocks: 1241177
See Also: → 1241177
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: