As per https://bugzilla.mozilla.org/show_bug.cgi?id=936041#c18, we should tell users when a download gets blocked. Especially since we are going to be expanding the coverage to include UNCOMMON and POTENTIALLY_UNWANTED (see bug 1019933 and bug 1053890)
Talked about this with Francois. It sounds like this could involve: 1) UI and string changes in the notification (currently the downward arrow) 2) UI and string changes to about:downloads (similar guidelines for how we made improvements to about:addons in bug 1170846) 3) dialog confirmations for "yes let me proceed anyways" type of behaviours
Today our product team said that they don't want to ship bug 936041 until we have this notification UX to go along with it. Is there something simple we could do this week so that we could still ship this in 46?
tracking-fennec: --- → ?
Do we feel that this is a pressing issue? I think before we start marking these downloads, we should give users a way to know "why?" and a way to do something about it. That said, I think the minimum UX requirements are: 1) Re-use the UI from https://bugzilla.mozilla.org/show_bug.cgi?id=1170846#c3 to tell users that a specific download is possibly malware or a virus. We could use the same icon but tint it red (#D23228) to denote the special situation. 2) when a user taps/presses on the aforementioned download, re-use the UI from https://bugzilla.mozilla.org/show_bug.cgi?id=1170851#c5 to give them options of "Dismiss" or "Download anyway". +-----------------------------------------+ | | | | | Download blocked | | | | | | This download has been blocked | | because it may contain a virus | | or spyware. | | | | | | DISMISS DOWNLOAD ANYWAY | | | | | +-----------------------------------------+ 3) Change the download "downloading" notification to "Download blocked" that will open about:downloads when pressed. So the user knows what's happening. Replace the downloading icon with our 'x' icon. I see a string in https://bugzilla.mozilla.org/attachment.cgi?id=8705862&action=edit (after "BLOCKED:"), we could reuse that string here in the subtitle of the notification. +------------------------------------------+ | | | +-+ Download blocked | | +-+ May contain a virus or spyware | | | +------------------------------------------+ Thoughts? Should we file additional bugs or handle them here? NI-ing Francois back since he mentioned there's some new strings landing in Desktop for this work, we should keep them consistent - I've just reused what they have in product ATM.
Flags: needinfo?(alam) → needinfo?(francois)
(In reply to Anthony Lam (:antlam) from comment #3) > NI-ing Francois back since he mentioned there's some new strings landing in > Desktop for this work, we should keep them consistent - I've just reused > what they have in product ATM. The Desktop UX bug for this is bug 1053890. Unfortunately, it's pretty noisy and it's not 100% whether or not attachment 8481334 [details] is the final version of the strings they will be implementing this quarter. It would probably be best to ask Paolo and Panos.
tracking-fennec: ? → 47+
The suggestion in comment 3 sounds reasonable to me. We have a much simpler UI than desktop so presenting a simple "download blocked" prompt is probably the best way to go. Panos, can you help give us guidance on what desktop is doing here? Ideally, I think the simplest thing to do would be to just throw up a prompt when the download is blocked, and then don't have any system notification or download manager listing. If we need to include UI for this in about:downloads, this will be a more complicated feature than I initially anticipated, and we'll need to prioritize it as such.
Flags: needinfo?(margaret.leibovic) → needinfo?(past)
The desktop UX is now in bug 1241177. We'll be enabling the UNWANTED and UNCOMMON verdicts (as opposed to just DANGEROUS like we have right now) as soon as the new UI is in, so you might want to do everything at once in Fennec.
François is right, the UX design from bug 1053890 is going to be slightly improved in bug 1241177 and this work is in our plan for release 47. I don't expect a lot of changes, mostly a visual refresh and a slight change in our messaging for the UNCOMMON case as you can see from the discussion in the bug.
I'm staying in the loop with Sevaan (desktop UX) to reuse the same language here. They're still in the process of finalizing this as I understand it. As that happens, the UX in comment 3 is still what we want to go with here. But the strings might change. Will post more as things get finalized.
This doesn't need to track a release until we decide when we want to ship this.
tracking-fennec: 47+ → ---
Hi Tim, We had download protection on Fennec since bug 936041 was landed. However, it was disabled in bug 1241566 because of a missing UI notification (this bug). It would be great if we can close this security gap. Is it possible to get someone in your team to work on this?
Adding some information and reference... Download protection on Fennec works the same way as on Desktop, except for the fact that there's no UI and that it's disabled by default. To enable it, go to about:config and set: browser.safebrowsing.downloads.enabled = true Then you can go to https://testsafebrowsing.appspot.com/ and click the test cases under "download warnings" (2-7) and the downloads will fail. To see what the UI should look, go to the same URL but with Desktop. ** Reference ** Our high-level documentation is on SUMO: https://support.mozilla.org/t5/Protect-your-privacy/How-does-built-in-Phishing-and-Malware-Protection-work/ta-p/9395 and everything else is on the wiki: https://wiki.mozilla.org/Security/Application_Reputation
Our backlog is pretty full because of the reasons you know of. Redirecting ni so this is under Product's radar.
Flags: needinfo?(timdream) → needinfo?(jcheng)
Joe no longer works on Fennec.
Re-triaging per https://bugzilla.mozilla.org/show_bug.cgi?id=1473195 Needinfo :susheel if you think this bug should be re-triaged.
Priority: -- → P5
You need to log in before you can comment on or make changes to this bug.