1711049 - Require user interaction for all but the first download from a page to prevent download spam

Status: NEW

(Firefox :: Downloads Panel, enhancement, P3)

Description

[Micah [:mtigley] (she/her)]

When Bug 1709129 is implemented, we'd need to address the download user experience to require user interaction when multiple downloads occur on the same page.

This means we need to implement a way to prevent download spam (perhaps via a popup blocker, a permission prompt, etc...) otherwise the user would have to deal with the downloads panel opening incessantly on the same page anytime a new download is initiated.

We do have some earlier work for this in Bug 1463527. So it would worth looking at that too.

Comment 1

[:Paolo Amadini]

You can find a breakdown of this project in https://bugzilla.mozilla.org/show_bug.cgi?id=1306334#c2, including suggested telemetry.

This feature alone can keep one person busy for several weeks.

Instead of using just one bug for the entire project as it was attempted in bug 1463527, I recommend landing it in smaller stages, creating an even more detailed feature breakdown. This has been partly started in https://bugzilla.mozilla.org/showdependencytree.cgi?id=1306334&hide_resolved=1.

This feature is the prerequisite for a number of Downloads Panel changes, the easiest of which is the removal of the interstitial dialog for executables only. This is a much smaller subset of what bug 1710941 is trying to do, and it is something I recommend enabling separately in production before any of the other changes, which in turn should happen after the protection from multiple downloads is also enabled.

Instead, the dependency tree for what it's being asked bug 1710941 is quite extensive. There have been various discussions, but no detailed breakdown yet. You can go through these meta-bugs to get an idea of the real complexity of this proposition:

https://bugzilla.mozilla.org/showdependencytree.cgi?id=1270405&hide_resolved=1

Comment 2

[Daniel Veditz [:dveditz]]

Even if it's not the download panel opening, multiple downloads can be a debilitating DOS. If you've said "ask me every time" for a particular type you have a zillion dialogs to clean up. If you have that type always open in a particular app then you get zillions of that app window launched. If you always "Save File" then you've got a mess to clean up there. A single huge file could fill up your disk already, but it's easier to stop and clean up. With multiple downloads they can get a bunch going in parallel depending on our limits on the number of connections.

Comment 3

[Ava Katushka]

This bug has a link there the problem with download spam could be reproduced: https://bugzilla.mozilla.org/show_bug.cgi?id=1328578

Comment 4

[Ava Katushka]

Looks like there are 2 solutions to this problem, one being more rigid, but easy to implement, and an other one being more flexible and desired.

1. Show permission dialog if more than 1 downloads are started from the same URL (as Sagar already attempted to solve it): https://bugzilla.mozilla.org/show_bug.cgi?id=1463527

2. Count only downloads, not triggered by user. The problem here is how to detect that "download was triggered by user".
   So, what kind of heuristics we can use here?

   Fast pace:

   • Download could be triggered unhumanly fast after the previous download
   • 10 downloads are triggered within the same second
     Lack of mouse movement:
   • Mouse wasn't moving than more than one download was triggered
     Lack of hover events:
   • No hover event was happening before download was "clicked".
     Same file is downloading:
   • Redownload of the same file

Also we can prevent the Unknown content dialog from opening, if an other one is already showing.

Comment 5

[Paul Zühlcke [:pbz]]

(In reply to Ava Katushka from comment #4)

Looks like there are 2 solutions to this problem, one being more rigid, but easy to implement, and an other one being more flexible and desired.

1. Show permission dialog if more than 1 downloads are started from the same URL (as Sagar already attempted to solve it): https://bugzilla.mozilla.org/show_bug.cgi?id=1463527

2. Count only downloads, not triggered by user. The problem here is how to detect that "download was triggered by user".
   So, what kind of heuristics we can use here?

   Fast pace:

   • Download could be triggered unhumanly fast after the previous download
   • 10 downloads are triggered within the same second
     Lack of mouse movement:
   • Mouse wasn't moving than more than one download was triggered
     Lack of hover events:
   • No hover event was happening before download was "clicked".
     Same file is downloading:
   • Redownload of the same file

Also we can prevent the Unknown content dialog from opening, if an other one is already showing.

I'm not super familiar with our download code, but since it's handled by nsExternalHelperAppService, perhaps you could use UserActivation::IsHandlingUserInput to determine if the download was triggered from a user interaction.
https://searchfox.org/mozilla-central/rev/b7bc94b4689a7f002c61d016c6e162e5e5708bf3/dom/base/UserActivation.cpp#35

If it's feasible IsHandlingUserInput seems like the simplest way to do it. There are other pre-existing ways for storing user interaction, such as this permission based approach used for the storage access API: https://searchfox.org/mozilla-central/rev/b7bc94b4689a7f002c61d016c6e162e5e5708bf3/toolkit/components/antitracking/ContentBlockingUserInteraction.cpp#50
Storing user interaction as a permission is not ideal though. For anti tracking we'd like to add a new module in the future to replace the permission.

Comment 6

[Ava Katushka]

Thank you, Paul!
Using UserActivation::IsHandlingUserInput sounds good to me.

Comment 7

[Ava Katushka]

Attachment: Bug 1711049 - Prevent download spam. r?gijs

Depends on D118328

Comment 8

[Ava Katushka]

What about Unknown Content Dialog poping up for the download spam? If the download is suspicious for being a spam, should they be shown after the permission prompt? (if allowed) Or emitted all together?

Comment 9

[Micah [:mtigley] (she/her)]

(In reply to Ava Katushka from comment #8)

What about Unknown Content Dialog poping up for the download spam? If the download is suspicious for being a spam, should they be shown after the permission prompt? (if allowed) Or emitted all together?

We should show the filepicker/unknowncontent dialog for the first download. But subsequent downloads should only show a prompt after a decision has been made on the permission prompt. We only do this if the user has "Always ask" configured from about:preferences.

Comment 10

[Ava Katushka]

Design doc for this project: https://docs.google.com/document/d/1CnwTjmKZU6ivwfaIOHLZtkiv1Y0H5MQz4grOzzOUinI/edit#heading=h.yspy8tt3f0xe

Comment 11

[Phabricator Automation]

Comment on attachment 9230463 [details]
Bug 1711049 - Prevent download spam. r?gijs

Revision D119512 was moved to bug 1725353. Setting attachment 9230463 [details] to obsolete.

Comment 15

[void2258]

I do not believe the issue I reported (1759134) is a duplicate of this bug, as it does not solely have to do with the behavior mentioned here. There are functionality issues beyond simply the number of pop-ups generated that the issue I brought up creates. The download check pop-up provided more functionality, and while avoiding spam pop-ups is desirable, it's removal does not only effect this. the pop-up also allowed for case-by-case selective behavior.

For example, if you had clicked on a PDF before, you could then decide FOR THAT PDF if it would be opened or downloaded. Now, all PDFs are either opened or downloaded with no user prompt. The only way to change this on a case-by-case basis is to, before you click, go into the settings and change them for PDFs, then go in again and change them back to your "default" behavior. The complete removal of this pop-up therefore creates MORE clicking and menu fiddling that was not previously needed.

A single unprompted behavior for all file types is not desirable and potentially problematic. Preventing spam pop-ups is a noble goal, and being able to set it so SOME types act this way is handy, but for all types by default is a problem. Being able to set some file types to ask what to do every time (with an option to say to do this every time, thus removing the pop-up AT USER REQUEST, not beyond user control) would be far preferable behavior.

Comment 16

[:Gijs (he/him)]

(In reply to void2258 from comment #15)

I do not believe the issue I reported (1759134) is a duplicate of this bug, as it does not solely have to do with the behavior mentioned here.

I provided a long comment in 1759134 explaining why I duplicated here - a bug should cover a single issue - trying to cover 3 or 4 different things in a bug doesn't work, so I think the duplication is correct. I'll respond to you in your original bug rather than cluttering up this one.

Comment 18

[BugBot [:suhaib / :marco/ :calixte]]

The bug assignee is inactive on Bugzilla, so the assignee is being reset.